Earlier quoted context omitted.
> 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 w…
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?
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)