Blog Annonces Nouvelles limites de Docker Hub : vos pipelines GitLab CI/CD sont impactés
Mise à jour : March 28, 2025
Lecture : 7 min

Nouvelles limites de Docker Hub : vos pipelines GitLab CI/CD sont impactés

Les nouvelles limites de Docker Hub relatives aux pulls d'images vont affecter les pipelines GitLab. Voici ce qu'il faut savoir.

plan - cover

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 :

  1. Effectuez un pull de l'image depuis Docker Hub.
  2. Attribuez-lui un tag adapté à votre registre de conteneurs GitLab.
  3. Effectuez un push de l'image dans votre registre de conteneurs GitLab.
  4. 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 :

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

Votre avis nous intéresse

Cet article de blog vous a plu ou vous avez des questions ou des commentaires ? Partagez vos réflexions en créant un nouveau sujet dans le forum de la communauté GitLab. Partager votre expérience

Lancez-vous dès maintenant

Découvrez comment la plateforme DevSecOps unifiée de GitLab peut aider votre équipe.

Commencer un essai gratuit

Découvrez le forfait qui convient le mieux à votre équipe

En savoir plus sur la tarification

Découvrez ce que GitLab peut offrir à votre équipe

Échanger avec un expert