Le 1er avril 2025, Docker va mettre en place de nouvelles limites de débit relatives aux pulls d'images sur Docker Hub, susceptibles d'impacter de manière significative les pipelines CI/CD de développement logiciel, y compris ceux qui s'exécutent sur GitLab. Le changement le plus notable : un plafond fixé à 10 pulls d'images par heure pour les utilisateurs non authentifiés.
Quels sont les changements attendus ?
À compter du 1er avril, Docker va appliquer les limites strictes suivantes aux pulls d'images (téléchargements d'images) :
Type d'utilisateur | Limite de pulls d'images par heure | Nombre de dépôts publics | Nombre de dépôts privés |
---|---|---|---|
Business, Team, Pro (authentifié) | Illimité (utilisation raisonnable) | Illimité | Illimité |
Personal (authentifié) | 100 | Illimité | Jusqu'à 1 |
Utilisateurs non authentifiés | 10 par adresse IPv4 ou sous-réseau IPv6/64 | Non applicable | Non applicable |
Ces nouveaux quotas sont particulièrement importants pour les raisons suivantes :
- Le proxy de dépendances de GitLab effectue actuellement des pulls à partir de Docker Hub en tant qu'utilisateur non authentifié.
- La plupart des pipelines CI/CD qui n'utilisent pas le proxy de dépendances effectuent des pulls directement à partir de Docker Hub en tant qu'utilisateurs non authentifiés.
- Pour les runners hébergés sur GitLab.com, le partage d'une même adresse IP ou sous-réseau par plusieurs utilisateurs les soumet collectivement à cette limite.
Quel impact sur les utilisateurs de GitLab ?
Impact sur les pulls directs depuis Docker Hub
Si vos pipelines CI/CD effectuent des pulls directement depuis Docker Hub sans authentification, ils seront limités à 10 pulls d'images par heure et par adresse IP. Dans le cas de pipelines exécutés fréquemment ou sur plusieurs projets partageant la même infrastructure de runner, cette limite sera rapidement atteinte, ce qui entraînera des échecs de pipeline.
Impact sur le proxy de dépendances de GitLab
La fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache des images Docker dans GitLab pour accélérer les pipelines et réduire la dépendance aux registres externes. Cependant, dans sa version actuelle, ce proxy effectue des pulls d'images depuis Docker Hub en tant qu'utilisateur non authentifié, ce qui signifie qu'il est lui aussi soumis à la limite des 10 pulls d'images par heure.
Impact sur les runners hébergés
Sur GitLab.com, les runners hébergés s'appuient sur le cache pull-through de Google Cloud, qui met en miroir les images fréquemment téléchargées. Cela permet d'éviter les limites de débit, comme pour les images de job définies comme image:
ou services:
dans votre fichier .gitlab-ci.yml
.
Tout se complique légèrement lorsque les images sont téléchargées dans l'environnement du runner. Le cas le plus courant de pull d'images pendant l'exécution du runner concerne la création d'une image à l'aide de Docker-in-Docker ou de Kaniko. Dans ce scénario, l'image Docker Hub définie dans votre Dockerfile
fait l'objet d'un pull directement depuis Docker Hub. Elle est donc susceptible d'être affectée par les limites de débit.
Comment GitLab répond à ces nouveaux quotas ?
Nous travaillons activement à la recherche de solutions pour atténuer les impacts liés à ces nouvelles limites :
- Authentification du proxy de dépendances : nous avons ajouté la prise en charge de l'authentification Docker Hub dans la fonctionnalité de proxy de dépendances de GitLab. Cela permettra à ce dernier de télécharger des images depuis Docker Hub en tant qu'utilisateur authentifié, et ainsi d'augmenter considérablement les limites de débit.
- Mise à jour de la documentation : nous avons actualisé notre documentation afin de fournir des instructions claires sur la configuration de l'authentification des pipelines pour Docker Hub.
- Préparation de l'infrastructure interne : nous préparons notre infrastructure GitLab.com afin de réduire au maximum l'impact de ces limites sur les runners hébergés.
Comment s'y préparer ?
Option 1 : configurez l'authentification Docker Hub dans vos pipelines
Si vos pipelines effectuent des pulls directement depuis Docker Hub, vous pouvez configurer l'authentification afin d'augmenter votre limite de taux à 100 pulls d'images par heure (ou illimitée avec un abonnement payant à Docker Hub).
Pour cela, ajoutez vos identifiants de connexion Docker Hub aux variables CI/CD de votre projet ou groupe (ne les insérez pas directement dans le fichier .gitlab-ci.yml
). Consultez les instructions détaillées de notre documentation sur l'utilisation d'images Docker pour configurer correctement la variable CI/CD DOCKER_AUTH_CONFIG
.
Option 2 : utilisez le registre de conteneurs GitLab
Effectuez un push des images Docker que vous utilisez le plus souvent dans votre registre de conteneurs GitLab afin d'éviter de devoir effectuer un pull d'images depuis Docker Hub pendant l'exécution des pipelines CI/CD. Procédez comme suit :
- Effectuez un pull de l'image depuis Docker Hub.
- Attribuez-lui un tag adapté à votre registre de conteneurs GitLab.
- Effectuez un push de l'image dans votre registre de conteneurs GitLab.
- Mettez à jour vos pipelines pour qu'ils effectuent un pull de l'image depuis le registre de conteneurs GitLab.
docker pull busybox:latest
docker tag busybox:latest $CI_REGISTRY_IMAGE/busybox:latest
docker push $CI_REGISTRY_IMAGE/busybox:latest
Puis ajoutez cette ligne de commande dans votre fichier .gitlab-ci.yml
:
image: $CI_REGISTRY_IMAGE/busybox:latest
Option 3 : utilisez le proxy de dépendances de GitLab
La fonctionnalité de proxy de dépendances de GitLab permet de mettre en cache les images Docker, tout en servant de proxy entre vos pipelines CI/CD et les registres Docker Hub, réduisant ainsi la dépendance aux registres externes et les risques liés aux limites de débit.
Options d'authentification actuelles :
- GitLab 17.10 : configurez l'authentification Docker Hub pour le proxy de dépendances à l'aide de l'API GraphQL.
- GitLab 17.11 : utilisez la nouvelle interface de configuration dans les paramètres de votre groupe (déjà disponible sur GitLab.com).
Une fois l'authentification correctement configurée, vous pouvez procéder comme suit :
- Configurez les identifiants de connexion Docker Hub dans les paramètres du proxy de dépendances de votre groupe :
- Pour GitLab 17.11+ (ou la version actuelle de GitLab.com) : accédez aux paramètres de votre groupe > Paquets et registres > Proxy de dépendances.
- Pour GitLab 17.10 : utilisez l'API GraphQL afin de configurer l'authentification.
- Mettez à jour vos pipelines de façon à ce qu'ils utilisent les URL du proxy de dépendances pour la configuration de votre pipeline CI/CD :
image:${CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX}/busybox:latest
Option 4 : envisagez d'acheter un abonnement payant à Docker Hub
Pour les équipes qui utilisent Docker Hub de manière intensive, la mise à niveau vers un abonnement Docker payant (Team ou Business) permet d'accéder à un nombre illimité de pulls, ce qui peut s'avérer la solution la plus simple.
Comment limiter l'impact des nouveaux quotas de Docker Hub ?
Quelle que soit l'option que vous choisissez, tenez compte de ces bonnes pratiques pour réduire au maximum l'impact des nouvelles limites de débit imposées par Docker Hub :
- Utilisez des tags d'image spécifiques au lieu de
latest
pour éviter les pulls inutiles. - Consolidez vos fichiers Docker de façon à ce qu'ils réutilisent les mêmes images de base dans tous vos projets.
- Planifiez l'exécution des pipelines les moins critiques en dehors des heures de pointe.
- Tirez parti intelligemment de la mise en cache pour éviter d'effectuer maintes fois un pull des mêmes images.
Remarque : selon la documentation de Docker Hub, le nombre de pulls augmente dès que vous effectuez le pull d'un manifeste d'image, et non en fonction de la taille de l'image ou du nombre de couches.
Calendrier et prochaines étapes
Dès maintenant
- Mettez en œuvre l'authentification pour les pulls directs depuis Docker Hub.
- Les utilisateurs de GitLab.com peuvent déjà configurer l'authentification Docker Hub pour le proxy de dépendances en utilisant :
- l'API GraphQL, ou
- l'interface utilisateur dans les paramètres de groupe.
- Les utilisateurs de GitLab Self-Managed 17.10 peuvent configurer l'authentification du proxy de dépendances à l'aide de l'API GraphQL.
1er avril 2025
- Les limites de débit de Docker Hub entrent en vigueur.
17 avril 2025
- Sortie de GitLab 17.11 qui prendra en charge l'authentification du proxy de dépendances via l'interface utilisateur pour les instances GitLab Self-Managed.
Nous vous recommandons d'appliquer ces mesures bien dès maintenant pour éviter des échecs de pipelines inattendus. Pour la plupart des utilisateurs, configurer le proxy de dépendances avec l'authentification Docker Hub est la solution la plus efficace à long terme.
Vous avez des questions ou besoin d'aide pour la mise en œuvre ? Consultez ce ticket dans lequel notre équipe fournit une assistance dédiée à ces changements.