3 ms·

Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot - You would/should be caching most of the images from dockerhub anyways, so subsequential builds shou

by Sahbak 6y ago

Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot - You would/should be caching most of the images from dockerhub anyways, so subsequential builds shouldn't count against your limit.

szszrk 6y ago
Internal repo that does caching of images is rather obvious and a good practice, but it still doesn't mean that 100 pulls are that many. Maybe we understand something different by a "small" team, but IMHO a smaller team uses more ready public images, to save time and costs. Also even not that big project on Kubernetes that includes internal software will also have a lot of other software. Let's speculate: I had a look at some teams I know and how they work (or they would like to work soon) and it's easily 15-30 images in a CI/CD pipeline. Plus tools used to develop, but not exactly released in a build (source code management, PM, communication etc). All teams I know have 2-3 cycles developed at all times (next release, hotfix, future release after the next one). This means a lot of these tools are multiplied by 2-3 (upgrading tools as well, so multiple versions of same tool needed). If you have a few clusters that have different requirements it can also be multiplied by 2 or 3. I would not dare to think what would happen if someone used "latest" tag in their daily work, or organized a docker/kubernetes workshop for new people :)
barumi 6y ago
> Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot It really depends on your usecase. I mean, each CICD stage can involve building a brand new image and running a couple of them, sometimes more. 100 pulls per 6 hours corresponds to a constant rate of 3 min between pulls, which would require between 15 to 20 minutes for each commit. Anyway, the primary practical implications of this sort of change is a) rate limiting suddenly becomes a requirement, b) we can no longer count on Docker Hub to provide a reliable service, thus we plan accordingly.
robrtsql 6y ago
At one point, Docker's announcement said that all 'docker pull' requests would count towards the rate limit, even if you had every layer cached and no layers ended up being downloaded. I may be wrong but I interpreted that to mean that even caching won't prevent you from hitting the limit.

by Sahbak 6y ago

Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot - You would/should be caching most of the images from dockerhub anyways, so subsequential builds shouldn't count against your limit.

szszrk 6y ago

Internal repo that does caching of images is rather obvious and a good practice, but it still doesn't mean that 100 pulls are that many. Maybe we understand something different by a "small" team, but IMHO a smaller team uses more ready public images, to save time and costs. Also even not that big project on Kubernetes that includes internal software will also have a lot of other software. Let's speculate: I had a look at some teams I know and how they work (or they would like to work soon) and it's easily 15-30 images in a CI/CD pipeline. Plus tools used to develop, but not exactly released in a build (source code management, PM, communication etc). All teams I know have 2-3 cycles developed at all times (next release, hotfix, future release after the next one). This means a lot of these tools are multiplied by 2-3 (upgrading tools as well, so multiple versions of same tool needed). If you have a few clusters that have different requirements it can also be multiplied by 2 or 3. I would not dare to think what would happen if someone used "latest" tag in their daily work, or organized a docker/kubernetes workshop for new people :)

barumi 6y ago

> Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot It really depends on your usecase. I mean, each CICD stage can involve building a brand new image and running a couple of them, sometimes more. 100 pulls per 6 hours corresponds to a constant rate of 3 min between pulls, which would require between 15 to 20 minutes for each commit. Anyway, the primary practical implications of this sort of change is a) rate limiting suddenly becomes a requirement, b) we can no longer count on Docker Hub to provide a reliable service, thus we plan accordingly.

robrtsql 6y ago

At one point, Docker's announcement said that all 'docker pull' requests would count towards the rate limit, even if you had every layer cached and no layers ended up being downloaded. I may be wrong but I interpreted that to mean that even caching won't prevent you from hitting the limit.