Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOCS: Does a check trigger the docker hub rate limits? #73

Open
scyto opened this issue May 6, 2022 · 7 comments
Open

DOCS: Does a check trigger the docker hub rate limits? #73

scyto opened this issue May 6, 2022 · 7 comments

Comments

@scyto
Copy link

scyto commented May 6, 2022

This might be a dumb question

I am about to implement shepherd in my swarm.
Currently it has 28 containers across 25 services.

Will each check every 5 mins trip the rate limit counter, or just pulls on an image change?

The images don't change frequently - often for weeks at a time.

@djmaze
Copy link
Collaborator

djmaze commented May 22, 2022

If you look at the definition, it seems yes, the rate limit will be affected unfortunately.

@stale
Copy link

stale bot commented Sep 21, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Sep 21, 2022
@Vaults
Copy link

Vaults commented Oct 25, 2022

I can confirm every check is an addition to the rate limit. However, I do have a workaround which is quite some work but worth it:

  • Configure a secure pull-through registry at a domain you control, example: https://domain.com
  • Transfer all your services from using image <user>/<docker-image> to domain.com/<user>/<docker-image> or in the case when the image is official and has no user, like nginx for example from nginx to domain.com/library/nginx

With the amount that Shepherd pulls it is wise to configure your own private registry and build your own images anyway to prevent more pulls. Unfortunately all the apis that circumvent this and can be used just to check if there's a new image are paid.

After having implemented this workaround, imagine 6 services which all use the nginx docker image divided over three machines. A single shepherd update of that set of services alone can cost over a whopping 18 pulls. Barring crazy states where every service has wildly varying versions, the workaround brings it back down to a single pull, which doesn't count double, triple etc. when repeated if there's no upstream updates. So in that case, you would need 200 seperate image/tag combos to be updated upstream every 6 hours to hit the limit in which case I think it would be fair if one started thinking about payment..

@stale stale bot removed the wontfix label Oct 25, 2022
@shizunge

This comment was marked as spam.

@madmurl0c
Copy link

@Vaults Are you sure that you have to rewrite all the images? Can't you just define registry-mirrors to the docker process?

I've been using a docker mirror for a while but it doesn't seem to be used by shepherd although I mounted /etc/docker/daemon.json:/etc/docker/daemon.json:ro.

The /etc/docker/daemon.json looks like this:

{
  "registry-mirrors": ["https://docker-mirror01.company.lan:5001"]
}

It works on the host but it doesn't work in the container. Is there any way to set the --registry-mirrors parameter or use $DOCKER_OPTS inside the image?

@moschlar
Copy link
Collaborator

moschlar commented Mar 8, 2024

@madmurl0c The problem is basically the docker manifest inspect call that shepherd issues beforehand to determine whether it need to trigger a service update at all. Since that call is just done "client side" by the docker cli in the container, it has no knowledge of the configured registry mirrors of the daemon on the host (though it could probably try to find that out...).

Will keep this open until we thought of a solution!

@mrambossek
Copy link

no solution yet? :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants