Add Official Docker Container Release

[OrbitingOcelot]

Hi, highly impressed with rustic so far 😍, however one thing I would really like to see is the addition of an official docker container as part of the build/release process.

I have seen the discussion about the dockerfile, however an officially built and released image on dockerhub would be what I am looking for.

Use case for this would be home NAS users, who currently install their 3rd-party software via docker containers and keep it up to date this way. Many of the major NAS systems have very convenient built-in ways to install/update docker images, however very little other ways to get the software from package managers, and building from source is also not a good option as these system are missing the build tools.

For example, I would like to add a rustic docker image to my NAS, and periodically run backups either via cron in the image, or via invoking the container with docker exec or docker run.

I would also propose that this container includes the latest version of the rclone binary (provide in docker build by for example pulling from image: rclone/rclone:latest), as a lot of backend connectivity depends on it, and it can be a real hassle to provide it via a different external container (for example, Kopia now has rclone binary in their docker image to make it more convenient).

Thank you for considering!

[nickchomey]

The maintainers, of course, can do what they like, but it seems to me that this is both unnecessary and excessively complicated.

Both rclone and rustic are single file binaries, so they can easily be installed simply by downloading that file. Rclone even has a shell script that will automatically download the correct version for the OS - you could even modify that to download the appropriate rustic version at the same time.

Both can be updated through their selfupdate command.

Still, I suppose it would be simple enough for you to make and contribute a docker image to the project...

[aawsome]

Please have a look at https://github.com/rustic-rs/rustic-helm. I lost a bit track of the current state. But @mueckinger is working on helm charts and hence also on getting official containers ready..

[aawsome]

I think this discussion should go into https://github.com/rustic-rs/rustic/discussions/995 - hence I'm closing this issue.

[aawsome]

Ah, just one comment. We just added support for opendal backends which will soon be able to support many storage providers directly without the need of rclone. But still, the rclone topic might stay important for some use cases...

[OrbitingOcelot]

Both rclone and rustic are single file binaries, so they can easily be installed simply by downloading that file. Rclone even has a shell script that will automatically download the correct version for the OS - you could even modify that to download the appropriate rustic version at the same time.

Both can be updated through their selfupdate command.

Maybe this is just a very special perspective of a NAS user, but generally I want to avoid installing stuff on the host system directly outside of the docker containers. Of course, I can create my own container with both binaries and periodically self-update, but it would make using rustic so much simpler for many (NAS) users if they could just get an official image that has all they need.

[mueckinger]

A prerequisite for having the official docker image is an automated build process in github. We'd require someone willing to contribute his knowledge on this topic. rustic and rclone (as server) communicate well via a REST API, so there is no need for a combined image. This would contradict the "one container, one process" and "microservice architecture" principle. Instead I would propose having a docker-compose file, combining both services.

[OrbitingOcelot]

Understood and acknowledged that automated docker build is currently not in the cards. Sadly I am also no expert on this topic, just a simple user, and be of much help.

REST API: My understanding is that both from a complexity, security, and performance point of view, it is desirable to have the API connection in the same container, and the rclone process spawned directly. The restic docs (hope you don't mind) explain this, I would assume the same reasoning would hold true for rustic? https://restic.net/blog/2018-04-01/rclone-backend/

By docker-compose file you mean users should roll their own container containing binaries from both images? This would exclude the NAS users who want to pull the official container and for it to "just work".

[mueckinger]

Hmm, somehow it seems to me that we don't mean the same thing when we talk about NAS. I switched to Kubernetes in my professional environment two years ago, and I have to admit that my docker knowledge is dwindling. But when I left docker, docker-compose was the de facto standard for handling docker containers. I still use it in my debian based home NAS setup. Can you please specify your NAS setup, are you using a special distro with UI? Regarding security, it is possible to isolate docker networks from each other. How do you deal with other services? I can't imagine that you are using a Nextcloud image with an integrated MariaDB, for example. That would be the classic for docker-compose.