Quand on est parents, on protège ses enfants contre le froid, les dangers ou même contre les chagrins.
Et contre les HPV, est-ce qu'on peut les protéger ?
Les HPV sont des virus humains appelés papilloma virus.
Ils sont responsables de plusieurs milliers de cancers chaque année.
80% des femmes et des hommes seront exposés à ces virus au cours de leur vie.
La bonne nouvelle, c'est qu'il existe une vaccination sûre et efficace pour protéger ses enfants.
Les filles, comme les garçons, dès 11 ans.
Contre les cancers de demain, c'est aujourd'hui qu'il faut agir.
Ceci est un message du ministère chargé de la santé et de l'Institut national du cancer.
D'après vous, qui peut souffrir de mal-être, d'anxiété, de dépression ou d'un autre trouble psychique ?
Une amie, un collègue, un proche, un voisin ?
Oui, nous tous.
Et d'après vous, qui peut écouter celui ou celle qui a besoin d'en parler ?
Une amie, un collègue, un proche, un voisin ?
Pareil, nous tous.
La santé mentale nous concerne tous.
Parlons-en, écoutons-nous.
Info et conseil sur santémentaleinfoservice.fr
Ceci est un message du ministère chargé de la santé et de santé publique France.
Ton intégration continue est complètement cassée.
Tu ne peux plus télécharger d'images depuis le Docker Hub.
Je vais t'expliquer pourquoi est-ce donné des pistes pour résoudre ce problème.
C'est parti !
Bonjour à toi chers compagnons.
Et aujourd'hui, on va parler des nouvelles limitations du Docker Hub.
Puisque Docker a mis en place des limitations à nouveau,
ce 1er avril 2025.
Et ce n'est pas un poisson.
Depuis quelque temps, tu as pu remarquer des problèmes avec le Docker Hub.
Alors soit tes images ne se télécharge pas correctement,
que ce soit sur ton laptop ou dans ton intégration continue, ce qui est plus embêtant.
C'est vraiment le chaos dans tous tes jobs d'intégration continue.
Puisque il n'y a plus rien qui fonctionne, tu as des images qui ne se téléchargent plus.
Ton product honneur est complètement en PLS car le projet n'avance plus.
C'est ce qu'on peut imaginer qui peut se passer si on ne prend pas en compte toutes ces limitations de Docker.
Alors, pas de panique.
On va en parler et on va aborder ce qui se passe.
Alors, ce qui se passe, c'est que le 1er avril 2025, Docker annonce un changement de règles,
notamment sur les poules du Docker Hub.
Les règles sont les suivantes.
Pour les utilisateurs anonymes, donc les personnes qui ne se connectent pas
et qui tentent de télécharger des images depuis le Docker Hub,
on est à environ 10 images par heure pour une IPv6 ou une IPv4 pour le sous-réseau slash 64.
Je te laisse aller voir la documentation de Docker.
Je te l'ai mis en lien de toute façon.
Pour les utilisateurs authentifiés gratuits, on est à 100 poules par heure.
Et pour les utilisateurs au moins pros, donc les utilisateurs payants, on est limités.
Donc, on peut télécharger autant d'images qu'on veut.
Alors, ça, ce n'est pas nouveau parce qu'en 2020, déjà, Docker avait mis en place des limites
sur le transfert des images.
Alors, il y a plein de choses qui s'est passées à ce moment-là.
Docker avait mis en place des limites très restrictives, puis est revenu dessus.
Mais ce qu'on sait, c'est qu'il y avait des images, enfin des poules d'image,
à raison de 100 toutes les 6 heures pour les utilisateurs anonymes
et pour les utilisateurs authentifiés, 200 toutes les 6 heures.
Et puis pour les pros, c'était illimité.
Donc déjà, à l'époque, il y avait eu pas mal de choses qui s'étaient passées.
La communauté avait remonté ses bretelles,
elle avait remonté les bretelles de Docker qui avait changé son fusil d'épaule plusieurs fois.
C'est à ce moment-là, deux mémoires qui t'apparaient,
le Proxy de conteneur de GitLab, dont on va parler.
Alors, maintenant, qu'est-ce que tu peux faire pour pallier à ça
puisque Docker va mettre en place ses limitations,
enfin, les a déjà mis en place jusqu'au moment où je tourne la vidéo,
on est déjà le 1er avril et le moment où tu vas l'avoir,
le moment où je les mets en ligne, ce sera passé.
Alors, qu'est-ce qu'on peut faire ?
T'as plusieurs solutions devant toi.
L'idée, c'est de pouvoir travailler tranquille.
Alors, première chose à faire pour ta ligne de commande et ta cli Docker sur ton laptop.
La première chose que moi, je te conseille,
c'est de créer un utilisateur auprès du Docker Hub ou un conduit Docker
et puis de configurer ton cli pour pouvoir s'authentifier directement
puisque dit pool, c'est vite atteint, dit pool par heure si tu fais des tests,
notamment sur des images diverses et variées.
Bon, là où c'est le plus grave, c'est pour ton intégration continue.
Là, moi, je vais me concentrer sur GitLab CI,
mais c'est vrai pour toutes les intégrations continue
puisque aujourd'hui, la plupart des outils d'intégration continue
se battent sur des images de conteneurs.
Et pour la plupart, vont les chercher sur le Docker Hub.
Donc, tu as plusieurs possibilités.
Je les ai classées en fonction du plus rapide au moins rapide à mettre en place.
Donc, la plus rapide à mettre en place, c'est de passer sur un compte payant.
Tu vas sur le Docker Hub, tu prends un compte, tu payes.
Ça commence à 9 euros par mois et par utilisateur.
Et puis là, tu n'as pas de limitation.
Tu peux configurer ton compte n'importe où.
C'est très rapide à mettre en place.
Bon, par contre, ton compte, qu'est-ce que tu vas en faire?
Puisque une fois que tu l'as, tu peux le mettre sur ton laptop,
mais tu peux aussi le mettre ailleurs.
Donc là, je vais aborder les autres solutions.
Et les autres solutions sont valables avec un compte payant ou avec un compte gratuit.
Puisque si tu n'as pas de compte, tu seras limité à 10 poules par heure.
Ce n'est pas suffisant.
La première chose que tu peux mettre en place,
c'est plutôt que d'aller télécharger les images de conteneurs sur le Docker Hub.
Tu peux utiliser le Proxy de dépendance GitLab.
C'est une solution que peu de gens vont conseiller.
Et pourtant, elle est, à mon avis, la plus simple à mettre en place.
Surtout sur toutes les forges, que ce soit GitLab.com ou les forges auto hébergés,
donc celle Faustide, tu peux mettre en place.
Tu peux mettre en place ça.
C'est très simple.
Il suffit de rajouter une variable d'environnement
qui t'est fourni par Docker par GitLab devant ton image de conteneurs.
Et lui, GitLab va aller la télécharger sur le Docker Hub une première fois
et puis la mettre à disposition de tous tes jobs.
Alors ce Proxy de dépendance, il peut être lié à un projet ou à un groupe.
C'est comme tu veux.
C'est très rapide à mettre en place.
Et tu peux, sur une forge auto hébergée,
même utiliser un utilisateur authentifié pour justement améliorer les performances.
J'ai fait une vidéo tuto pour te montrer
comment mettre en place ce genre de choses.
Parce que là, dans ce podcast, j'aborde juste les techniques.
La deuxième chose que tu peux faire, c'est configurer le Docker Hub dans tes pipeline.
Enfin, un compte, tu utilises un compte Docker Hub pour tes pipeline
et donc tu vas là mettre en place dans tes pipeline
soit au niveau de ton projet, soit au niveau de ton groupe,
un compte authentifié.
Donc pareil, tu vas créer un compte soit gratuit soit payant
et puis tu vas le mettre dans tes variables d'intégration continue.
Alors, bien dans tes variables et pas dans ton fichier
Geeklabs.y.y.mull parce que c'est un secret.
Donc c'est important de le mettre dans tes variables d'environnement au niveau de Geeklab.
Si tu as un compte payant, par exemple, tu peux le mettre au niveau de ton groupe.
Si tu as des comptes séparés par projet,
tu peux les mettre au niveau de tes projets.
C'est assez rapide à mettre en place puisque c'est une variable d'environnement
que tu vas déclarer et automatiquement,
tes pipelines vont aller utiliser ce compte.
Ensuite, tu peux aller mettre en place un compte authentifié sur tes Geeklab.runner.
Si tu gères toi-même tes Geeklab.runner,
tu peux aller configurer ton Geeklab.runner pour aller chercher les images de conteneurs
avec un compte authentifié toujours soit gratuit soit payant.
Là aussi, c'est assez rapide à mettre en place
puisque c'est une variable d'environnement que tu veux mettre au niveau du conteneur.
C'est en plus la même que tu veux mettre au niveau de tes pipelines.
Donc c'est la même technique.
Pareil, je te montre dans un tuto comment faire ça sur tes propres runneurs.
Une autre solution qui est d'utiliser les registres tiers.
Au niveau d'utilisation des registres tiers, tu as plusieurs possibilités.
Là, on parle de ce passé du Docker Hub pour télécharger tes images de conteneurs
et d'aller chercher tes images de conteneurs sur un autre registre.
Alors déjà, tu as celui de Google.
Celui de Google, il est utilisé par Geeklab.com.
Il sert de miroir.
Je ne sais pas très bien comment il fonctionne parce que je n'utilise pas.
Mais a priori, Geeklab.com utilise le registre de Google
et Google va chercher les images sur le registre de conteneurs Docker
puis les mettre à disposition.
Donc tu peux mettre en place ça,
soit en utilisant un registre de conteneurs tout fait,
enfin en sas comme Google,
soit mettre en place ton propre registre de conteneurs dans ton infrastructure.
Ce n'est pas le plus rapide à mettre en place.
Je ne te montrerai pas dans le tuto comment le faire
parce que sinon le tuto serait trop long.
Ce n'est pas une des choses que je vais mettre en place tout de suite.
Dans la même vaine, tu peux utiliser un miroir
en utilisant le Geeklab,
le registre de conteneurs de Geeklab.com.






