Hacker News new | ask | show | jobs
by lloeki 3015 days ago
> Instead, I have to update every single client.

To combat this, every single image we use from hub.docker.com is "proxied" into our registry with a one-line Dockerfile:

   FROM image:version
Building the "proxy" image and publishing it in our registry is entirely automated (using CI+Registry of a self-hosted Gitlab). Then we make everything point to our version in our registry. Should hub.docker.com go belly-up, then we have 1. a cache of versions in use (current and past), and 2. full control of the images (possibly making our own FROM scratch) without having to change a single line in downstream consumers. Initially we did this to be safe from hub.docker.com possibly intermittent availability that would delay image pulls on deployments.
1 comments
donmcronald 3015 days ago
Do you do it per project or as a separate project that houses all the proxy images? How do you version the proxy images? What namespace do you push them into? Is it easy enough to deal with that it doesn’t waste a lot of time?

I’ve been trying to insulate myself from docker too and the FROM proxy strategy seems to break the least stuff. Have you hit any pain points?

link
lloeki 3015 days ago
This is a single 'gitlab.example.com/docker/library' project.

We use orphan branches, one per image, although other strategies are possible (like using the commit diff and directory name).

Proxy images are versioned using branch names (e.g postgres vs postgres-9.6), images are pushed to gitlab.example.com/docker/library/postgres, and using version detection we generate docker image tags (e.g a 'postgres' branch will create postgres:latest, plus extracting version from postgres --version also pushes postgres:10 and postgres:10.1 images.

See this .gitlab-ci.yml[0]. Yes, there is one per branch. This can be generalised further (especially with Gitlab's new import system for .gitlab-ci.yml) but works well enough in practice, it's very low maintenance, and updates are a mere commit+push away.

In fact we use this not just for proxying images but for all "generalised", "utility", or "dependency" images that are not the result of a given full-blown app project in its own repo (those have their own CI/CD process in their respective repo)

[0]: https://gitlab.com/snippets/1705998

link