Libelektra: Docker : limite de taux de traction atteinte.

Notre serveur de build ne devrait en fait tirer que de notre registre docker privé, jamais de docker.org.

Le problème n'est-il peut-être qu'un paramètre que nous n'avons pas modifié sur hub.libelektra.org ? Ou y a-t-il des images qui ne sont pas reflétées sur hub.libelektra.org ?

@robaerd pouvez-vous jeter un oeil s'il vous plaît? C'est urgent, car cela affecte nos constructions.

Ou y a-t-il des images qui ne sont pas reflétées sur hub.libelektra.org ?

Il semble qu'il vérifie toujours les images de base mises à jour qui ne sont pas sur notre hub...

Il semble qu'il vérifie toujours les images de base mises à jour qui ne sont pas sur notre hub...

Cela fait partie de la reconstruction mensuelle des images docker, puisque le mois fait partie de l'identifiant de l'image.

Les images docker sont actuellement à nouveau mises en cache, donc aucune reconstruction des images docker ne devrait se produire et donc l'erreur ne devrait pas se reproduire au moins ce mois-ci.

Je ne sais toujours pas comment nous pourrions dépasser la limite de 100 pulls avec nos ~ 14 images docker.

Merci de vous y être penché. :sparkling_heart: Oui, ça a l'air un peu bizarre : si ce n'est que 14 images docker et que nous ne tirons que mensuellement, nous devrions être bien en dessous de toute limite ?

Il semble qu'il vérifie toujours les images de base mises à jour qui ne sont pas sur notre hub...

Hub.libelektra.org est-il configuré comme ceci : https://docs.docker.com/registry/recipes/mirror ? Si c'est le cas, je crois comprendre que la vérification de la mise à jour de l'image ne devrait être prise en compte que dans le quota, s'il a vraiment besoin d'extraire une nouvelle image.

Le moyen le plus simple de contourner le quota serait de créer un compte Docker Hub pour le CI. Il existe un programme Open Source , nous serions donc probablement éligibles pour un compte illimité.

Je pourrais faire l'application si ça peut aider. Mais d'abord, nous devrions découvrir quel est réellement le problème.

Je ne sais pas comment Docker Hub suit la limite de débit. Je suppose qu'il est basé sur IP, sinon il serait trop facile de le réinitialiser localement. Dans ce cas, notre serveur de build est-il la seule chose qui apparaîtrait à Docker Hub via cette IP ?

Oui, le serveur de build a une IP dédiée, voire plusieurs, et le CI est la seule partie qui utilise docker.

s'il ne s'agit que de 14 images docker et que nous ne tirons que mensuellement, nous devrions être bien en dessous de toute limite ?

Il semble que le pipeline Jenkins exécute un travail (je pense pour le site Web) qui essaie de tirer de Docker Hub tout le temps : https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3589 /5/canalisation/696

AFAIK, cela se produit à cause de l'utilisation de build --pull .

Nous devrions probablement simplement utiliser build (sans --pull ) par défaut et l'exécuter avec --pull hebdomadaire ou mensuel.

Merci d'avoir découvert ! :sparkling_heart:

Merci d'avoir trouvé la cause de ce problème !

Alternativement à la suppression de --pull , nous pourrions également créer une image de base pour la base webui sans elektra encore installé (uniquement avec les dépendances et les gtests installés). Cette image de base serait alors - comme les autres - construite mensuellement et l'image de base webui s'étendrait à partir de cette image de base et ne tirerait que de notre registre docker privé (et n'affecterait donc pas la limite de tirage)

base webui sans elektra encore installé

J'aime cette idée! Indépendamment des limites de traction de Docker, ce serait une amélioration !

base webui sans elektra encore installé

Oui, ce serait aussi une option. L'image en question est déjà l'image de base pour les images réelles webui et elektrad . Nous pourrions donc simplement déplacer la copie et la construction d'Elektra dans les autres fichiers Docker. Ou peut-être existe-t-il une solution avec des versions en plusieurs étapes ? Je ne sais pas si les étapes intermédiaires peuvent être poussées vers/tirées des registres.

Hier, je testais la bibliothèque partagée sur jenkins où seul le pull-stage était exécuté. Aucune création d'image, uniquement à partir de notre registre Docker privé sur hub.libelektra.org et j'ai toujours l'erreur Docker Rate Limit. J'ai regardé un peu plus profondément et j'ai réussi à trouver la cause de notre problème.
C'est watchtower , un conteneur en cours d'exécution qui met à jour nos images à des intervalles spécifiés. Ce problème devrait être résolu dans leur dernière version . Je vais mettre à jour cette image et définir l'intervalle de sondage sur une valeur plus élevée.
Les journaux du conteneur de la tour de guet confirment également mon hypothèse.

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."

Merci beaucoup d'avoir découvert :sparkling_heart:

@robaerd pouvons-nous fermer cela ou y a-t-il autre chose à faire ?

Toutes les images docker utilisées dans l'étape de l'artefact (webui, site Web, tests de packages) proviennent toujours de docker.org au lieu de notre registre privé. Je pense que cela devrait probablement faire l'objet d'un numéro distinct, car nous ne dépasserions jamais la limite de traction du docker avec cela. Mais depuis la mise à jour de l'image de la tour de guet, ce problème devrait être résolu et IMHO peut être fermé.

Il n'y a probablement rien d'autre à faire. Si nous n'atteignons pas les limites, c'est à mon humble avis de sortir de docker.org.