Build & publish docker images

[jinnko]

Output of rest-server --version : master

What should rest-server do differently?

It would be great if there were up-to-date published docker images of the rest-server available for both amd64 and arm64 architectures.

What are you trying to do? What is your use case?

I'm using a docker image as the backend and I want it to be confident it's regularly kept up to date.

Did rest-server help you today? Did it make you happy in any way?

I have put together a Github actions workflow in my fork to automatically build and publish the rest-server to the ghcr.io registry.

This will automatically publish to your own ghcr.io registry without having to configure any credentials as it will use the Github Actions GITHUB_TOKEN.

The produced images will have standardized tags and labels as produced by the official docker/metadata-action

Here's a couple of build examples to see what this is doing:

Pushes to master:

• https://github.com/jinnko/rest-server/actions/runs/6580532884/job/17878709059
• https://github.com/jinnko/rest-server/actions/runs/6580704450/job/17879251349

When a release is published:

• https://github.com/jinnko/rest-server/actions/runs/6580795590/job/17879516649

And there's a schedule-based trigger to ensure a weekly image is created from the master branch to capture any OS or env level security patches that may be needed.

If you're happy with all this I will raise the changes in a PR.

[rawtaz]

Are there not already up to date and official Docker images of rest-server for those architectures here? --> https://hub.docker.com/r/restic/rest-server

[MichaelEischer]

@rawtaz The Docker images on the docker hub just contain the latest rest-server binary but no updates to the underlying base image.

We have a ghcr docker image build pipeline for restic: https://github.com/restic/restic/blob/master/.github/workflows/docker.yml . I'd prefer to keep the configuration as similar as possible between restic and rest-server.

From what I see, the only major difference to what's currently configured for restic, seems to be the addition of the cron statement for weekly rebuilds? Do you know what the current best practices are regarding rebuilds of docker images? If I'm not mistaken, replacing an image tag isn't always picked up by whatever is used to run the container, especially in case of Kubernetes.

[TheCrockett]

+1

Client error:
enter password for repository:
Fatal: config cannot be loaded: unsupported repository version. Try again

Client:
restic version
restic 0.15.2 compiled with go1.20.6 on linux/amd64

Server (docker):
/data # rest-server -v
rest-server version rest-server 0.12.1 compiled with go1.20.5 on linux/amd64
/data #

Built from repo:
Fatal: config cannot be loaded: unsupported repository version. Try again
enter password for repository:

[MichaelEischer]

@TheCrockett the client is definitely not running restic 0.15.2. That specific fatal error message is only returned by restic versions before 0.14.0 . Either way, the problem is unrelated to this issue.

[hydrapolic]

Wondering about the same. I'm using restic/rest-server:0.12.1-amd64 and trivy vulnerability scan shows:

restic/rest-server:0.12.1-amd64 (alpine 3.18.2)

Total: 24 (UNKNOWN: 0, LOW: 0, MEDIUM: 16, HIGH: 5, CRITICAL: 3)

usr/bin/rest-server (gobinary)

Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)

A weekly rebuild would probably suffice (or more frequent releases).