Quand on teste et qu'on arrive pas à faire un truc parfois on ressaye souvent. Je ne pense pas avoir souvent dépassé 10 par heure mais je ne serais pas surpris de l'avoir déjà fait.
Et quand ça marche pas et que tu découvre que tu a jeté une configuration fonctionnelle parce que tu n'avais pas vu que c'était à cause de cette limite….
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Ça ne change pas le problème si ton image de base est mise à jour tu va la pull, mais avoir toutes tes images de bases qui changent en même temps ça me surprend
Posté par Psychofox (Mastodon) .
Évalué à 1 (+0/-2).
Dernière modification le 22 février 2025 à 18:45.
Par défaut pour son propre code on devrait dans la mesure du possir toujours utiliser scratch. Et ça tombe bien vu qu'elle est vide, pas la peine de la mettre à jour.
Et pour les images de bases tu peux programmer leur pull de manière intelligente. C'est rare d'avoir besoin d'un million d'images de base. En général si tu prends:
- alpine
- fedora / centos / almalinux / rocky / amazon linux pour avoir une distro basée sur rpm
- la dernière ubuntu lts ou debian pour le monde deb.
Tu couvre tout le spectre de ce que tu vas en général trouver. Et en pullant 3-4 d'entre elles une fois par jour pour la mettre dans ta registry privée tu reste loin de la limite.
Par défaut pour son propre code on devrait dans la mesure du possir toujours utiliser scratch.
Que si tu fais de la compilation statique globalement.
alpine
fedora / centos / almalinux / rocky / amazon linux pour avoir une distro basée sur rpm
la dernière ubuntu lts ou debian pour le monde deb.
Euh alors ça c'est si tu fais ops dans une grande boite et que tu veux proposer un large panel aux développeurs, sinon c'est une par runtime (python, js, R,…) + une part technologie sur étagère que tu déploie dans docker (ton sgbdr, rabbitmq, kafka, nginx, redis,…) + une distribution vanilla éventuellement.
Et en pullant 3-4 d'entre elles une fois par jour pour la mettre dans ta registry privée tu reste loin de la limite.
Pull + reconstruire les images + redéployer
Et c'est ce que tente de faire l'outil plus haut mais mal.
c'est une par runtime (python, js, R,…) + une part technologie sur étagère que tu déploie dans docker (ton sgbdr, rabbitmq, kafka, nginx, redis,…) +
Pour toutes ces images il existe un repo avec une dockerfile, tu peux les builder toi même en local. C'est d'ailleurs en général assez instructif.
Moi je ne pull que des images de base, pour tout le reste je veux au moins savoir comment elles sont faites alors je clone le repo git
, étudie le dockerfile et le processus de build de l'appli et je reconstruis les images. Et comme ça on se rend compte souvent qu'on peut reconstruire l'image de pleins de projets avec la mėme image de base, d'autant plus que les runtime ont généralement une image, et donc une dockerfile, pour chaque release supportée de alpine/debian/ubuntu en version normale ou slim.
Alors tu vas me dire c'est gentooesque de tout recompiler mais en terme de temps de compilation et de traitement un runtime ou une sgbd ça build bien bien bien plus vite qu'un desktop comme kde ou gnome.
Tu peux mais ce n'est pas la pratique standard et ça demande pas mal d'engagement parce que c'est ton équipe qui prend de la responsabilité en plus. En plus de suivre les mises à jour des images de bases tu dois suivre celles des projets que tu utilise et de leurs dépendances. C'est possible, mais ce n'est pas un travail anodin si on veut le faire correctement. Plus qu'un truc comme renovate il faut aussi avoir un analyseur d'images docker comme snyk ou aqua. C'est toujours du travail en plus (pour réagir à ces alertes et pour maintenir l'ensemble aller vérifier que les outils fonctionnent toujours etc).
Perso je n'ai fais la démarche que sur notre image qui représentait 90% de nos usages parce que ça avait du sens je l'aurais pas fait pour les autres. Là où je suis maintenant nous sommes nombreux, tout ça est effectivement fait
non. Il re-pull tout pour se rendre qu'il a rien à faire >_<
Sat Feb 22 00:00:26 CET 2025 Timezone set to Europe/Paris
Sat Feb 22 00:00:26 CET 2025 Enabling synchronous service updates
Sat Feb 22 00:00:26 CET 2025 Send given registry authentication details to swarm agents
Sat Feb 22 00:00:26 CET 2025 Trying to login into registry
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
Sat Feb 22 00:00:30 CET 2025 Trying to update service camille_camille with image killruana/camille:main
Sat Feb 22 00:00:36 CET 2025 No updates to service camille_camille!
Sat Feb 22 00:00:40 CET 2025 Trying to update service coincoin_celery_beat with image killruana/coincoin:main
Sat Feb 22 00:00:46 CET 2025 No updates to service coincoin_celery_beat!
Sat Feb 22 00:00:49 CET 2025 Trying to update service coincoin_celery_worker with image killruana/coincoin:main
Sat Feb 22 00:00:56 CET 2025 No updates to service coincoin_celery_worker!
Sat Feb 22 00:00:59 CET 2025 Trying to update service coincoin_coincoin with image killruana/coincoin:main
Sat Feb 22 00:01:05 CET 2025 No updates to service coincoin_coincoin!
Sat Feb 22 00:01:17 CET 2025 Trying to update service coincoin_postgres17 with image postgres:17
Sat Feb 22 00:01:24 CET 2025 No updates to service coincoin_postgres17!
Sat Feb 22 00:01:36 CET 2025 Trying to update service coincoin_redis with image redis:latest
Sat Feb 22 00:01:43 CET 2025 No updates to service coincoin_redis!
Sat Feb 22 00:01:48 CET 2025 Trying to update service freshrss_freshrss with image freshrss/freshrss:latest
Sat Feb 22 00:01:54 CET 2025 No updates to service freshrss_freshrss!
Sat Feb 22 00:02:07 CET 2025 Trying to update service freshrss_postgres17 with image postgres:17
Sat Feb 22 00:02:13 CET 2025 No updates to service freshrss_postgres17!
Sat Feb 22 00:02:25 CET 2025 Trying to update service games_nginx with image nginx:latest
Sat Feb 22 00:02:31 CET 2025 No updates to service games_nginx!
Sat Feb 22 00:02:34 CET 2025 Trying to update service jtremesay_jtremesay with image killruana/jtremesay.org:main
Sat Feb 22 00:02:41 CET 2025 No updates to service jtremesay_jtremesay!
Sat Feb 22 00:02:42 CET 2025 Trying to update service mattermost_mattermost with image mattermost/mattermost-team-edition:10.2
Sat Feb 22 00:02:49 CET 2025 No updates to service mattermost_mattermost!
Sat Feb 22 00:03:01 CET 2025 Trying to update service mattermost_postgres17 with image postgres:17
Sat Feb 22 00:03:07 CET 2025 No updates to service mattermost_postgres17!
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_RP7N9GYosTBv9CtMPkL7-KDb7eA=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:12 CET 2025 Error updating service mirrors_nginx! Image nginx:latest does not exist or it is not available
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_Xfs4Q9tJpZUXRdEHk92FsPGoMGQ=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:14 CET 2025 Error updating service nextcloud_app! Image nextcloud:30 does not exist or it is not available
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_aTlaM4_m2RgzXHZNUb---wnUcJY=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:15 CET 2025 Error updating service nextcloud_cron! Image nextcloud:30 does not exist or it is not available
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_5hfSqgSVZbK0mdAovYRZ8PlXXEg=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:17 CET 2025 Error updating service nextcloud_postgres17! Image postgres:17 does not exist or it is not available
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_dMte7svnjqhlzLoloUoFq1Le4eo=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:19 CET 2025 Error updating service nextcloud_redis! Image redis:latest does not exist or it is not available
Sat Feb 22 00:03:24 CET 2025 Trying to update service portainer_agent with image portainer/agent:2.21.3
Sat Feb 22 00:03:31 CET 2025 No updates to service portainer_agent!
Sat Feb 22 00:03:36 CET 2025 Trying to update service portainer_portainer with image portainer/portainer-ce:2.21.3
Sat Feb 22 00:03:42 CET 2025 No updates to service portainer_portainer!
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_vDKBH94M0mBzXnevk02fMmOgINE=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:44 CET 2025 Error updating service rssbridge_rssbridge! Image rssbridge/rss-bridge:latest does not exist or it is not available
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_rBaEADvWcZw53ywOnpJ68J-ggwk=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:03:45 CET 2025 Error updating service sheperd_app! Image containrrr/shepherd:latest does not exist or it is not available
Sat Feb 22 00:03:55 CET 2025 Trying to update service sheperd_scheduler with image crazymax/swarm-cronjob:latest
Sat Feb 22 00:04:01 CET 2025 No updates to service sheperd_scheduler!
toomanyrequests: You have reached your pull rate limit as 'killruana': dckr_jti_trZcuNFMnTPypfL2M1SsWgg9tmw=. You may increase the limit by upgrading. https://www.docker.com/increase-rate-limit
Sat Feb 22 00:04:03 CET 2025 Error updating service traefik_traefik! Image traefik:3 does not exist or it is not available
1. hit the docker hub rate limit https://docs.docker.com/docker-hub/download-rate-limit/ ?
2. or image download uses too much internet bandwidth / server resources ?
The former one is due to
1. Both `docker manifest inspect` and `docker service update` contributes to the dockerhub rate usage.
2. Shepherd runs `docker manifest inspect` on all services, even they have the same image before updating. We do need to check whether there is an update on all services, but we can cache the results.
As a result, today, Shepherd would consume at least dockerhub rate 56 for your 28 stacks.
But it seems shepherd does more than I understand, and consumes more than 200 dockerhub rate. Maybe the commands use more than 1 rate.
Pardon mais il y a un truc que je ne comprends pas. Bon déjà ce logiciel est buggué de ce qui est décrit dans le ticket et tout cela le met en lumière. Disons pas optimisé si tu préfère, mais là ceux du ticket et toi vous avez de petites stacks pour ceux qui ont des choses plus conséquentes il doit être vraiment pénible à utiliser.
Ensuite je ne comprends pas le bien fondé du proxy refistry. Si me fait d'avoir un cache corrige les choses, c'est bien qu'ils font trop de choses.
Ça a l'air d'être un logiciel écrit dans l'idée que le réseau et les ressources du hub sont infini et gratuites et qui découvre qu'en fait c'est pas le cas.
toutafé. Mais hier quand j'ai réalisé que j'en avais un peu marre de mettre à jour les trucs muches à la main et qu'il était temps d'automatiser tout ça, c'est plus ou moins le seul truc pertinent et pas encore totalement mort que m'a retourné mon moteur de recherche préféré.
Je pense qu'avec une recherche moins spécifique tu peux trouver quelque chose de cool. Par exemple avec renovate. C'est un peu plus de travail si tu n'a pas de déploiement continue, mais ça n'est pas forcément si compliqué que ça à mettre en place
D'ailleurs tu pourrais au contraire augmenter la fréquence à une fois par heure. Ça réduit le risque de toutes les mettre à jour en même temps et si ça arrive ça ne retarde que d'une heure l'application de la correction
J'arrive à l'atteindre avec 1 unique conteneur (gotosocial) quand le fichier systemd est mis à jour par Ansible après une mise à jour de la version. J'ai encore vu ça ce matin.
J'ai pas exactement compris pourquoi et comment, vu que ça arrive avant le premier mars, mais visiblement, même en ne faisant rien de manuel pendant une heure (le temps de prendre le petit dej), j'arrive à avoir ça juste après:
# podman pull docker.io/superseriousbusiness/gotosocial:0.17.4
Trying to pull docker.io/superseriousbusiness/gotosocial:0.17.4...
WARN[0032] Failed, retrying in 1s ... (1/3). Error: initializing source docker://superseriousbusiness/gotosocial:0.17.4: reading manifest 0.17.4 in docker.io/superseriousbusiness/gotosocial: toomanyrequests: You have reached your unauthenticated pull rate limit. https://www.docker.com/increase-rate-limit
Et quand je dit rien, je suis sur que personne n'a touché à la machine. Il y a exactement un conteneur qui tourne sur ce serveur (le reste est en dehors), le serveur est utilisé par moi uniquement, et même si y a un VPN qui pourrait interferer, le portable qui utilise ce VPN était éteint pour cause de petit dej.
Donc soit y a un truc qui tourne en tache de fond (mais j'ai rien qui vient à l'esprit, aucun cronjob suspect ou timer), soit y a un souci spécifiquement avec Digital Ocean et le message est pourri (même si l'IP n'a pas changé depuis 4 ans), soit DockerHub interagit spécifiquement de façon qui cause un souci avec podman (qui n'a pas bougé depuis novembre sur la machine en question, donc je vais exclure un comportement du dit moteur).
Et ça dure depuis plus d'une semaine (vu que j'ai vu ça avec la version 0.17.4 de gotosocial, avec une erreur 500 au réveil), donc ça donne pas vraiment confiance dans Docker Hub en tant que stewart des images de divers projets upstream.
La seule hypothèse que j'ai, c'est que même si je dit "file moi la dernière version" avec docker pull, podman regarde les 25 autres versions que j'ai accumulé (et du coup, trigger le blocage avant même de faire un pull). J'ai fait le ménage dans le doute, on va voir dans 1h si c'est mieux.
Posté par Misc (site web personnel) .
Évalué à 4 (+1/-0).
Dernière modification le 23 février 2025 à 20:33.
Donc non, le ménage n'a pas aidé, ni l'attente.
Par contre, ça a finit par tomber en marche à 20h20 quand j'ai forcé l'IP de registry-1.docker.io en IPv4 afin de faire du tcpdump pour débugguer. Et en effet, en IP v6, ça marche pas, au moins sur mon serveur (car j'ai aussi de l'IP v6 partout sur mon la, et ça passe depuis chez moi).
100 téléchargements anonymes toutes les 6 heures (soit 16 par heure, contre 10 à partir du 1er mars)
200 téléchargements authentifiés toutes les 6 heures (soit 33 par heure, contre 40 à partir du 1er mars)
C'est donc un poil moins pour les anonymes et un poil plus pour les utilisateurs enregistrés.
Rappelons ici la nécessité d'avoir son propre registre si on a besoin de beaucoup tirer et qu'on ne veut pas utiliser un compte payant sur le Docker Hub.
Dis autrement avec 100 par 6 heures tu peux en faire 25 en 1h et rien ensuite… Alors que quand c'est mis par heure cela n'est plus possible.
Cela fait 1 pour 3.6 minutes (arrondissons à 3 min 30). Si tu lance un script qui fait 2 pull, il plante… et le pire c'est que je ne suis pas sûr que tu puisse dans tous les cas les décaler (Genre un docker CI qui fait plusieurs "pull docker" sur "git merge".).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Pour limiter les appels à docker hub, j'utilise actuellement le très beau projet artipie qui permets de gérer des dépôts de tout type, donc Docker.
Il est simple à déployer et le code est lisible (c'est du bon Java) et contrairement à son concurrent Nexus, c'est du vrai opensource véritable sans version premium privatrice.
Malheureusement, depuis quelques mois ses auteurs n'ont plus trop de temps pour le maintenir, je suis en train de chercher une structure pour en reprendre le développement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# ce n'est pas tant que ça
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+2/-1).
Quand on teste et qu'on arrive pas à faire un truc parfois on ressaye souvent. Je ne pense pas avoir souvent dépassé 10 par heure mais je ne serais pas surpris de l'avoir déjà fait.
Et quand ça marche pas et que tu découvre que tu a jeté une configuration fonctionnelle parce que tu n'avais pas vu que c'était à cause de cette limite….
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: ce n'est pas tant que ça
Posté par jtremesay (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 21 février 2025 à 23:41.
Je l'atteint quand https://github.com/containrrr/shepherd lance la mise à jour quotidienne de mes 22 containeurs :(
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Tes 22 images changent tous les jours ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par jtremesay (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 22 février 2025 à 01:03.
non. Mais si une mise à jour de sécurité est publié, je préfère la récupérer au plus tôt que au plus tard.
Pis même si je passais le cron à une fréquence hebdomadaire, ça ne changerait rien au fait qu'il crame la limite de 10 pull en une heure.
[^] # Re: ce n'est pas tant que ça
Posté par Psychofox (Mastodon) . Évalué à 1 (+0/-2).
Moi je préfère reconstruire une image depuis le dockerfile et la mettre sur ma registry privée.
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Ça ne change pas le problème si ton image de base est mise à jour tu va la pull, mais avoir toutes tes images de bases qui changent en même temps ça me surprend
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par Psychofox (Mastodon) . Évalué à 1 (+0/-2). Dernière modification le 22 février 2025 à 18:45.
Par défaut pour son propre code on devrait dans la mesure du possir toujours utiliser scratch. Et ça tombe bien vu qu'elle est vide, pas la peine de la mettre à jour.
Et pour les images de bases tu peux programmer leur pull de manière intelligente. C'est rare d'avoir besoin d'un million d'images de base. En général si tu prends:
- alpine
- fedora / centos / almalinux / rocky / amazon linux pour avoir une distro basée sur rpm
- la dernière ubuntu lts ou debian pour le monde deb.
Tu couvre tout le spectre de ce que tu vas en général trouver. Et en pullant 3-4 d'entre elles une fois par jour pour la mettre dans ta registry privée tu reste loin de la limite.
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Que si tu fais de la compilation statique globalement.
Euh alors ça c'est si tu fais ops dans une grande boite et que tu veux proposer un large panel aux développeurs, sinon c'est une par runtime (python, js, R,…) + une part technologie sur étagère que tu déploie dans docker (ton sgbdr, rabbitmq, kafka, nginx, redis,…) + une distribution vanilla éventuellement.
Pull + reconstruire les images + redéployer
Et c'est ce que tente de faire l'outil plus haut mais mal.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par Psychofox (Mastodon) . Évalué à 3 (+1/-1).
Pour toutes ces images il existe un repo avec une dockerfile, tu peux les builder toi même en local. C'est d'ailleurs en général assez instructif.
Moi je ne pull que des images de base, pour tout le reste je veux au moins savoir comment elles sont faites alors je clone le repo git
, étudie le dockerfile et le processus de build de l'appli et je reconstruis les images. Et comme ça on se rend compte souvent qu'on peut reconstruire l'image de pleins de projets avec la mėme image de base, d'autant plus que les runtime ont généralement une image, et donc une dockerfile, pour chaque release supportée de alpine/debian/ubuntu en version normale ou slim.
Alors tu vas me dire c'est gentooesque de tout recompiler mais en terme de temps de compilation et de traitement un runtime ou une sgbd ça build bien bien bien plus vite qu'un desktop comme kde ou gnome.
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Tu peux mais ce n'est pas la pratique standard et ça demande pas mal d'engagement parce que c'est ton équipe qui prend de la responsabilité en plus. En plus de suivre les mises à jour des images de bases tu dois suivre celles des projets que tu utilise et de leurs dépendances. C'est possible, mais ce n'est pas un travail anodin si on veut le faire correctement. Plus qu'un truc comme renovate il faut aussi avoir un analyseur d'images docker comme snyk ou aqua. C'est toujours du travail en plus (pour réagir à ces alertes et pour maintenir l'ensemble aller vérifier que les outils fonctionnent toujours etc).
Perso je n'ai fais la démarche que sur notre image qui représentait 90% de nos usages parce que ça avait du sens je l'aurais pas fait pour les autres. Là où je suis maintenant nous sommes nombreux, tout ça est effectivement fait
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Il ne le fait que si tu as effectivement de nouvelles images.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par jtremesay (site web personnel) . Évalué à 3 (+1/-0).
non. Il re-pull tout pour se rendre qu'il a rien à faire >_<
[^] # Re: ce n'est pas tant que ça
Posté par jtremesay (site web personnel) . Évalué à 3 (+1/-0).
https://github.com/containrrr/shepherd/issues/125
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Pardon mais il y a un truc que je ne comprends pas. Bon déjà ce logiciel est buggué de ce qui est décrit dans le ticket et tout cela le met en lumière. Disons pas optimisé si tu préfère, mais là ceux du ticket et toi vous avez de petites stacks pour ceux qui ont des choses plus conséquentes il doit être vraiment pénible à utiliser.
Ensuite je ne comprends pas le bien fondé du proxy refistry. Si me fait d'avoir un cache corrige les choses, c'est bien qu'ils font trop de choses.
Ça a l'air d'être un logiciel écrit dans l'idée que le réseau et les ressources du hub sont infini et gratuites et qui découvre qu'en fait c'est pas le cas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par jtremesay (site web personnel) . Évalué à 3 (+1/-0).
toutafé. Mais hier quand j'ai réalisé que j'en avais un peu marre de mettre à jour les trucs muches à la main et qu'il était temps d'automatiser tout ça, c'est plus ou moins le seul truc pertinent et pas encore totalement mort que m'a retourné mon moteur de recherche préféré.
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Je pense qu'avec une recherche moins spécifique tu peux trouver quelque chose de cool. Par exemple avec renovate. C'est un peu plus de travail si tu n'a pas de déploiement continue, mais ça n'est pas forcément si compliqué que ça à mettre en place
https://docs.renovatebot.com/docker/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
D'ailleurs tu pourrais au contraire augmenter la fréquence à une fois par heure. Ça réduit le risque de toutes les mettre à jour en même temps et si ça arrive ça ne retarde que d'une heure l'application de la correction
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ce n'est pas tant que ça
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0).
J'arrive à l'atteindre avec 1 unique conteneur (gotosocial) quand le fichier systemd est mis à jour par Ansible après une mise à jour de la version. J'ai encore vu ça ce matin.
J'ai pas exactement compris pourquoi et comment, vu que ça arrive avant le premier mars, mais visiblement, même en ne faisant rien de manuel pendant une heure (le temps de prendre le petit dej), j'arrive à avoir ça juste après:
Et quand je dit rien, je suis sur que personne n'a touché à la machine. Il y a exactement un conteneur qui tourne sur ce serveur (le reste est en dehors), le serveur est utilisé par moi uniquement, et même si y a un VPN qui pourrait interferer, le portable qui utilise ce VPN était éteint pour cause de petit dej.
Donc soit y a un truc qui tourne en tache de fond (mais j'ai rien qui vient à l'esprit, aucun cronjob suspect ou timer), soit y a un souci spécifiquement avec Digital Ocean et le message est pourri (même si l'IP n'a pas changé depuis 4 ans), soit DockerHub interagit spécifiquement de façon qui cause un souci avec podman (qui n'a pas bougé depuis novembre sur la machine en question, donc je vais exclure un comportement du dit moteur).
Et ça dure depuis plus d'une semaine (vu que j'ai vu ça avec la version 0.17.4 de gotosocial, avec une erreur 500 au réveil), donc ça donne pas vraiment confiance dans Docker Hub en tant que stewart des images de divers projets upstream.
La seule hypothèse que j'ai, c'est que même si je dit "file moi la dernière version" avec docker pull, podman regarde les 25 autres versions que j'ai accumulé (et du coup, trigger le blocage avant même de faire un pull). J'ai fait le ménage dans le doute, on va voir dans 1h si c'est mieux.
[^] # Re: ce n'est pas tant que ça
Posté par Misc (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 23 février 2025 à 20:33.
Donc non, le ménage n'a pas aidé, ni l'attente.
Par contre, ça a finit par tomber en marche à 20h20 quand j'ai forcé l'IP de registry-1.docker.io en IPv4 afin de faire du tcpdump pour débugguer. Et en effet, en IP v6, ça marche pas, au moins sur mon serveur (car j'ai aussi de l'IP v6 partout sur mon la, et ça passe depuis chez moi).
[^] # Re: ce n'est pas tant que ça
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Une erreur de pull c'est tout de même plutôt clair. Sinon passe sur le registry d'un cloud provider ou de RedHat par exemple
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# ça ne change pas grand-chose
Posté par nico (site web personnel, Mastodon) . Évalué à 5 (+5/-0).
Si je ne me trompe pas, au final ça ne change pas grand-chose au plan d'avant : https://web.archive.org/web/20241112091312/https://www.docker.com/increase-rate-limits/
C'est donc un poil moins pour les anonymes et un poil plus pour les utilisateurs enregistrés.
Rappelons ici la nécessité d'avoir son propre registre si on a besoin de beaucoup tirer et qu'on ne veut pas utiliser un compte payant sur le Docker Hub.
[^] # Re: ça ne change pas grand-chose
Posté par ff9097 . Évalué à 10 (+9/-0).
100 par 6h c'est bien plus souple que 16 par heure.
[^] # Re: ça ne change pas grand-chose
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Dis autrement avec 100 par 6 heures tu peux en faire 25 en 1h et rien ensuite… Alors que quand c'est mis par heure cela n'est plus possible.
Cela fait 1 pour 3.6 minutes (arrondissons à 3 min 30). Si tu lance un script qui fait 2 pull, il plante… et le pire c'est que je ne suis pas sûr que tu puisse dans tous les cas les décaler (Genre un docker CI qui fait plusieurs "pull docker" sur "git merge".).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Artipie
Posté par devnewton 🍺 (site web personnel) . Évalué à 9 (+6/-0). Dernière modification le 22 février 2025 à 14:43.
Pour limiter les appels à docker hub, j'utilise actuellement le très beau projet artipie qui permets de gérer des dépôts de tout type, donc Docker.
Il est simple à déployer et le code est lisible (c'est du bon Java) et contrairement à son concurrent Nexus, c'est du vrai opensource véritable sans version premium privatrice.
Malheureusement, depuis quelques mois ses auteurs n'ont plus trop de temps pour le maintenir, je suis en train de chercher une structure pour en reprendre le développement.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Artipie
Posté par steph1978 . Évalué à 1 (+0/-1).
Le registry est disponible en auto-hébergement.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.