Tu ne vas pas mettre en place un service dans ton infrastructure,
tu vas utiliser le registre de conteneurs de Geeklab.
Si tu es déjà sur Geeklab, a priori si le registre de conteneurs est activé,
tu vas pouvoir l'utiliser.
Tu crées un espace, un projet ou même un groupe,
dans lequel tu vas héberger les images de conteneurs.
L'idée est simple,
c'est que pour chaque image de conteneurs que tu vas utiliser,
pour ton intégration continue,
tu vas télécharger l'image de conteneurs,
l'attagger et l'envoyer sur ton registre de conteneurs.
Comme ça, tu pourras l'utiliser depuis les pipelines.
Donc là, il va falloir changer tes pipelines pour aller non plus
chercher tes images de conteneurs sur le Docker Hub,
mais sur le Geeklab Registry Conteneurs,
donc le registre de conteneurs de Geeklab.
Tu peux automatiser ça.
Je ne sais pas encore si je vais le mettre dans le tuto,
mais si je le mets dans le tuto, tu auras ça aussi.
Tu peux automatiser ça via un pipeline Geeklab CI.
Si tu mets la liste de toutes tes images,
tu peux concevoir un pipeline qui va le faire tous les jours
ou toutes les semaines ou tous les mois comme tu veux.
C'est moyennement rapide à mettre en place,
donc c'est une solution que je te conseille dans un second temps.
Bon, maintenant que tu as toutes ces solutions,
l'idée c'est de se poser la question de
quelle solution j'utilise, moi.
Qu'est-ce que je vais mettre en place ?
Moi je vais te conseiller ce que tu pourrais mettre en place
rapidement et puis moins rapidement.
Quelle solution tu pourras adopter là ?
La première chose que je te conseille de faire
si tu as tes propres runners Geeklab,
c'est d'aller créer un compte sur le Docker Hub
et d'authentifier tes runners directement.
Ça c'est la première chose que je fais.
C'est ce qu'on a fait sur Frogit, notre forge logiciel.
On a authentifié nos runners directement
sur le Docker Hub.
La deuxième chose c'est d'aller authentifier tes jobs
ou tes pipelines sur le Docker Hub.
Soit au niveau de tes projets, soit au niveau de tes groupes
en fonction de la taille de ton infrastructure.
Donc tu peux jongler avec les comptes,
par exemple un compte par projet, etc.
Mais si tu commences à faire ce genre de choses,
peut-être que tu devrais passer sur un compte pays.
La troisième chose que je te conseille de mettre en place
une fois que tu as fait les deux premières,
c'est d'utiliser le proxy de dépendance de conteneurs de Geeklab,
qui va t'améliorer les choses,
parce que en plus ça va localiser au plus près de tes runners
les images de conteneurs,
parce qu'aller les chercher sur le Docker Hub, ça prend du temps.
Donc là on va les chercher sur le Docker Hub une fois
et puis après elles seront dans la forge.
Donc là souvent les runners sont localisés proches de la forge,
ce qui est le cas sur Frogit,
puisque c'est le même fournisseur, donc ça va encore plus vite.
Donc ça aussi, on va le conseiller,
en tout cas à nos clients, de le faire
dans une communication.
Une fois que tu as mis en place ces trois trucs-là,
mettre en place un roger de conteneurs,
soit utiliser le roger de conteneurs de Geeklab,
soit en utilisant un autre,
pour aller poser les images critiques
et l'étendre justement
avec le temps sur les autres images.
Là tu vas pouvoir petit à petit
aller poser tes images de conteneurs
dans ce roger de conteneurs,
qui ne servira qu'à tes intégrations contenues.
L'avantage de faire ça, c'est qu'en plus tu peux les scanner toi-même,
tes images de conteneurs.
Tu les télécharges, tu les scannes,
dans ton pipeline, tu les scannes et tu vois ce qui se passe.
Et enfin,
le top du top,
c'est de mettre en place
à un miroir
des dépôts
qui paquaitent les images de conteneurs,
donc des dépôts avec les docker files.
Pourquoi ? Parce que si
ces dépôts-là disparaient,
déjà tu as les docker files,
donc c'est bien, tu pourras les réutiliser.
Deux-mêmes le précédent conseil
que je t'ai donné, ce qui était de
mettre en place un roger de conteneurs,
si le roger de conteneurs docker habile est
soit cassé, soit coupé,
parce que je sais pas, un embargo par exemple,
et ben tu auras à disposition
tes images de conteneurs.
Donc là c'est ce que je te conseille de mettre en place petit à petit.
Tu trouveras
dans l'article de blog,
parce que je ne mets plus les liens
dans la description YouTube ou dans la description
du podcast, c'est trop long et
les descriptions sont trop courtes.
Donc tu trouveras dans l'article de blog tout un tas de liens,
notamment
le lien de l'article de blog
de docker qui explique les nouvelles
limitations.
Je te mets le lien aussi de la documentation.
Je te mets aussi un poste
l'une que Dine, donc c'est le poste
d'Olivier qui m'a mis
la puce à l'oreille sur cette histoire là,
parce que je n'avais pas regardé avant.
Je te mets aussi un article
de Stéphane Robert qui décrit pas mal de
choses et je suis
assez d'accord avec ce qu'il propose.
Donc tu peux aller compléter
l'article de blog que je te donne avec celui-là.
Et puis tout un tas d'autres articles,
notamment l'article de GeekLam qui explique
comment faire des choses
et aussi les articles historiques
que j'ai réussi à trouver
dans la web-back machine, donc
les archives du web, parce que
elles avaient disparu.
Mais voilà, tu as les infos sur ce qui
s'est passé en 2020.
Je te mets aussi des infos sur le
registre de cache de Google.
Alors il y en a d'autres.
Tu peux aller chercher les autres.
Et tu as un lien aussi
vers la documentation
GeekLam qui parle du proxy de
dépendance de conteneurs.
Donc t'as de quoi faire.
Et je te rappelle que tu as mon
tuto aussi pour t'aider à mettre en place
tout ça, où je te montre avec mon
écran, je te montre ce que je fais
et comment je le fais.
Donc, va voir la vidéo, elle s'affiche
donc, elle s'affiche en haut,
à droite, ici ou là. Je ne sais
jamais avec le miroir et tout.
Mais bref, elle s'affiche.
Donc, va la voir.
Tu ressors plus.
Et si tu veux plus d'informations
et de techniques liées à Geek
ou Geek Lab, tu peux
t'inscrire sur ma communauté.
Puisque je vais lancer une communauté
Geek et Geek Lab, je la prépare en ce moment.
Tu recevras en plus en t'inscrivant
mon antisèche et des astuces
régulières sur Geek Lab.
Bon, j'espère que
tu pourras mettre en place tout ça.
Que ta CII va aller
beaucoup mieux avec le temps.
Et moi, je te dis à très bientôt
pour un nouveau podcast.
Merci d'avoir écouté Radio DevOps.
N'oublie pas de noter l'épisode.
Plus la note sera élevée et plus
sera mis en avant dans les applications.
Tu peux aussi le partager.
Ça nous aidera à le diffuser et rendre le mouvement plus visible.
Si tu as envie de discuter
du mouvement, alors rejoins-nous
dans la communauté des compagnons
du DevOps. A bientôt.
La balade aux diffusions des compagnons
du DevOps est produite à Lydra.