Use restic & rclone binary of host system in docker container

[beatbrot]

The issue

Autorestic calls restic in a container for backing up docker volumes. The restic binary in the container, however, is shipped with the image. This can lead to version mismatches and a very tight coupling between restic & autorestic

The fix

With this change, Autorestic mounts the restic and optionally the rclone binary from the host OS. This is only possible, because restic and rclone both are Go applications that tend to have almost no external dependencies. In fact, both rclone and restic have no external dependencies other than muslc.

I tried this locally and this approach worked just fine.

Remarks:

• I don't know if the autorestic docker image is still needed after this PR. I just left the Dockerfile as is, to not break anything
• This approach currently doesn't work with a custom rclone path. This, however, was already the case before due to this call

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
autorestic	✅ Ready (Inspect)	Visit Preview	Sep 4, 2022 at 0:14AM (UTC)

[zenofile]

At least on Fedora as the host OS, where rclone and restic are built with CGO_ENABLED=1, both fail to run when mounted into alpine unless they are rebuilt as entirely static binaries.

[beatbrot]

@zenofile So I guess switching to a base image with glibc would solve this? Maybe busybox:stable-glibc?

[zenofile]

@zenofile So I guess switching to a base image with glibc would solve this? Maybe busybox:stable-glibc?

I don't think this would work. At least not reliably.

Host OS Fedora 36:

# podman run --rm -v /usr/bin/restic:/usr/bin/restic docker.io/library/busybox:stable-glibc /usr/bin/restic version
/usr/bin/restic: /lib/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/restic)
/usr/bin/restic: /lib/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/restic)

# podman run --rm -v /usr/bin/restic:/usr/bin/restic docker.io/library/debian:stable-slim /usr/bin/restic version
/usr/bin/restic: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/restic)
/usr/bin/restic: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/restic)

# podman run --rm -v /usr/bin/restic:/usr/bin/restic docker.io/library/debian:testing-slim /usr/bin/restic version
restic 0.12.1 compiled with go1.18.4 on linux/amd64

# podman run --rm -v /usr/bin/restic:/usr/bin/restic docker.io/library/debian:unstable-slim /usr/bin/restic version
restic 0.12.1 compiled with go1.18.4 on linux/amd64

As soon as the glibc versions drift apart, this will cause issues. Let alone non-FHS compliant distributions like NixOS as host.

I would prefer having the mapping of the host binaries as a configuration option as well as being able to specify my own container image used in the backup process.

There is also https://github.com/cupcakearmy/autorestic/pull/233.

[beatbrot]

Hmm very good points :) Great that you had a look at it. I like your suggestion, I'll however wait until we get feedback from @cupcakearmy so I don't do the work unnecessarily :)

[cupcakearmy]

The idea seems very smart, like the approach! @zenofile def. has more knowledge about this than me xD but I would also say that my gut feeling tells me this could break things.

[cupcakearmy]

For now #233 I think is the more stable variant. But not neceserraly the end solution