[jopsen]

People, yours truly included, seem a bit concerned with the 2 months notice.

To be fair docker cloud was never great and hopefully it doesn't have many big customers...

But the precedence of shutting down a paid service with 2 months notice is not nice. What would happen if this was docker hub? Panic!

[gingerlime]

> What would happen if this was docker hub? Panic!

Isn't docker hub relatively easy to replace, in comparison?

Otherwise, is this a wakeup call perhaps?

[TheDong]

docker hub is surprisingly difficult to replace because of how docker registries work.

Traditional package managers have two distinct concepts: a repository and packages within those repositories.

For example, if ubuntu took down their apt repo server, I could run my own with all the same packages and change a single sources.list entry and all my servers, ansible roles installing packages, etc, would operate the same.

This is possible because the package name+version is an identifier everything else uses and the only thing that cares about the repository is apt itself; all other tooling doesn't need to know about the repository the package is sourced from.

Docker conflates those two things. Each client doesn't just send a package name, it sends a url + package name + version (e.g. foo.registryurl.com/image:version). Because every single client has the detail of "foo.registryurl.com" baked in, it's difficult to change that. I can't change a single "repository-mapping" file that the docker daemon reads to quickly update it.

Instead, I have to update every single client.

The idea of decoupling those is not new. In 2014 it was proposed [1], and various implementations that would help make it easier to migrate off the default registry have been proposed and rejected [2]

This doesn't even get into the lack of tooling for chasing down the transitive dependencies building my images has on various registries with each FROM.

[1]: https://github.com/moby/moby/issues/8329

[2]: https://github.com/moby/moby/pull/5821#issuecomment-49492924

[lloeki]

> 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.

[donmcronald]

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?

[lloeki]

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

[dullgiulio]

But here we are talking about Docker Hub closing, which is way easier to solve. This is the registry that is used as default (for all non-local images without a URL identifier, like "alpine:latest").

All you need is an option to set the default registry. Probably it's already there, didn't google.

[donmcronald]

Google it. It’s a fun topic.

[donmcronald]

Does it actually send the URL? I think it uses the URL to make the network request, but doesn’t actually send the URL to the registry. If it did, you could use an alternate registry as a pull through cache and have it go upstream for everything. AFAIK that’s not possible.

[TheDong]

Docker's registry protocol is surprisingly complicated. It is stateful, it is not trivially cacheable, and it's a right pain in the ass to deal with

[cygned]

The registry itself can be self-hosted easily, however everything on top (authentication, web UI, automation, ...) is surprisingly difficult. Plus technical challenges as pointed out by other commenters.

[kuschku]

GitLab includes a full docker registry, with all that.

Just run a custom GitLab instance, and you get all that for free.

For my open source projects on git.kuschku.de I also have a gitlab container registry on k8r.eu, and it’s been amazing to work with.

[agotterer]

AWS has a registry as well. Both solutions are and easy way to host private and public repos. But Dockerhub offers access to a huge ecosystem that everyone is already plugged into that would be devastating if it shut down. You’d potentially have to re create so many base images from scratch.

[andypanik]

Nexus also has a docker registry with all that.

[_ix]

Nexus isn’t a terrible option, but the application feels pretty dated from a deployment and maintenance perspective. We’re using it for ruby gems and internal docker registry. I haven’t looked into viable alternatives for the gems side of things—that works well enough—but we’re replacing the docker registry with gitlab.

[cygned]

Interesting, I didn’t know that. We host a registry with HTTP simple auth and it works for us because we don’t need all that.

[zawerf]

There's an on premise version of docker hub (Docker Trusted Registry I think?).

[jopsen]

References to docker hub is hardcoded into a LOT of code/config..

[markbnj]

I suspect the majority are unqualified references, i.e. 'markbnj/unbound' that rely on docker using the hub as a default repository.

[devmunchies]

I could see github adding a tab to repos as for a container registry. That would destroy docker hub imo.

[bharatkhatri14]

GitLab has an integrated container registry since 2016. https://about.gitlab.com/2016/05/23/gitlab-container-registr...

[Chilinot]

Their devops for autobuilding, testing, and deploying are really awesome as well. We run an internal GitLab host that handles all deployments for us through their CI/CD interface.

[curryhowardiso]

That would be super cool, and I've noticed the branch protection features changing on GitHub, so perhaps they're thinking about this space too.