3 ms·

> If your CI is doing more than 100 pulls and you have a "small team" then you must be doing something wrong. Most CI systems poll to see if there are new vers

> If your CI is doing more than 100 pulls and you have a "small team" then you must be doing something wrong. Most CI systems poll to see if there are new versions of an image. If this is done with a GET request (to get the manifest as a first step towards pulling layers), it counts towards the rate limiting. > Has this mentality not continued into the Docker era? It seems pretty easy to set up [0] and has all kinds of advantages even without the upcoming limit. Maven separates the domain of a Maven repository from the coordinates of packages. Docker does not. Dockerhub's domain is inferred into any shorthand reference like `foo/bar`, meaning that it will ignore a pull-through cache. You can ostensibly configure a docker daemon to treat another registry as a trusted mirror, but it's harder than it looks in practice, because on most production systems that won't (and shouldn't) be enabled.

franga2000 6y ago
Ok, if just checking whether a newer version is available counts towards the rate limit, than that is just completely insane! EDIT: Yeah, that makes sense given the protocol's design. Anyways, HEAD requests don't count, so hopefully the client can utilise those (or be modified to). [/EDIT] And yes, Maven has a design much better suited to having a local "proxy" (in fact, it always does that on localhost anyways), but the setup looks pretty straightforward and I really don't see much reason to not use it on all dev, test and CI machines. I'd also use it in production, but even if you'd prefer not to, production servers don't pull that often and updates are usually done through hooks, not constantly polling a repo. So basically, from my perspective (handful of servers, each with some 20 containers) this change will be thoroughly annoying, but will force me to set up caching which will make things much faster and also decrease the reliance on an external service for day-to-day operation. Not a fan of it, but yi completely see the reason why they did it.
- jacques_chester 6y ago
  My point is that the name of the image and the location of the registry are mixed together. If it was easy to do cache hierarchies folks wouldn't be so fussed.
  - franga2000 6y ago
    Yes, that was a rather unfortunate design choice...

franga2000 6y ago

Ok, if just checking whether a newer version is available counts towards the rate limit, than that is just completely insane! EDIT: Yeah, that makes sense given the protocol's design. Anyways, HEAD requests don't count, so hopefully the client can utilise those (or be modified to). [/EDIT] And yes, Maven has a design much better suited to having a local "proxy" (in fact, it always does that on localhost anyways), but the setup looks pretty straightforward and I really don't see much reason to not use it on all dev, test and CI machines. I'd also use it in production, but even if you'd prefer not to, production servers don't pull that often and updates are usually done through hooks, not constantly polling a repo. So basically, from my perspective (handful of servers, each with some 20 containers) this change will be thoroughly annoying, but will force me to set up caching which will make things much faster and also decrease the reliance on an external service for day-to-day operation. Not a fan of it, but yi completely see the reason why they did it.

jacques_chester 6y ago
My point is that the name of the image and the location of the registry are mixed together. If it was easy to do cache hierarchies folks wouldn't be so fussed.
- franga2000 6y ago
  Yes, that was a rather unfortunate design choice...