Container Registry Redirect

[marcoceppi]

Summary

With ISOs around the corner, we need to make sure we can support our ever evolving projects needs. Today we host all our images in ghcr.io but that may one day change. This proposal is to build and deploy a container registry redirect at ublue.it which will allow, via a YAML file, the ability to map container URLs such as ublue.it/silverblue-main and ublue.it/kinoite-nvidia as a redirects to one or more container registry backends.

Goals

• Support a consistent and permanent container image URL
• Support multiple registry backends for a single image
• Support pointing multiple URLs to the same image (eg: ublue.it/ubuntu -> ghcr.io/ublue-os/bluefin & ublue.it/bluefin -> ghcr.io/ublue-os/bluefin)
• Stateless redirection
• Minimal infrastructure investment

Non-goals

• Create a proxy or cache where images blobs / traffic are passed through the service

Design

Either modify this existing Caddy implementation or build a small service either using something like NGINX, aiohttp, or net/http where the app can read in a simple configuration file and produce the correct 302 Location header when a valid URL is accessed.

Under the covers, a container URL such as ghcr.io/ublue-os/bluefin actually translates into a series of requests against against this base url: https://ghcr.io/v2/ublue-os/bluefin.

Ultimately when you enter a ublue.it image into a container engine (like podman, docker, rpm-ostree rebase, etc) and use an image URL like ublue.it/bluefin; the container engine will translate that into a URL like this https://ublue.it/v2/library/bluefin/... and use it for all requests. This service will return an HTTP 302 with a location header pointing to https://ghcr.io/v2/ublue-os/bluefin/... which will cause the container engine to then follow that redirect and proceed with communicating to the Github API server to fetch metadata and the actual layer blobs.

Github's own container registry actually implements a series of redirects themselves when accessing their v2 container API. When you fetch a container blog it redirects to an object store URL.

Alternatives

I spent a bit of time looking around and the closest implementations I could find are httptoolkit/docker-registry-facade and registry.k8s.io/archeio.

registry.k8s.io is the recently deployed registry redirect by the Kubernetes project that allowed them to migrate from k8s.gcr.io to auto redirecting between GCP and AWS based on where the request originates from and some other requirements. While this solution is great from a pure redirect and lots of value add for their users it won't fit some of our use cases.

docker-registry-facade is the closest to what we're trying to do by using Caddy. It's focused on a mostly transparent passthrough and with some modifications we could implement the goals of redirecting.

@akdev1l discovered blog.cloudflare.com/dynamic-redirect-rules which would help to implement mapping a domain to registries. However, the free tier has some limitations that may not work for this project.

Timeline

I'm looking to get started on this April 10th pending feedback and have an MVP available before Fedora 38 lands on April 18th.

[castrojo]

Do you have any insight on cost? (Edit: so far we're paying for a domain and the github team plan, but this would be real infrastructure so just want to look at all our options because that's a one way trip, heh.)

[bigpod98]

Im not sure it does because we would want it to be ublue.it/bluefin for example to get bluefin
And not just target ghcr but also lets say quay and dockerhub so even if ghcr is down images would still be pullable

Therefore im not sure if just 10 configurations is enought

[akdev1l]

okay so I was playing with this and I was able to get a redirect going on resume.akdev.xyz (sorry this is domain I already had laying around)

CF probably would work if they didn't have a bunch of functionality paywalled (without literally any indication of this paywall until you actually try to call some functions)

redirects via CF Pages almost works but it seems CF strips off the authorization header so can't login through that :-(

I also have some servers laying around I could provision to host stuff if needed

[marcoceppi]

I've added your findings to the original post. Thanks!

[dhoell]

Independent of cloudflare (or any other service) and certainly free forever, but more limited: DNS CNAME

We'd need to use a subdomain, since ublue.it should probably still point to github pages, something like get.ublue.it. IN CNAME ghcr.io. should do the trick. However:

• There is no way to refer to specific resources, so we'd end up with the slightly redundant URL get.ublue.it/ublue-os/silverblue
• We can't point to multiple backends, CNAME need to be unique.

[akdev1l]

Sadly I don't think DNS level solutions would work because all the connections are TLS and the hostname is validated as part of that.

It also seems like we want to achieve some level of HA