5 ms·

I don't disagree with what you are saying, _but_: > Docker defines pull rate limits as the number of manifest requests to Docker Hub. > For example, if you al

I don't disagree with what you are saying, _but_: > Docker defines pull rate limits as the number of manifest requests to Docker Hub. > For example, if you already have the image, the Docker Engine client will issue a manifest request, realize it has all of the referenced layers based on the returned manifest, and stop. ... <excluded> ... So an image pull is actually one or two manifest requests, This still implies that even if you are appropriately re-using layers on your machine, with a free plan you can only do maximum 200 builds (since docker still needs to verify it has the image) per 6 hours? This change also seems to imply that builds steps which previously did not handle/require authentication against Docker hub (it was only pulling public images, and pushing elsewhere) will now be required to auth against docker hub in order to double the number of pulls/checks/builds it is allowed?

bsamuels 6y ago
This is an excellent point. Trying to find out if docker build --pull without an accompanying blob download will trigger the rate limiter. If it does, then this will definitely be a reason to riot. It will effectively mean that anyone who wants to do more than 200 builds every 6 hours using the "right" way will have to get a docker pro subscription.
- nrmitchi 6y ago
  It sounds like it definitely does trigger the rate limiter. > There is a small tradeoff – if you pull an image you already have, this is still counted even if you don’t download the layers. I expect we're just going to see a lot more recycling of build nodes once it has "used up it's docker credits".
  - heavenlyblue 6y ago
    All reasonable orgs should have had their private docker repo a long time ago. Everybody else is living the pipe dream where they have externalised their risk and probably deserve the Docker treatment.
    - jhenkens 6y ago
      Agreed. Third party package repositories has been a weak point in our CI, and we put all of them behind a self-hosted proxy that we can manage in our own HA fasion. Turns out we get faster pulls from it, as well as being a good internet-citizen.
    - Spivak 6y ago
      Yes but Docker achieved their goal of making it annoying as hell to not user DockerHub. Because you can run your own private repo just fine but what you want is a transparent proxy (like apt-catcher) that will let you pretend you’re using DH but actually pulling from either the cache or your private repos. All the pieces are there with private repos and “pullthrough” proxies they’re just not well integrated, seemingly on purpose. RedHat’s patches to Docker make this possible but Docker has refused to upstream it.
      - heavenlyblue 6y ago
        > annoying as hell to not user DockerHub Why? All your need to do is to use your domain name when referencing the image.
- dannyw 6y ago
  If you do 200 builds every 6 hours, you could probably afford to pay $5 a month.
userbinator 6y ago
I admittedly have only used Docker very little, but how exactly does someone manage to build images once every 108 seconds continuously for 6 hours? That sounds extreme.
- deleted 6y ago
  [deleted]
- terom 6y ago
  Easily with CI. Every pull request on the GitHub project will build a dozen Docker images whenever a PR is opened, updated or merged. Granted, there's only a couple base images involved, so CI pipelines will need updating to be more efficient in terms of `docker build --pull` usage.
deleted 6y ago
[deleted]

bsamuels 6y ago

This is an excellent point. Trying to find out if docker build --pull without an accompanying blob download will trigger the rate limiter. If it does, then this will definitely be a reason to riot. It will effectively mean that anyone who wants to do more than 200 builds every 6 hours using the "right" way will have to get a docker pro subscription.

nrmitchi 6y ago
It sounds like it definitely does trigger the rate limiter. > There is a small tradeoff – if you pull an image you already have, this is still counted even if you don’t download the layers. I expect we're just going to see a lot more recycling of build nodes once it has "used up it's docker credits".
- heavenlyblue 6y ago
  All reasonable orgs should have had their private docker repo a long time ago. Everybody else is living the pipe dream where they have externalised their risk and probably deserve the Docker treatment.
  - jhenkens 6y ago
    Agreed. Third party package repositories has been a weak point in our CI, and we put all of them behind a self-hosted proxy that we can manage in our own HA fasion. Turns out we get faster pulls from it, as well as being a good internet-citizen.
  - Spivak 6y ago
    Yes but Docker achieved their goal of making it annoying as hell to not user DockerHub. Because you can run your own private repo just fine but what you want is a transparent proxy (like apt-catcher) that will let you pretend you’re using DH but actually pulling from either the cache or your private repos. All the pieces are there with private repos and “pullthrough” proxies they’re just not well integrated, seemingly on purpose. RedHat’s patches to Docker make this possible but Docker has refused to upstream it.
    - heavenlyblue 6y ago
      > annoying as hell to not user DockerHub Why? All your need to do is to use your domain name when referencing the image.
dannyw 6y ago
If you do 200 builds every 6 hours, you could probably afford to pay $5 a month.

userbinator 6y ago

I admittedly have only used Docker very little, but how exactly does someone manage to build images once every 108 seconds continuously for 6 hours? That sounds extreme.

deleted 6y ago
[deleted]
terom 6y ago
Easily with CI. Every pull request on the GitHub project will build a dozen Docker images whenever a PR is opened, updated or merged. Granted, there's only a couple base images involved, so CI pipelines will need updating to be more efficient in terms of `docker build --pull` usage.

deleted 6y ago

[deleted]