4 ms·

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 cus

by jopsen 9y ago

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 9y ago
> 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 9y ago
  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 https://github.com/moby/moby/issues/8329 [2]: https://github.com/moby/moby/pull/5821#issuecomment-49492924 https://github.com/moby/moby/pull/5821#issuecomment-49492924
  - donmcronald 9y ago
    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 9y ago
      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
  - dullgiulio 9y ago
    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 9y ago
      Google it. It’s a fun topic.
  - lloeki 9y 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.
    - 9y ago
- cygned 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
      Nexus also has a docker registry with all that.
      - _ix 9y ago
        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 9y ago
      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 9y ago
- jopsen 9y ago
  References to docker hub is hardcoded into a LOT of code/config..
  - markbnj 9y ago
    I suspect the majority are unqualified references, i.e. 'markbnj/unbound' that rely on docker using the hub as a default repository.
devmunchies 9y ago
I could see github adding a tab to repos as for a container registry. That would destroy docker hub imo.
- curryhowardiso 9y ago
  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.
- bharatkhatri14 9y ago
  GitLab has an integrated container registry since 2016. https://about.gitlab.com/2016/05/23/gitlab-container-registry/ https://about.gitlab.com/2016/05/23/gitlab-container-registr...
  - Chilinot 9y ago
    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.

by jopsen 9y ago

gingerlime 9y ago

> 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 9y ago
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 https://github.com/moby/moby/issues/8329 [2]: https://github.com/moby/moby/pull/5821#issuecomment-49492924 https://github.com/moby/moby/pull/5821#issuecomment-49492924
- donmcronald 9y ago
  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 9y ago
    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
- dullgiulio 9y ago
  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 9y ago
    Google it. It’s a fun topic.
- lloeki 9y 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.
  - 9y ago
cygned 9y ago
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 9y ago
  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 9y ago
    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 9y ago
    Nexus also has a docker registry with all that.
    - _ix 9y ago
      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 9y ago
    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 9y ago
jopsen 9y ago
References to docker hub is hardcoded into a LOT of code/config..
- markbnj 9y ago
  I suspect the majority are unqualified references, i.e. 'markbnj/unbound' that rely on docker using the hub as a default repository.

devmunchies 9y ago

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

curryhowardiso 9y ago
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.
bharatkhatri14 9y ago
GitLab has an integrated container registry since 2016. https://about.gitlab.com/2016/05/23/gitlab-container-registry/ https://about.gitlab.com/2016/05/23/gitlab-container-registr...
- Chilinot 9y ago
  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.