Add rclone binary to official docker container or provide an image variant including rclone binary

[OrbitingOcelot]

Output of restic version

0.16.2

What should restic do differently? Which functionality do you think we should add?

It would be really nice to have the latest rclone binary included in the official restic container image (or maybe provide a second container variant as part of the release process which contains the bin from rclone/rclone:latest?).

What are you trying to do? What problem would this solve?

I am evaluating backup strategies for my home-NAS, and after listening to a podcast with Alex I am really keen to start experimenting with restic, which looks awesome!

One thing that is currently providing some headache is the integration of rclone while using the official container image. I am using a backend that only has rclone support, so I need to have the rclone binary accessible in the container, which is currently not the case.

For most NAS distributions, it is really easy to install/update software via docker, so users can pull the official images for restic and rclone, but they cannot easily use the binaries together without potentially messy hacks, relying on 3rd party containers, or building their own container, and thus making things more complicated and losing their systems container GUI- or auto-update functionality.

Kopia decided to do this some time ago, and it just makes it so much easier to use on a NAS with limited build capabilities. Could help a lot of folks to have something similar for restic, especially since this is such an important part of the functionality for many backends.

Thank you for consideration!

[MichaelEischer]

rclone has a very different release cycle than restic. To keep the binary up to date, we'd need some automation to rebuild the image. Maybe someone wants to set up the necessary Github Actions to publish such an image to the GHCR?

[OrbitingOcelot]

Ah, I see, you mean building anew container on every rclone update, even if there is not restic update?

I was more or less thinking about the simpler option, just pulling the latest available rclone binary from rclone/rclone at restic build time, not if docker can do this natively by using something like FROM rclone/rclone ADD xyz...

[MichaelEischer]

Ah, I see, you mean building anew container on every rclone update, even if there is not restic update?

I had a CI job in mind that (unconditionally) runs every few days. rclone usually has a higher release frequency than restic and I'd like to avoid issues that ask for updates.

I was more or less thinking about the simpler option, just pulling the latest available rclone binary from rclone/rclone at restic build time, not if docker can do this natively by using something like FROM rclone/rclone ADD xyz...

With multi-stage builds in docker it's really simple to collect binaries from multiple images.

[cmbcbe]

i don't know if it can help, but i have write a docker-compose.yml that use official rclone docker image and start it as a restic rest server with auth. here is the code

version: "3"
services:
 rclone-webdav-server:
  container_name: rclone-restic-server

  image: rclone/rclone
  command:
    - "serve"
    - "restic"
    - "--addr"
    - "0.0.0.0:8080"
    - "--append-only"
    - "--user"
    - "restic_usr01"
    - "--pass"
    - "Restic_PWD01!"
    - "-v"
    - "/data"
    - "--rc"
    - "--rc-web-gui"
    - "--rc-addr"
    - "0.0.0.0:5572"
    - "--rc-user"
    - "user"
    - "--rc-pass"
    - "pass"

  restart: unless-stopped

  # Use host networking for simplicity.
  # It also enables server's default listen on 127.0.0.1 to work safely.
  #net: host

  # If you want to use port mapping instead of host networking,
  # make sure to make rclone listen on 0.0.0.0.
  ports:
    - "28080:8080"
    - "5572:5572"

  volumes:
    - /srv/rclone-restic/data:/data
    #- /srv/rclone-restic/config/:/root/.config/rclone/:ro