back to article Ready for pull rate limits? Docker outlines 'next chapter' as Google tells customers how to dodge subscriptions

From 1 November, Docker will clap limits on how many container images free users can pull from its Docker Hub before requests are declined, a move that could cause problems for users of public cloud platforms. Docker stated in August that anonymous users will be limited to 100 container image pulls per six hours, and …

  1. RichardBarrell

    Hm. I hope this works out for them. It sounds like it might have a reasonable shot at being a steady revenue source.

    Usage based pricing is straightforward and makes sense. The free limits mentioned here are high enough that I couldn't plausibly see myself as a developer hitting them at any point. "docker pull" takes a minimum of 5 minutes for me, so no way am I managing to do that 100x in the space of 360 minutes.

    1. NeilPost Silver badge

      Yes... production users could - you know - actually pay a little for something instead of freeloading.

  2. MNB

    Caching?

    Surely people with serious CI/CD pipelines in the cloud would be caching their docker images to properly implement configuration *control*?

    Or am I more overly cautious than your average cloud native commentard?

    1. Anonymous Coward
      Anonymous Coward

      Re: Caching?

      No one could possibly be pulling untested images into a production environment. That would be ..... brave

      1. Cederic Silver badge

        Re: Caching?

        Thanks, I was worried I was an outlier for a moment there.

        100 images per six hours? 100 images per six weeks wouldn't be a major cause for concern. Don't people use their own container repositories for their own images and third party images that they've validated, security checked and tested?

    2. MatthewSt Silver badge

      Re: Caching?

      Because the images have a hash based on their contents it doesn't matter _where_ you pull them down from as long as you've validated the hash. They're effectively signed (unless there's a weakness/collision discovered).

      On the flip side of this, they should be the easiest thing in the world to cache, because you're downloading them based on a request that indicates the contents that you want to download. The image for a particular hash will _never_ change, so your caching can be based off LRU and you're sorted.

      Even Microsoft have worked out how to do this, and their build agents have a certain number of popular images cached _on the build server itself_.

    3. Tom 38 Silver badge

      Re: Caching?

      Docker doesn't make it easy to add caching. Lets say you have a common ci setup, with a private registry that you pull/push your built images to, and pulling public images from docker hub.

      You can only configure docker to use a single upstream cache, so if you do, your cache also has to handle the authenticated requests as well as the public ones, as everything will go through the cache - this means injecting your private docker credentials into the cache. Typically, your CI task will run with credentials that only give it access to the images for that particular repository - now it has access to everything.

      Then, there's the matter of local docker caches. Your CI itself is probably running inside of docker (docker in docker). If you expose the host machine's docker daemon to the docker containers running your CI task, then any private images pulled/built by different tasks will be available to any other CI job running on the same host. That's a security nightmare, so in most cases you run without the host docker daemon being visible, and therefore each job starts with a completely empty docker image cache.

      See https://github.com/tiangolo/docker-registry-proxy#docker-itself-should-provide-this. It could be easier, but docker want to push people in to using them as their private docker registry (in which case everything works great). Don't want to use docker as your private registry? Harder. Restricting public pulls when they've engineered it to make it harder to cache public pulls IMO is a cynical drive to get people to use their private registry services.

      1. CrackedNoggin

        Re: Caching?

        Serious users paying $5~7 dollars a month for unlimited is not that cynical, I think. The company has to survive. The price might not be right however. They might try adding $12 a year + micro-fees per download as an alternative - makes more sense to have a bandwidth charge.

        And there you have provided the workaround - https://github.com/tiangolo/docker-registry-proxy#docker-itself-should-provide-this - if you can trust it.

        I pulled the docker version of "verdaccio" (which is the open source self-hosting server for npm). Ironically, starting verdaccio on docker up maxed out CPU usage indefinitely and I had no easy way to figure out was happening. (Ironic because verdaccio is to npm what docker-registry-proxy is to docker, almost). So I installed the apt version of verdaccio on a LXC (linux container) instead and it works fine. (Note: It probably wasn't the container that was the problem, but I don't KNOW that, and that's a problem.)

        So I would say the bigger problem for serious users is verifying content of docker containers.

  3. Claptrap314 Silver badge

    In other news, grass is green

    Their business plan is the path forged by the likes of Google. The transition is always dicey, I wish them luck.

    If you don't understand that a single docker pull command can result in more than 100 image pulls, you don't understand a thing about docker. Of course, for many reasons, the better images will have a much smaller set of pulls, but there is _no_ guarantee.

    ANY company that has a business-critical dependency on an outside free service deserves to have the tap turned off at the worst possible time.

    For this particular service, there is NO excuse for the production pipeline to be making outside pulls. That unacceptable from a security standpoint, let alone a reliability one.

  4. Henry Wertz 1 Gold badge

    Cache?

    Seems like you'd be able to use some kind of cache; I mean, I doubt you're deploying 100 different images in that 6 hours, it'd be 100 of the same image (or a few images). Seems like you'd REALLY want to cache that somewhere for speed purposes if nothing else. Must admit, I can't think of how I'd burn through like 16 Docker images an hour either.

    (Edit: Didn't notice the thread on caching just above. But seriously, who would not want to use a cache if they're doing more than an occasional Docker pull?)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021