Libelektra: Docker: Pull-Rate-Limit erreicht.

Unser Build-Server sollte eigentlich nur aus unserer privaten Docker-Registry ziehen, niemals von docker.org.

Ist das Problem vielleicht nur eine Einstellung die wir auf hub.libelektra.org nicht geändert haben? Oder gibt es Bilder, die auf hub.libelektra.org nicht gespiegelt sind?

@robaerd kannst du bitte mal nachschauen? Es ist dringend, da es sich auf unsere Builds auswirkt.

Oder gibt es Bilder, die auf hub.libelektra.org nicht gespiegelt sind?

Es scheint, dass es immer nach aktualisierten Basis-Images sucht, die sich nicht auf unserem Hub befinden ...

Es scheint, dass es immer nach aktualisierten Basis-Images sucht, die sich nicht auf unserem Hub befinden ...

Dies ist Teil des monatlichen Rebuilds der Docker-Images, da der Monat Teil der Image-ID ist.

Die Docker-Images werden derzeit wieder zwischengespeichert, daher sollte kein Rebuild der Docker-Images erfolgen und daher sollte der Fehler mindestens diesen Monat nicht erneut auftreten.

Ich bin mir immer noch nicht sicher, wie wir das 100-Pull-Limit mit unseren ~ 14 Docker-Images überschreiten könnten.

Vielen Dank, dass Sie sich damit befasst haben. :sparkling_heart: Ja, es sieht ein bisschen komisch aus: Wenn es nur 14 Docker-Images sind und wir nur monatlich ziehen, sollten wir weit unter jeder Grenze sein?

Es scheint, dass es immer nach aktualisierten Basis-Images sucht, die sich nicht auf unserem Hub befinden ...

Ist hub.libelektra.org so konfiguriert: https://docs.docker.com/registry/recipes/mirror ? Wenn ja, sollte die Überprüfung, ob das Image aktuell ist, nach meinem Verständnis nur auf das Kontingent angerechnet werden, wenn wirklich ein neues Image gezogen werden muss.

Der einfachste Weg, das Kontingent zu umgehen, besteht darin, ein Docker Hub-Konto für das CI zu erstellen. Es gibt ein Open-Source-Programm , also wären wir wahrscheinlich für ein unbegrenztes Konto berechtigt.

Ich könnte die Bewerbung machen, wenn es hilft. Aber zuerst sollten wir herausfinden, was eigentlich das Problem ist.

Ich weiß nicht, wie Docker Hub das Ratenlimit verfolgt. Ich gehe davon aus, dass es auf IP basiert, sonst wäre es zu einfach, lokal zurückzusetzen. Ist in diesem Fall unser Build-Server das einzige, was Docker Hub über diese IP erscheinen würde?

Ja, der Build-Server hat eine dedizierte IP, sogar mehrere, und das CI ist der einzige Teil, der Docker verwendet.

Wenn es nur 14 Docker-Images sind und wir nur monatlich ziehen, sollten wir weit unter jedem Limit sein?

Es scheint, dass die Jenkins-Pipeline einen Job ausführt (ich denke für die Website), der ständig versucht, aus Docker Hub zu ziehen: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3589 /5/Pipeline/696

AFAIK passiert dies aufgrund der Verwendung von build --pull .

Wir sollten wahrscheinlich nur build (ohne --pull ) standardmäßig verwenden und es wöchentlich oder monatlich mit --pull ausführen.

Danke, dass du es herausgefunden hast! :funkelndes_herz:

Vielen Dank, dass Sie die Ursache für dieses Problem gefunden haben!

Alternativ zum Entfernen von --pull könnten wir auch ein Basis-Image für die Webui-Basis erstellen, ohne dass elektra noch installiert ist (nur mit installierten Abhängigkeiten und gtests). Dieses Basis-Image würde dann - wie die anderen - monatlich erstellt und das Webui-Basis-Image würde sich aus diesem Basis-Image erweitern und nur aus unserer privaten Docker-Registry ziehen (und würde dadurch das Pull-Limit nicht beeinflussen)

webui base noch ohne elektra installiert

Ich mag diese Idee! Unabhängig von den Docker-Pull-Limits wäre dies eine Verbesserung!

webui base noch ohne elektra installiert

Ja das wäre auch eine Option. Das fragliche Bild ist bereits das Basisbild für die tatsächlichen webui und elektrad Bilder. So konnten wir das Kopieren und Bauen von Elektra einfach in die anderen Dockerfiles verschieben. Oder gibt es vielleicht eine Lösung mit mehrstufigen Builds? Nicht sicher, ob Zwischenstufen in Register verschoben/aus Registern gezogen werden können.

Gestern habe ich die Shared Library auf Jenkins getestet, wo nur die Pull-Stage ausgeführt wurde. Kein Image-Building, nur das Ziehen aus unserer privaten Docker-Registry unter hub.libelektra.org und ich habe immer noch den Fehler Docker Rate Limit. Ich habe etwas genauer nachgesehen und es geschafft, die Ursache unseres Problems zu finden.
Es ist watchtower , ein Container, der ausgeführt wird und unsere Bilder in bestimmten Intervallen aktualisiert. Dieses Problem sollte in der neuesten Version behoben
Auch die Protokolle des Wachturmcontainers bestätigen meine Vermutung.

time="2020-11-16T22:22:58Z" level=info msg="Unable to update container /frontend_repo_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:22:59Z" level=info msg="Unable to update container /frontend_registry_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:00Z" level=info msg="Unable to update container /frontend_letsencrypt-nginx-proxy-companion_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:01Z" level=info msg="Unable to update container /frontend_nginx-proxy_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:02Z" level=info msg="Unable to update container /frontend_watchtower_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:04Z" level=info msg="Unable to update container /frontend_libelektra-webui_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:28Z" level=info msg="Unable to update container /frontend_repo_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:29Z" level=info msg="Unable to update container /frontend_registry_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."
time="2020-11-16T22:23:30Z" level=info msg="Unable to update container /frontend_letsencrypt-nginx-proxy-companion_1, err='Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'. Proceeding to next."

Vielen Dank, dass du es herausgefunden hast :sparkling_heart:

@robaerd können wir das schließen oder ist noch etwas zu tun?

Alle Docker-Images, die in der Artefaktphase (Webui, Website, Pakettests) verwendet werden, werden weiterhin von docker.org anstelle unserer privaten Registrierung abgerufen. Ich denke, dies sollte wahrscheinlich in einer separaten Ausgabe behandelt werden, da wir damit niemals das Docker-Pull-Limit überschreiten würden. Aber seit dem Wachturm-Image-Update sollte dieses Problem behoben sein und IMHO kann geschlossen werden.

Vermutlich muss nichts mehr gemacht werden. Wenn wir die Grenzen nicht erreichen, ist es imho in Ordnung, von docker.org zu ziehen.