24 ms·

Docker to rate limit image pulls

355 points by AaronFriel 6y ago

LongLiveCHIEF 6y ago
The real reason this is a problem, is that docker hub has never focused on implementing standard and secure features for account management. Even with the recently implemented access tokens, there's no way for me to limit the scope of those tokens to a specific organization or image, and thus it's no different from a password. That means if I build something from one organization, it's going to impact the ability to build something for another organization. This effort seems to me like they are trying to disguise a last ditch effort to stay afloat. Now that github, gitlab, and other great image repository options exist that don't lack these inherent security/integration features, anyone impacted can easily switch providers for no cost. This new rate limiting won't help anything for docker, it's just going to kick off the exodus away from docker. Ironically, it's this account/security/integration stuff that they lacked focus on that lost them so much financial opportunity to begin with.
LongLiveCHIEF 6y ago
People are also forgetting how newer docker infrastructures use multi-arch and multi-stage builds, meaning a single build could count for dozens of manifest hits, especially with distributed caching. All the things docker has been working for to enhance the build tooling will now be more difficult to use, even if the user never stores a single image of their own on docker hub.
AaronFriel 6y ago
This seems incredibly likely to break development use cases at both extremes: CI/CD systems and developers just starting out could end up pulling quite a few images per hour. Imagine if NPM, Ruby Gems, and so on rate limited package downloads until you paid! I'm not sure if there's a better way to monetize the Docker Hub, but this seems so hostile to adoption.
- brian_herman__ 6y ago
  Yeah, someone should come up with an alternative that mirrors it or something.
  - mirekrusin 6y ago
    Built in torrent and/or ipfs?
    - namibj 6y ago
      The latter has content-dependent chunking support. That would allow for cross-image sharing of common data (large binaries, etc.).
- sitkack 6y ago
  > Imagine if NPM, Ruby Gems, and so on rate limited package downloads until you paid! Sounds like an entirely reasonable thing to start imagining. Reliability, safety, determinism and predictability are not thrust upon someone from the commons. I frankly find it someone atrocious and abusive that downstream systems do not adequately cache these assets. The main archive repositories should be the source of truth, but they also don't need to be the fountain.
  - AaronFriel 6y ago
    Do you think NPM, Ruby Gems, or others would last long if they were so user hostile? Would Node have grown into the genuinely useful development environment it is if free users were limited to 10000 package downloads an hour? It's so unbelievably user hostile that it seems like the result will be people just stop using Docker. The right solution for Docker is probably to spin off or monetize the Hub in a different way. Imagine if GitHub started charging users for git cloning too many packfiles per hour.
    - michaelmrose 6y ago
      All these things cost money to run why would it be surprising if they cost money to utilize their resources beyond a point?
cosmotic 6y ago
I setup a local docker cache using a docker image. The transition to HTTPS everywhere makes caching this sort of thing difficult. One has to install and often manually configure trusted certificates on every client to maximize the cache. APK and APT caches often come hand-in-hand for this sort of thing as the logical next step is to add some OS packages to the pulled image. This also benefits from local caching and also means frustrating cache setup, certificate setup, etc. To maximize local caching there's a lot of manual work to setup a house-of-cards series of proxies that only work on the network. Setting it up on a laptop then traveling means everything breaks in not-so-obvious ways when you leave the network.
solatic 6y ago
Want to see if you're affected? kubectl get pods --all-namespaces -ojson | jq -r '.items[].spec | .containers[] // [] += .initContainers[] // [] | .image' | sort | uniq | less ... and look for anything that's not from a private registry that you control. Give people two months to migrate? What a nightmare.
- merb 6y ago
  well a shitload of stuff from k8s mostly lies in quay.io or k8s.gcr.io
- Dylan16807 6y ago
  Giving people over a certain limit two months to migrate or set up a cache or give them a few dollars. What a non-nightmare.
uberman 6y ago
I'm very conflicted about this. On the one hand, I recognize that there are potentially significant costs to be born to serve these repositories. On the other hand, making docker part of your infrastructure requires a certain degree of availability. At some level this seems to me like using my IDE and after 6 hours it would stop working or finding that my CDNJS references to bootstrap stopped working after 6 hours of my site being up. I think it is exactly as if NPM or PIP were to stop working for the day if you included "too many" packages. I don't really have a good feeling for how these new limits might impact setting up new dev/test environments so I'll likely switch from using specific images to using generic images to limit my exposure. For example, at the moment, if I want a new dev container for a project in python, I'll FROM python:latest and supplement with pulls from support service containers like nginx:latest and postgres:latest. Moving forward, it would seem a safer approach will be to use pull a single 18.04 image and run the required installs into them. This super bums me out though as it seems to bypass some of the nicer aspects of getting up and running with docker.
- geek_at 6y ago
  Well to play devil's advocate if docker is part of your infrastructure and you need to make more than 200 pulls in 6 hours you should already host your own registry and maybe mirror a few dockerhub repos to your own
- throwanem 6y ago
  Do pulls for a "latest" tag bypass the cache?
  - mikepurvis 6y ago
    No they don't, but if you do something silly like spin up a bare VM build node, and then pull your environment every time, then obviously you won't get any caching.
    - ArchOversight 6y ago
      Github Actions? Gitlab CI? Many of those don't do any caching because of the chance of poisoning a tag in the local registry, and don't have a good way to do caching per project. I can imagine that this affects those sorts of operations.
Keverw 6y ago
I kinda wonder if Docker as a company is struggling. Redhat made Podman which is a compatible replacement, Then there's swarm but apparently that's not recommended and actively developed anymore, then as far as I know they sold off their enterprise clustering product. Seems Kubernetes is the popular thing now even if a bit complex to setup. Wonder what the current business model? Pretty neat idea of using containers, but seems they put it out in the wild, got popular and sorta lost control with so many competing options being released.
- zapita 6y ago
  Yes Docker seems to be struggling as a company. But I doubt Podman has anything to do with it. The adoption of Docker open-source tools is massive and 99% of its users have never heard of podman or any other clones, and likely never will. The problem is simply that those tools are free, and Docker has failed to convert the success of their free tools into a successful business.
  - hda111 6y ago
    It’s partly open source and partly freeware. They could just make docker for windows/mac a paid software. I would pay for it if they would listen more to the community when a bug is found. They seem to ignore many bugs Docker Desktop on GitHub. I like about the podman Tools that there is a community effort from Red Hat. It’s not 100% compatible with docker and probably never will. So I will just hope that Microsoft or Canonical buys Docker and make it more open to the Community.
- pm90 6y ago
  They won the container war but lost the orchestration war. Even if docker compose was successful though, I fail to see how the clouds wouldn’t just replicate everything. So I guess they just failed to monetize the technology.
  - zapita 6y ago
    > So I guess they just failed to monetize the technology. Yes, it's really that simple. All those "container wars" and "orchestration wars" are a distraction from the core issue, which is that all those container and orchestration tools are open-source, and it's very hard to build a viable business on top of them. Docker tried and failed, like most startups involved.
jpalomaki 6y ago
I guess CI services like Github Actions could be easily hitting these limits (100 pulls per IP per 6 hours).
- eblanshey 6y ago
  I'm thinking the same thing. GitLab has shared CI runners that probably do a lot of image pulling. Hopefully they have plans to implement their own docker registry cache.
  - tr-gitlab 6y ago
    GitLab PM here - we have a feature called the [Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/ https://docs.gitlab.com/ee/user/packages/dependency_proxy/) that allows you to cache images from DockerHub. Currently this only works for public projects, but we are working on adding support for private projects now: https://gitlab.com/gitlab-org/gitlab/-/issues/11582 https://gitlab.com/gitlab-org/gitlab/-/issues/11582.
- lights0123 6y ago
  I would imagine that GitHub would work out something with Docker to either pay themselves or have some way of caching images themselves. They could just inject their own TLS certificates into their VMs and then intercept Docker requests for images with their own cache.
- jacques_chester 6y ago
  I am anecdotally aware of large Concourse installations that have caused individual companies to be blocked entirely from Dockerhub (and which caused "face melting" of Github Enterprise instances). Badly-behaved CI is a serious issue at scale.
pm90 6y ago
I’m hoping GCP/AWS steps up and creates a limitless docker registry. Considering the size of their infrastructure operations, I suspect this would be a small cost but bring a lot of goodwill. One thing this is bound to do is to make the process of using docker a bit more complex. Explicit registries will probably start to be used everywhere, which is something I welcome. But it seems like a really poor decision by docker, the company to do this: they’re going to drive people off using docker hub.
- verdverm 6y ago
  They have registries already which work with docker after an auth setup. They are generally private to you. Yes, docker is a struggling company which sold some lines of business and is now trying to reinvent itself again towards developers. Given other recent moves, I'm not sure the new leadership understands how to do this.
  - forty 6y ago
    They have registries but at least AWS' one is not free at all...
    - verdverm 6y ago
      They all cost money, because it's expensive to ship bytes out of the cloud. Docker is likely going the way of the Dodo because they likely funded our free access with VC money. They also probably made a bad assumption in that they could define the only container format before standards bodies got involved. Blitz Scaling was the mantra of the time, seems to have bitten those back who took a bite of that cake.
obilgic 6y ago
They want you to login, so they have better data for monetization
- jacques_chester 6y ago
  I think they want you to login because it's hard to monetize anything while hemorrhaging cash to egress fees.
bsamuels 6y ago
There is very little reason for a build node to need to pull 200 images in 6 hours, and here is why: When a machine issues a ``docker build`` command, the program reads the relevant dockerfile to check for any base images that need to be pulled (a la "FROM:") These base images are identified based on the image repository, image name, and image tag. The first thing docker does is it checks its local registry and tries to find a match for the base image the docker build is requesting. If a matching image is located in the local registry, it uses that one in lieu of downloading the image. This is significant - if your organization only uses a few dozen base images from DockerHub, those images will only be downloaded by each build node _once_, then never again. Many docker users erroneously believe that if their Dockerfile requests a "latest" tagged image, docker build will always download the newest version of the image. However, the "latest" tag is literally just a tag, it doesn't have any special functionality built in. If the docker build command finds an image tagged "latest" in the local registry, it stops there. The only way to get docker build to always use the "actual latest" version of the base image is to add the "--pull" parameter to the docker build command. This arg will tell docker build to check the repository remote to see if the SHA hash of the image tagged "latest" has changed, and if so, re-download and use it. In the absolute worst case, this means each build node will pull 1 copy of each base image when the base image is updated. So unless you use 200 different base images that all have updates deployed to Dockerhub each and every day, you are fine.
- adrianmsmith 6y ago
  > The first thing docker does is it checks its local registry and tries to find a match for the base image the docker build is requesting. If a matching image is located in the local registry, it uses that one in lieu of downloading the image. While I agree that this is the way it's supposed to work, I have unfortunately worked at companies with "stateless" build/CI servers that download the Docker image each build.
  - umvi 6y ago
    Well, this policy change will force them to be more efficient, and it's a net win for everyone
theon144 6y ago
Good! I'd even welcome much more agressive limits than what they're proposing; the current culture regarding builds and CI in general is horrifyingly ineffficient, wasteful and in the end just plain slow. I'm looking forward to developers adjusting their workflows (and caches, etc.) to actual, reasonable limits, not just perusing the service as if it were an unlimited cost-free cornucopia of software.
- draw_down 6y ago
  > the current culture regarding builds and CI in general is horrifyingly ineffficient I used to be in charge of the website for a company you’ve heard of. We once realized some huge proportion of our traffic originated from a hosted CI company requesting the site thousands and thousands of times (guessing one for each build they hosted) every 5 minutes. I can’t remember what proportion of traffic it was but I’m pretty sure it was a majority, maybe even more than 80%.
  - userbinator 6y ago
    I sure hope the "cloud first" advocates are happy now, because they have managed to create masses of developers who have next to no idea that what they're doing is an incredible waste of resources. These are also the same people who are perplexed why their systems intermittently fail, or are surprised that they do when the Internet connection cuts out for a bit.
    - draw_down 6y ago
      We just emailed them and asked them to stop. Which they did, and they apologized, but maybe they just changed it to google.com or something which wouldn’t be any less wasteful.
- pjmlp 6y ago
  I welcome the end of free beer culture, so I am quite alright with their change.
- avasthe 6y ago
Havoc 6y ago
Can’t say I’m surprised. They must be incurring significant data costs. The limits seem reasonable at least.
Crazyontap 6y ago
Honest question, but why can't docker use something like bittorrent to download images? Most of us download our OS via torrents only, so we may as well download the images too if there was support for it.
- saagarjha 6y ago
  > Most of us download our OS via torrents only I mean, I only do it to stick it to the people who claim torrents can only be used for piracy; I think most people prefer the simplicity of direct downloads though…
  - bigmanwalter 6y ago
    I can usually max out my connection speed with torrents. This is rarely the case with direct downloads.
    - saagarjha 6y ago
      Guess I just have slow internet :(
    - stingraycharles 6y ago
      The start up time of a torrent is typically so long though, by the time it has connected to all peers and is downloading I have already downloaded the iso with a direct download anyway.
      - stonewareslord 6y ago
        There's a feature of linx-server that provides uploaded files with a torrent URL as well as a regular download URL. I believe the torrent client tries fetching data from peers as well as from linx (http). https://github.com/andreimarcu/linx-server https://github.com/andreimarcu/linx-server
      - namibj 6y ago
        Soon, when QUIC is widely supported by the swarm (just needs updating to the current version), IPFS should be better than torrents for start-up delay, and much more importantly, it allows for sharing data across "torrents" when using content-defined chunking via rabin or buzhash. This means that things like common larger binaries get shared between images that include them, which should greatly increase the average amount of seeders for the chunks that make up an image.
renewiltord 6y ago
Numbers seem reasonable. Does anyone have a quick guide for me to use ECR as a transparent cache or something?
nickjj 6y ago
Does anyone have any good ideas on how the Docker Hub could be monetized in a way that's user friendly and makes sense? AWS, GCP, Azure, DigitalOcean and even GitHub / GitLab all have private container registry offerings. If your stack is on X provider, chances are you're going to use their private registry service instead of using the Docker Hub because you've gone all-in with that provider. That means private repos alone isn't enough to get folks to pay for Docker Hub.
- withinboredom 6y ago
  - Keep the 100 pulls for Docker anon users, but make it monthly. - Every user gets 600 pulls per month for free. - Pre/post pay per pull or buy a rate plan. Something like $100USD === 10,000 pulls on "pay-as-you-go" and prepay could reduce the cost per pull.
- chrissoundz 6y ago
  I think there was a lot of potential to be made in the service/support aspect of containerization of applications - configuring appropriate dependencies etc. Now probably not so much - most people have probably painstakingly learnt the knowledge by now. Maybe even some kind of container marketplace. Otherwise, I don't think it's practical to have docker itself as a commercial product.
- bpfrh 6y ago
  take over supply checks? E.g. make base images for programming languages, systems, etc and guarantee security. I think many small companies would like it a lot better if they got could externalize the cost of running docker images with all their dependencies.
  - jacques_chester 6y ago
    This what Cloud Native Buildpacks do. There are already three major suppliers of these: Heroku, Paketo (by Cloud Foundry folks), and Google Cloud. I'd be pretty thrilled if Docker encouraged buildpack use. It would be a huge win for them.
- 6y ago
greatgib 6y ago
We have seen that a thousand time with google products and co. First, you have unlimited, then you have reasonably large limits. The rational is "limits are needed to reduce abuses and should not impact normal users". Then, it starts to be mandatory to be authenticated. Again, officially for reducing abuses. Once everyone has an account, and are used to limitations, free limits are reduced again, little by little, and finally to the point where you need to take the "pro" offer to have a normal usage.
rhacker 6y ago
Ugh, I don't envy their position. There are many ways to reduce the size of a docker image. I'm guilty too. Probably the best thing to do is leverage multi-stage builds. Those have the largest effect on repo size. (Like a 10x reduction often). The problem is, docker, the company behind the repo, has no control over what Open Source Joe and Developer Suzy are committing and the other developers pulling down their images. They can send out all these notices and announcements, and I think the typical reach of such things probably gets like what, %0.05 percent of the developers it needs to? And of those, are any willing to rewrite the image to be smaller?
- spockz 6y ago
  Well, they could use different rate limits depending on the size of the image. Say if the image size (or the size of the added layers) is in line with what we want for dockers you could offer different rates. Unlimited for images <10MiB, high limits for <100, and low limits for everything else. That way they both push for small images, and keep everyone happy. Or people will just add a proxy/imagestream in between instead of directly pulling from docker hub.
  - efreak 6y ago
    Or you just do it the easy way and limit the speed based on the amount of data downloaded so far, with the history being 'lost' after 6 hours. This way you also prevent someone from doing dumb things to get around it, like using multiple connections (or in this case, multiple layers for a project that doesn't actually need them)
    - spockz 6y ago
      That is possible but it means distributing the total amount of data to all the nodes. Luckily it doesn’t require correctness but it is more complicated to setup regardless.
qaq 6y ago
MS should just buy them and put out of their misery.
rubyn00bie 6y ago
I originally came here to ask how folks use that many docker images in six hours (I'm mostly a Docker n00b, and not being facetious); however, after reading the article, I clicked to see how much unlimited is and it's $5 a month. Now my question has changed to: is $5 a month really a deal breaker for folks to get unlimited? Or what are the use cases where the cost is prohibitive? Open source or community projects? In most cases it would seem $5/user isn't much as a business or organizational expense, and if it's a personal project 200 images in six hours seems pretty solid? I'm just sort of shocked it's so cheap. I figured it'd be like $25-$100 a month or something just because of all the bandwidth someone could probably burn building random/broken shit over and over. I'm mostly curious because I've considered using Docker recently for personal projects and my home server; but I'd rather not invest a bunch of time porting things only to find out it's gonna be way more than $5 (not including my time). Or is it that hard to just build your own images? To be honest, I've never really understood that part of Docker (using other folks images)... It always seemed like an enormous security risk[1]. FWIW, I still deploy my personal projects using chef/ansible, shell scripts, and systemd units like some sort of curmudgeon-y monster... [1] Everything is a security risk (APT, source, etc), I know, I get it. No one need scribe miles of pedantry into the comments explaining it to me. It's what each of us has tolerance for and can accept that matters.
- klodolph 6y ago
  I don’t think anyone who’s adopted systemd can call themselves a curmudgeon :)
  - msla 6y ago
    Sometimes, curmudgeonliness is measured in resistance to changing the default: "Stock CentOS was good enough before and it's good enough now!"
- temikus 6y ago
  It may be general resistance to a concept. More and more services are becoming subscription based, so 5$ here, 5$ there and the cost creeps further.
offbynull 6y ago
Why don't they move to a P2P model? Something like BitTorrent DHT or IPFS? DockerHub itself can just be used if the image is scarce and to penalize free riders.
- viraptor 6y ago
  Ipfs is already implemented. https://blog.bonner.is/docker-registry-for-ipfs/ https://blog.bonner.is/docker-registry-for-ipfs/ But it's on you to use it. (And it doesn't solve the metadata queries the way I understand it)
stevebmark 6y ago
This is good, just like pruning old images. What's bad, and what Docker isn't saying, is it was a mistake to ever allow unlimited free plans. Independent of scale. Setting up an expectation of unlimited free hosting and bandwidth at any point of a business is bad. Tuning knobs of paid hosting and services at all tier levels, with a limited free tier, should have been baked in from the beginning, and would have led to a much stronger business.
- stingraycharles 6y ago
  I don’t think it was a mistake per se, it was part of their growth strategy. Their biggest problem is that they never really managed to capitalize on the market (and kubernetes happened), so now their plan B is to effectively reduce costs of docker hub or get some money out of the people using it. Completely understandable imho.
LockAndLol 6y ago
Yes, good. After reading the comments on their image retention limits [0] talking about simply pulling the images all the time to keep them fresh, this seems like a reasonable response. I'll repeat what I wrote there [1]: If people really think this is a problem, they'd contribute a non-abusive solution. Writing cron jobs to pull periodically in order to artificially reset the timer is abusive. Non-abusive solutions include: - extending docker to introduce reproducible image builds - extending docker push and pull to allow discovery from different sources that use different protocols like IPFS, TahoeLAFS, or filesharing hosts I'm sure you can come up with more solutions that don't abuse the goodwill of people. ----------------------------- Additionally, hosting a local network docker repo would mitigate this rate limit completely. Or straight up pay. It's not that difficult. Getting mad about a free, open-source service becoming pay to use... I couldn't imagine the gall and conceitedness. 0: https://news.ycombinator.com/item?id=24143588 https://news.ycombinator.com/item?id=24143588 1: https://news.ycombinator.com/item?id=24144475 https://news.ycombinator.com/item?id=24144475
- kortex 6y ago
  > introduce reproducible image builds This is a great idea in concept, but in practice very challenging. RUN curl https://www.random.org/integers/?num=1&min=1&max=99999 https://www.random.org/integers/?num=1&min=1&max=99999 Docker will cache this after the first invocation. The build is not reproducible. Now what? Replace "curl random.org" with "nondeterministic and really expensive code build/model training/etc operation". > extending docker push and pull to allow discovery from different sources that use different protocols like IPFS, TahoeLAFS, or filesharing hosts This is great, if you can solve the image integrity/trust issues therein, which should be just some signing/merkle tree work.
alpb 6y ago
Also worth mentioning they added a 6 month retention policy for unpaid accounts. https://www.docker.com/pricing/resource-consumption-updates https://www.docker.com/pricing/resource-consumption-updates If you don't want your images disappearing, you should probably move off of Docker Hub. (That said, I don't think there's any reason to continue using Docker Hub, even with a paid service. I suspect such docker services will be discontinued gradually.) It's not hard to run a registry yourself. https://docs.docker.com/registry/deploying/ https://docs.docker.com/registry/deploying/ Registry supports all sorts of storage backends (files, S3, GCS ...). It's just a stateless HTTP server. It's not hard to configure for production (it comes with decent defaults). If you deploy this to something like Google Cloud Run, you can get ~free hosting (sans the storage costs) for the "registry" itself plus TLS and autoscaling too (I should probably write a tutorial on this).
awinter-py 6y ago
yeah docker is both the best and the worst build tool best because it's hermetic worst because it's wasteful and isn't great at any kind of graph-based step caching (even with buildkit graphs, that's not going to integrate well with your package management and build tool)
jpambrun 6y ago
I see a lot of people mentioning the low cost, saying that it's no big deal. It's not the cost that I find annoying; it's dealing with credentials and secrets..
- LongLiveCHIEF 6y ago
  And docker hub account management and security management options have always been _horrible_. For example, I can't create a login token exclusive to one organization or repo on docker hub, meaning anywhere i use those credentials is a potential security risk to ALL my orgs and projects.
- geerlingguy 6y ago
  Yeah for ephemeral work or CI builds especially, that's the most annoying part (especially for orgs where you might not want to put your personal credentials in repo settings... but you also don't want or have the funding structure to pay the $5/month for unique credentials for that org).
ameyv 6y ago
Smart move by Docker! This will earn them some good bucks.
zelly 6y ago
This is the future of containers: https://guix.gnu.org/ https://guix.gnu.org/ https://nixos.org/ https://nixos.org/ You can build a Docker-compatible image from a Guix or Nix package. You never have to use Docker or Docker Hub. The limitation of Docker is that the nice semi-reproducible sandbox you get exists on top of an operating system that was not designed for it, resulting in giant blobs to get it to work. It's inefficient and a band-aid stopgap until we get to the future where the operating system is a pure function (which can be versioned in a tree, diffed, reverted, etc. just like git). If you used NixOS, you wouldn't need Docker. Sure, it's available and you can use it, but you wouldn't need to.
- stjohnswarts 6y ago
  It works fine though and a lot of companies have valuable time and process built on top of it. However I'm all for natural selection, if these are better products may the the best container win
de_watcher 6y ago
Okay, now can you finally accept patches about the default registry? https://github.com/moby/moby/issues/1988 https://github.com/moby/moby/issues/1988 https://github.com/moby/moby/issues/4324 https://github.com/moby/moby/issues/4324 Or we're still stonewalling?
bandrami 6y ago
The sysadmin in me dies a little bit inside every time I realize there are shops that actually pull images for production from the global registry.
Sir_Substance 6y ago
Hrm, based on this: https://docs.docker.com/docker-hub/orgs/#add-a-member-to-a-team https://docs.docker.com/docker-hub/orgs/#add-a-member-to-a-t... I see that Docker doesn't actually offer an AWS-style enterprise account that one can use to hand authorization to developers without requiring those developers to make individual accounts. It feels pretty sassy of docker to give everyone 2 months to shove credentials everywhere when docker themselves haven't done the minimum to make enterprise accounts realistic. Instead, they're adopting the github model of "oh, just ask everyone to make personal accounts and then include their personal accounts in the org team". That has problems. Firstly, it puts employers in the unpleasant position of attempting to compel employees to make legal agreements with third parties (docker, in this case). The correct way to do this is AWS-style, where the org itself makes /one/ agreement and then delegates that agreement via access keys. This is the minimum I expect from enterprise account systems, hard fail for docker. Secondly, it's a clusterfuck to manage. You end up with an org filled with random-arse account names that you can't really audit, and you don't know who has access to what. If employees leave the org, it's hard to ensure that their access is revoked because the access takes place entirely outside the standard account domains. Github has recently improved this a shade by adding ADFS authorization to org accounts, but that involves asking employees to tie their personal (and all github and docker accounts /are/ personal) account to their work ADFS account, which is a shitty half-solution. All things considered, docker made this problem for themselves. They've spent /years/ working hard to get everyone to make docker accounts and push everything to docker hub instead of fostering an ecosystem of registries by different orgs for different purposes. All of a sudden it's now "too expensive" and they're dropping the hammer on everyone to sign up and push credentials everywhere with very little warning, whilst not doing their half of the work by making a proper delegated authority account system. Doesn't fill me with confidence for their future as a stable platform on which to base a business.

355 points by AaronFriel 6y ago

The real reason this is a problem, is that docker hub has never focused on implementing standard and secure features for account management. Even with the recently implemented access tokens, there's no way for me to limit the scope of those tokens to a specific organization or image, and thus it's no different from a password. That means if I build something from one organization, it's going to impact the ability to build something for another organization. This effort seems to me like they are trying to disguise a last ditch effort to stay afloat. Now that github, gitlab, and other great image repository options exist that don't lack these inherent security/integration features, anyone impacted can easily switch providers for no cost. This new rate limiting won't help anything for docker, it's just going to kick off the exodus away from docker. Ironically, it's this account/security/integration stuff that they lacked focus on that lost them so much financial opportunity to begin with.

LongLiveCHIEF 6y ago

People are also forgetting how newer docker infrastructures use multi-arch and multi-stage builds, meaning a single build could count for dozens of manifest hits, especially with distributed caching. All the things docker has been working for to enhance the build tooling will now be more difficult to use, even if the user never stores a single image of their own on docker hub.

AaronFriel 6y ago

This seems incredibly likely to break development use cases at both extremes: CI/CD systems and developers just starting out could end up pulling quite a few images per hour. Imagine if NPM, Ruby Gems, and so on rate limited package downloads until you paid! I'm not sure if there's a better way to monetize the Docker Hub, but this seems so hostile to adoption.

brian_herman__ 6y ago
Yeah, someone should come up with an alternative that mirrors it or something.
- mirekrusin 6y ago
  Built in torrent and/or ipfs?
  - namibj 6y ago
    The latter has content-dependent chunking support. That would allow for cross-image sharing of common data (large binaries, etc.).
sitkack 6y ago
> Imagine if NPM, Ruby Gems, and so on rate limited package downloads until you paid! Sounds like an entirely reasonable thing to start imagining. Reliability, safety, determinism and predictability are not thrust upon someone from the commons. I frankly find it someone atrocious and abusive that downstream systems do not adequately cache these assets. The main archive repositories should be the source of truth, but they also don't need to be the fountain.
- AaronFriel 6y ago
  Do you think NPM, Ruby Gems, or others would last long if they were so user hostile? Would Node have grown into the genuinely useful development environment it is if free users were limited to 10000 package downloads an hour? It's so unbelievably user hostile that it seems like the result will be people just stop using Docker. The right solution for Docker is probably to spin off or monetize the Hub in a different way. Imagine if GitHub started charging users for git cloning too many packfiles per hour.
  - michaelmrose 6y ago
    All these things cost money to run why would it be surprising if they cost money to utilize their resources beyond a point?

cosmotic 6y ago

I setup a local docker cache using a docker image. The transition to HTTPS everywhere makes caching this sort of thing difficult. One has to install and often manually configure trusted certificates on every client to maximize the cache. APK and APT caches often come hand-in-hand for this sort of thing as the logical next step is to add some OS packages to the pulled image. This also benefits from local caching and also means frustrating cache setup, certificate setup, etc. To maximize local caching there's a lot of manual work to setup a house-of-cards series of proxies that only work on the network. Setting it up on a laptop then traveling means everything breaks in not-so-obvious ways when you leave the network.

solatic 6y ago

Want to see if you're affected? kubectl get pods --all-namespaces -ojson | jq -r '.items[].spec | .containers[] // [] += .initContainers[] // [] | .image' | sort | uniq | less ... and look for anything that's not from a private registry that you control. Give people two months to migrate? What a nightmare.

merb 6y ago
well a shitload of stuff from k8s mostly lies in quay.io or k8s.gcr.io
Dylan16807 6y ago
Giving people over a certain limit two months to migrate or set up a cache or give them a few dollars. What a non-nightmare.

uberman 6y ago

I'm very conflicted about this. On the one hand, I recognize that there are potentially significant costs to be born to serve these repositories. On the other hand, making docker part of your infrastructure requires a certain degree of availability. At some level this seems to me like using my IDE and after 6 hours it would stop working or finding that my CDNJS references to bootstrap stopped working after 6 hours of my site being up. I think it is exactly as if NPM or PIP were to stop working for the day if you included "too many" packages. I don't really have a good feeling for how these new limits might impact setting up new dev/test environments so I'll likely switch from using specific images to using generic images to limit my exposure. For example, at the moment, if I want a new dev container for a project in python, I'll FROM python:latest and supplement with pulls from support service containers like nginx:latest and postgres:latest. Moving forward, it would seem a safer approach will be to use pull a single 18.04 image and run the required installs into them. This super bums me out though as it seems to bypass some of the nicer aspects of getting up and running with docker.

geek_at 6y ago
Well to play devil's advocate if docker is part of your infrastructure and you need to make more than 200 pulls in 6 hours you should already host your own registry and maybe mirror a few dockerhub repos to your own
throwanem 6y ago
Do pulls for a "latest" tag bypass the cache?
- mikepurvis 6y ago
  No they don't, but if you do something silly like spin up a bare VM build node, and then pull your environment every time, then obviously you won't get any caching.
  - ArchOversight 6y ago
    Github Actions? Gitlab CI? Many of those don't do any caching because of the chance of poisoning a tag in the local registry, and don't have a good way to do caching per project. I can imagine that this affects those sorts of operations.

Keverw 6y ago

I kinda wonder if Docker as a company is struggling. Redhat made Podman which is a compatible replacement, Then there's swarm but apparently that's not recommended and actively developed anymore, then as far as I know they sold off their enterprise clustering product. Seems Kubernetes is the popular thing now even if a bit complex to setup. Wonder what the current business model? Pretty neat idea of using containers, but seems they put it out in the wild, got popular and sorta lost control with so many competing options being released.

zapita 6y ago
Yes Docker seems to be struggling as a company. But I doubt Podman has anything to do with it. The adoption of Docker open-source tools is massive and 99% of its users have never heard of podman or any other clones, and likely never will. The problem is simply that those tools are free, and Docker has failed to convert the success of their free tools into a successful business.
- hda111 6y ago
  It’s partly open source and partly freeware. They could just make docker for windows/mac a paid software. I would pay for it if they would listen more to the community when a bug is found. They seem to ignore many bugs Docker Desktop on GitHub. I like about the podman Tools that there is a community effort from Red Hat. It’s not 100% compatible with docker and probably never will. So I will just hope that Microsoft or Canonical buys Docker and make it more open to the Community.
pm90 6y ago
They won the container war but lost the orchestration war. Even if docker compose was successful though, I fail to see how the clouds wouldn’t just replicate everything. So I guess they just failed to monetize the technology.
- zapita 6y ago
  > So I guess they just failed to monetize the technology. Yes, it's really that simple. All those "container wars" and "orchestration wars" are a distraction from the core issue, which is that all those container and orchestration tools are open-source, and it's very hard to build a viable business on top of them. Docker tried and failed, like most startups involved.

jpalomaki 6y ago

I guess CI services like Github Actions could be easily hitting these limits (100 pulls per IP per 6 hours).

eblanshey 6y ago
I'm thinking the same thing. GitLab has shared CI runners that probably do a lot of image pulling. Hopefully they have plans to implement their own docker registry cache.
- tr-gitlab 6y ago
  GitLab PM here - we have a feature called the [Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/ https://docs.gitlab.com/ee/user/packages/dependency_proxy/) that allows you to cache images from DockerHub. Currently this only works for public projects, but we are working on adding support for private projects now: https://gitlab.com/gitlab-org/gitlab/-/issues/11582 https://gitlab.com/gitlab-org/gitlab/-/issues/11582.
lights0123 6y ago
I would imagine that GitHub would work out something with Docker to either pay themselves or have some way of caching images themselves. They could just inject their own TLS certificates into their VMs and then intercept Docker requests for images with their own cache.
jacques_chester 6y ago
I am anecdotally aware of large Concourse installations that have caused individual companies to be blocked entirely from Dockerhub (and which caused "face melting" of Github Enterprise instances). Badly-behaved CI is a serious issue at scale.

pm90 6y ago

I’m hoping GCP/AWS steps up and creates a limitless docker registry. Considering the size of their infrastructure operations, I suspect this would be a small cost but bring a lot of goodwill. One thing this is bound to do is to make the process of using docker a bit more complex. Explicit registries will probably start to be used everywhere, which is something I welcome. But it seems like a really poor decision by docker, the company to do this: they’re going to drive people off using docker hub.

verdverm 6y ago
They have registries already which work with docker after an auth setup. They are generally private to you. Yes, docker is a struggling company which sold some lines of business and is now trying to reinvent itself again towards developers. Given other recent moves, I'm not sure the new leadership understands how to do this.
- forty 6y ago
  They have registries but at least AWS' one is not free at all...
  - verdverm 6y ago
    They all cost money, because it's expensive to ship bytes out of the cloud. Docker is likely going the way of the Dodo because they likely funded our free access with VC money. They also probably made a bad assumption in that they could define the only container format before standards bodies got involved. Blitz Scaling was the mantra of the time, seems to have bitten those back who took a bite of that cake.

obilgic 6y ago

They want you to login, so they have better data for monetization

jacques_chester 6y ago
I think they want you to login because it's hard to monetize anything while hemorrhaging cash to egress fees.

bsamuels 6y ago

There is very little reason for a build node to need to pull 200 images in 6 hours, and here is why: When a machine issues a ``docker build`` command, the program reads the relevant dockerfile to check for any base images that need to be pulled (a la "FROM:") These base images are identified based on the image repository, image name, and image tag. The first thing docker does is it checks its local registry and tries to find a match for the base image the docker build is requesting. If a matching image is located in the local registry, it uses that one in lieu of downloading the image. This is significant - if your organization only uses a few dozen base images from DockerHub, those images will only be downloaded by each build node _once_, then never again. Many docker users erroneously believe that if their Dockerfile requests a "latest" tagged image, docker build will always download the newest version of the image. However, the "latest" tag is literally just a tag, it doesn't have any special functionality built in. If the docker build command finds an image tagged "latest" in the local registry, it stops there. The only way to get docker build to always use the "actual latest" version of the base image is to add the "--pull" parameter to the docker build command. This arg will tell docker build to check the repository remote to see if the SHA hash of the image tagged "latest" has changed, and if so, re-download and use it. In the absolute worst case, this means each build node will pull 1 copy of each base image when the base image is updated. So unless you use 200 different base images that all have updates deployed to Dockerhub each and every day, you are fine.

adrianmsmith 6y ago
> The first thing docker does is it checks its local registry and tries to find a match for the base image the docker build is requesting. If a matching image is located in the local registry, it uses that one in lieu of downloading the image. While I agree that this is the way it's supposed to work, I have unfortunately worked at companies with "stateless" build/CI servers that download the Docker image each build.
- umvi 6y ago
  Well, this policy change will force them to be more efficient, and it's a net win for everyone

theon144 6y ago

Good! I'd even welcome much more agressive limits than what they're proposing; the current culture regarding builds and CI in general is horrifyingly ineffficient, wasteful and in the end just plain slow. I'm looking forward to developers adjusting their workflows (and caches, etc.) to actual, reasonable limits, not just perusing the service as if it were an unlimited cost-free cornucopia of software.

draw_down 6y ago
> the current culture regarding builds and CI in general is horrifyingly ineffficient I used to be in charge of the website for a company you’ve heard of. We once realized some huge proportion of our traffic originated from a hosted CI company requesting the site thousands and thousands of times (guessing one for each build they hosted) every 5 minutes. I can’t remember what proportion of traffic it was but I’m pretty sure it was a majority, maybe even more than 80%.
- userbinator 6y ago
  I sure hope the "cloud first" advocates are happy now, because they have managed to create masses of developers who have next to no idea that what they're doing is an incredible waste of resources. These are also the same people who are perplexed why their systems intermittently fail, or are surprised that they do when the Internet connection cuts out for a bit.
  - draw_down 6y ago
    We just emailed them and asked them to stop. Which they did, and they apologized, but maybe they just changed it to google.com or something which wouldn’t be any less wasteful.
pjmlp 6y ago
I welcome the end of free beer culture, so I am quite alright with their change.
avasthe 6y ago

Havoc 6y ago

Can’t say I’m surprised. They must be incurring significant data costs. The limits seem reasonable at least.

Crazyontap 6y ago

Honest question, but why can't docker use something like bittorrent to download images? Most of us download our OS via torrents only, so we may as well download the images too if there was support for it.

saagarjha 6y ago
> Most of us download our OS via torrents only I mean, I only do it to stick it to the people who claim torrents can only be used for piracy; I think most people prefer the simplicity of direct downloads though…
- bigmanwalter 6y ago
  I can usually max out my connection speed with torrents. This is rarely the case with direct downloads.
  - saagarjha 6y ago
    Guess I just have slow internet :(
  - stingraycharles 6y ago
    The start up time of a torrent is typically so long though, by the time it has connected to all peers and is downloading I have already downloaded the iso with a direct download anyway.
    - stonewareslord 6y ago
      There's a feature of linx-server that provides uploaded files with a torrent URL as well as a regular download URL. I believe the torrent client tries fetching data from peers as well as from linx (http). https://github.com/andreimarcu/linx-server https://github.com/andreimarcu/linx-server
    - namibj 6y ago
      Soon, when QUIC is widely supported by the swarm (just needs updating to the current version), IPFS should be better than torrents for start-up delay, and much more importantly, it allows for sharing data across "torrents" when using content-defined chunking via rabin or buzhash. This means that things like common larger binaries get shared between images that include them, which should greatly increase the average amount of seeders for the chunks that make up an image.

renewiltord 6y ago

Numbers seem reasonable. Does anyone have a quick guide for me to use ECR as a transparent cache or something?

nickjj 6y ago

Does anyone have any good ideas on how the Docker Hub could be monetized in a way that's user friendly and makes sense? AWS, GCP, Azure, DigitalOcean and even GitHub / GitLab all have private container registry offerings. If your stack is on X provider, chances are you're going to use their private registry service instead of using the Docker Hub because you've gone all-in with that provider. That means private repos alone isn't enough to get folks to pay for Docker Hub.

withinboredom 6y ago
- Keep the 100 pulls for Docker anon users, but make it monthly. - Every user gets 600 pulls per month for free. - Pre/post pay per pull or buy a rate plan. Something like $100USD === 10,000 pulls on "pay-as-you-go" and prepay could reduce the cost per pull.
chrissoundz 6y ago
I think there was a lot of potential to be made in the service/support aspect of containerization of applications - configuring appropriate dependencies etc. Now probably not so much - most people have probably painstakingly learnt the knowledge by now. Maybe even some kind of container marketplace. Otherwise, I don't think it's practical to have docker itself as a commercial product.
bpfrh 6y ago
take over supply checks? E.g. make base images for programming languages, systems, etc and guarantee security. I think many small companies would like it a lot better if they got could externalize the cost of running docker images with all their dependencies.
- jacques_chester 6y ago
  This what Cloud Native Buildpacks do. There are already three major suppliers of these: Heroku, Paketo (by Cloud Foundry folks), and Google Cloud. I'd be pretty thrilled if Docker encouraged buildpack use. It would be a huge win for them.
6y ago

greatgib 6y ago

We have seen that a thousand time with google products and co. First, you have unlimited, then you have reasonably large limits. The rational is "limits are needed to reduce abuses and should not impact normal users". Then, it starts to be mandatory to be authenticated. Again, officially for reducing abuses. Once everyone has an account, and are used to limitations, free limits are reduced again, little by little, and finally to the point where you need to take the "pro" offer to have a normal usage.

rhacker 6y ago

Ugh, I don't envy their position. There are many ways to reduce the size of a docker image. I'm guilty too. Probably the best thing to do is leverage multi-stage builds. Those have the largest effect on repo size. (Like a 10x reduction often). The problem is, docker, the company behind the repo, has no control over what Open Source Joe and Developer Suzy are committing and the other developers pulling down their images. They can send out all these notices and announcements, and I think the typical reach of such things probably gets like what, %0.05 percent of the developers it needs to? And of those, are any willing to rewrite the image to be smaller?

spockz 6y ago
Well, they could use different rate limits depending on the size of the image. Say if the image size (or the size of the added layers) is in line with what we want for dockers you could offer different rates. Unlimited for images <10MiB, high limits for <100, and low limits for everything else. That way they both push for small images, and keep everyone happy. Or people will just add a proxy/imagestream in between instead of directly pulling from docker hub.
- efreak 6y ago
  Or you just do it the easy way and limit the speed based on the amount of data downloaded so far, with the history being 'lost' after 6 hours. This way you also prevent someone from doing dumb things to get around it, like using multiple connections (or in this case, multiple layers for a project that doesn't actually need them)
  - spockz 6y ago
    That is possible but it means distributing the total amount of data to all the nodes. Luckily it doesn’t require correctness but it is more complicated to setup regardless.

qaq 6y ago

MS should just buy them and put out of their misery.

rubyn00bie 6y ago

I originally came here to ask how folks use that many docker images in six hours (I'm mostly a Docker n00b, and not being facetious); however, after reading the article, I clicked to see how much unlimited is and it's $5 a month. Now my question has changed to: is $5 a month really a deal breaker for folks to get unlimited? Or what are the use cases where the cost is prohibitive? Open source or community projects? In most cases it would seem $5/user isn't much as a business or organizational expense, and if it's a personal project 200 images in six hours seems pretty solid? I'm just sort of shocked it's so cheap. I figured it'd be like $25-$100 a month or something just because of all the bandwidth someone could probably burn building random/broken shit over and over. I'm mostly curious because I've considered using Docker recently for personal projects and my home server; but I'd rather not invest a bunch of time porting things only to find out it's gonna be way more than $5 (not including my time). Or is it that hard to just build your own images? To be honest, I've never really understood that part of Docker (using other folks images)... It always seemed like an enormous security risk[1]. FWIW, I still deploy my personal projects using chef/ansible, shell scripts, and systemd units like some sort of curmudgeon-y monster... [1] Everything is a security risk (APT, source, etc), I know, I get it. No one need scribe miles of pedantry into the comments explaining it to me. It's what each of us has tolerance for and can accept that matters.

klodolph 6y ago
I don’t think anyone who’s adopted systemd can call themselves a curmudgeon :)
- msla 6y ago
  Sometimes, curmudgeonliness is measured in resistance to changing the default: "Stock CentOS was good enough before and it's good enough now!"
temikus 6y ago
It may be general resistance to a concept. More and more services are becoming subscription based, so 5$ here, 5$ there and the cost creeps further.

offbynull 6y ago

Why don't they move to a P2P model? Something like BitTorrent DHT or IPFS? DockerHub itself can just be used if the image is scarce and to penalize free riders.

viraptor 6y ago
Ipfs is already implemented. https://blog.bonner.is/docker-registry-for-ipfs/ https://blog.bonner.is/docker-registry-for-ipfs/ But it's on you to use it. (And it doesn't solve the metadata queries the way I understand it)

stevebmark 6y ago

This is good, just like pruning old images. What's bad, and what Docker isn't saying, is it was a mistake to ever allow unlimited free plans. Independent of scale. Setting up an expectation of unlimited free hosting and bandwidth at any point of a business is bad. Tuning knobs of paid hosting and services at all tier levels, with a limited free tier, should have been baked in from the beginning, and would have led to a much stronger business.

stingraycharles 6y ago
I don’t think it was a mistake per se, it was part of their growth strategy. Their biggest problem is that they never really managed to capitalize on the market (and kubernetes happened), so now their plan B is to effectively reduce costs of docker hub or get some money out of the people using it. Completely understandable imho.

LockAndLol 6y ago

Yes, good. After reading the comments on their image retention limits [0] talking about simply pulling the images all the time to keep them fresh, this seems like a reasonable response. I'll repeat what I wrote there [1]: If people really think this is a problem, they'd contribute a non-abusive solution. Writing cron jobs to pull periodically in order to artificially reset the timer is abusive. Non-abusive solutions include: - extending docker to introduce reproducible image builds - extending docker push and pull to allow discovery from different sources that use different protocols like IPFS, TahoeLAFS, or filesharing hosts I'm sure you can come up with more solutions that don't abuse the goodwill of people. ----------------------------- Additionally, hosting a local network docker repo would mitigate this rate limit completely. Or straight up pay. It's not that difficult. Getting mad about a free, open-source service becoming pay to use... I couldn't imagine the gall and conceitedness. 0: https://news.ycombinator.com/item?id=24143588 https://news.ycombinator.com/item?id=24143588 1: https://news.ycombinator.com/item?id=24144475 https://news.ycombinator.com/item?id=24144475

kortex 6y ago
> introduce reproducible image builds This is a great idea in concept, but in practice very challenging. RUN curl https://www.random.org/integers/?num=1&min=1&max=99999 https://www.random.org/integers/?num=1&min=1&max=99999 Docker will cache this after the first invocation. The build is not reproducible. Now what? Replace "curl random.org" with "nondeterministic and really expensive code build/model training/etc operation". > extending docker push and pull to allow discovery from different sources that use different protocols like IPFS, TahoeLAFS, or filesharing hosts This is great, if you can solve the image integrity/trust issues therein, which should be just some signing/merkle tree work.

alpb 6y ago

Also worth mentioning they added a 6 month retention policy for unpaid accounts. https://www.docker.com/pricing/resource-consumption-updates https://www.docker.com/pricing/resource-consumption-updates If you don't want your images disappearing, you should probably move off of Docker Hub. (That said, I don't think there's any reason to continue using Docker Hub, even with a paid service. I suspect such docker services will be discontinued gradually.) It's not hard to run a registry yourself. https://docs.docker.com/registry/deploying/ https://docs.docker.com/registry/deploying/ Registry supports all sorts of storage backends (files, S3, GCS ...). It's just a stateless HTTP server. It's not hard to configure for production (it comes with decent defaults). If you deploy this to something like Google Cloud Run, you can get ~free hosting (sans the storage costs) for the "registry" itself plus TLS and autoscaling too (I should probably write a tutorial on this).

awinter-py 6y ago

yeah docker is both the best and the worst build tool best because it's hermetic worst because it's wasteful and isn't great at any kind of graph-based step caching (even with buildkit graphs, that's not going to integrate well with your package management and build tool)

jpambrun 6y ago

I see a lot of people mentioning the low cost, saying that it's no big deal. It's not the cost that I find annoying; it's dealing with credentials and secrets..

LongLiveCHIEF 6y ago
And docker hub account management and security management options have always been _horrible_. For example, I can't create a login token exclusive to one organization or repo on docker hub, meaning anywhere i use those credentials is a potential security risk to ALL my orgs and projects.
geerlingguy 6y ago
Yeah for ephemeral work or CI builds especially, that's the most annoying part (especially for orgs where you might not want to put your personal credentials in repo settings... but you also don't want or have the funding structure to pay the $5/month for unique credentials for that org).

ameyv 6y ago

Smart move by Docker! This will earn them some good bucks.

zelly 6y ago

This is the future of containers: https://guix.gnu.org/ https://guix.gnu.org/ https://nixos.org/ https://nixos.org/ You can build a Docker-compatible image from a Guix or Nix package. You never have to use Docker or Docker Hub. The limitation of Docker is that the nice semi-reproducible sandbox you get exists on top of an operating system that was not designed for it, resulting in giant blobs to get it to work. It's inefficient and a band-aid stopgap until we get to the future where the operating system is a pure function (which can be versioned in a tree, diffed, reverted, etc. just like git). If you used NixOS, you wouldn't need Docker. Sure, it's available and you can use it, but you wouldn't need to.

stjohnswarts 6y ago
It works fine though and a lot of companies have valuable time and process built on top of it. However I'm all for natural selection, if these are better products may the the best container win

de_watcher 6y ago

Okay, now can you finally accept patches about the default registry? https://github.com/moby/moby/issues/1988 https://github.com/moby/moby/issues/1988 https://github.com/moby/moby/issues/4324 https://github.com/moby/moby/issues/4324 Or we're still stonewalling?

bandrami 6y ago

The sysadmin in me dies a little bit inside every time I realize there are shops that actually pull images for production from the global registry.

Sir_Substance 6y ago

Hrm, based on this: https://docs.docker.com/docker-hub/orgs/#add-a-member-to-a-team https://docs.docker.com/docker-hub/orgs/#add-a-member-to-a-t... I see that Docker doesn't actually offer an AWS-style enterprise account that one can use to hand authorization to developers without requiring those developers to make individual accounts. It feels pretty sassy of docker to give everyone 2 months to shove credentials everywhere when docker themselves haven't done the minimum to make enterprise accounts realistic. Instead, they're adopting the github model of "oh, just ask everyone to make personal accounts and then include their personal accounts in the org team". That has problems. Firstly, it puts employers in the unpleasant position of attempting to compel employees to make legal agreements with third parties (docker, in this case). The correct way to do this is AWS-style, where the org itself makes /one/ agreement and then delegates that agreement via access keys. This is the minimum I expect from enterprise account systems, hard fail for docker. Secondly, it's a clusterfuck to manage. You end up with an org filled with random-arse account names that you can't really audit, and you don't know who has access to what. If employees leave the org, it's hard to ensure that their access is revoked because the access takes place entirely outside the standard account domains. Github has recently improved this a shade by adding ADFS authorization to org accounts, but that involves asking employees to tie their personal (and all github and docker accounts /are/ personal) account to their work ADFS account, which is a shitty half-solution. All things considered, docker made this problem for themselves. They've spent /years/ working hard to get everyone to make docker accounts and push everything to docker hub instead of fostering an ecosystem of registries by different orgs for different purposes. All of a sudden it's now "too expensive" and they're dropping the hammer on everyone to sign up and push credentials everywhere with very little warning, whilst not doing their half of the work by making a proper delegated authority account system. Doesn't fill me with confidence for their future as a stable platform on which to base a business.