Docker Hub quotas strictes dés le 1er Avril 2025

Publié le : 25/03/2025

Ce n’est pas un poisson d’avril : à partir du 1er avril 2025, Docker Hub appliquera strictement ses limites de téléchargement d’images, et cela va impacter directement vos pipelines GitLab CI/CD. Si vous utilisez le Dependency Proxy sans authentification ou si vos runners tirent régulièrement des images publiques, vous risquez des échecs de jobs en cascade. Heureusement, GitLab anticipe ces changements dès la version 17.11. Voyons ensemble comment s’y préparer efficacement.

Les nouvelles limites de Docker Hub expliquées

Depuis plusieurs années, Docker Hub impose des restrictions sur le nombre de téléchargements d’images pour limiter les abus et garantir la disponibilité du service. Mais à partir du 1ᵉʳ avril 2025, ces limites seront activement appliquées, avec un impact direct sur les workflows CI/CD non configurés correctement.

Voici les quotas officiels :

Utilisateurs non authentifiés : 10 pulls d’images par heure.
Utilisateurs authentifiés avec un compte gratuit : 100 pulls d’images par heure.
Comptes payants (Pro, Team, Business) : pulls illimités, sous réserve d’un usage conforme.

Concrètement, si on n’a pas configuré d’authentification vers Docker Hub dans mes pipelines, chaque téléchargement d’image de base (alpine, node, python, etc.) est comptabilisé. Or, dans un environnement partagé, ce quota peut être atteint très rapidement, provoquant des erreurs HTTP 429 (Too Many Requests).

Autre point important : ces limites s’appliquent aussi aux services intermédiaires comme le Dependency Proxy de GitLab, tant qu’ils ne sont pas configurés avec un compte Docker Hub authentifié.

Cela veut dire qu’un simple docker pull dans un script, ou une image définie via image: dans mon fichier .gitlab-ci.yml, peut suffire à faire échouer un pipeline si la limite est atteinte.

C’est donc le bon moment pour réviser la façon dont mes runners accèdent aux images Docker.

Les solutions proposées par GitLab

Face à l’entrée en vigueur stricte des quotas Docker Hub, GitLab a pris plusieurs mesures pour éviter que vos pipelines tombent en panne. L’objectif : permettre à chaque équipe de continuer à builder, tester et déployer sans surprise.

Solution 1 : Authentifier le Dependency Proxy avec Docker Hub

À partir de GitLab 17.11 (annoncée pour le 17 Avril), ont peut configurer une authentification Docker Hub directement dans l’interface web de GitLab, au niveau du groupe. Cela permet au Dependency Proxy de tirer les images en tant qu’utilisateur authentifié, et donc d’augmenter le quota de 10 à 100 pulls par tranche de 6 heures.

Avec la version 17.10, il faut passer par l’API GraphQL pour définir manuellement ces identifiants. GitLab simplifie donc grandement la démarche.

👉 Documentation officielle de GitLab sur le Dependency Proxy ↗

Solution 2 : Ajouter les identifiants Docker Hub dans mes variables CI/CD

Même sans utiliser le proxy, on peut authentifier mes pulls Docker en ajoutant une variable DOCKER_AUTH_CONFIG dans les paramètres CI/CD de mon projet ou groupe.

Voici un exemple de contenu de cette variable (à adapter avec mes identifiants) :

{
  "auths": {
    "https://index.docker.io/v1/": {
      "auth": "xxxxxxx=="
    }
  }
}

Vous vous assurez bien entendu de masquer cette variable (Masked) pour éviter toute fuite.

Solution 3 : Utiliser le registre Docker intégré à GitLab

Pour ne plus dépendre du tout de Docker Hub, ont peut héberger ses images fréquemment utilisées dans le GitLab Container Registry. C’est particulièrement utile pour les images de base (alpine, python, node, etc.).

Voici la démarche :

docker pull python:3.12
docker tag python:3.12 registry.gitlab.com/mon-groupe/mon-projet/python:3.12
docker push registry.gitlab.com/mon-groupe/mon-projet/python:3.12

Puis, dans mon fichier .gitlab-ci.yml :

image: registry.gitlab.com/mon-groupe/mon-projet/python:3.12

Résultat : mes pipelines ne sollicitent plus Docker Hub pour cette image.

Solution 4 : Passer à un abonnement Docker Hub Pro ou Team

Si mon usage justifie un volume de pulls élevé, une autre solution est de souscrire à un abonnement Docker Hub Pro ou Team, pour débloquer les limites de téléchargement.

Je peux alors configurer ces identifiants dans GitLab (comme vu plus haut), que ce soit pour le Dependency Proxy ou pour mes jobs CI/CD individuels.

Conclusion : adopter une approche hybride et durable

Les limitations de taux imposées par Docker Hub ne sont pas nouvelles, mais leur application stricte à partir du 1er avril 2025 transforme cette contrainte en risque réel pour mes pipelines GitLab CI/CD. Il serait imprudent de miser uniquement sur des ajustements temporaires ou de croiser les doigts en espérant passer entre les mailles du filet.

À mon sens, la solution la plus fiable passe par une approche hybride :

Authentifier les accès Docker Hub dans GitLab (CI/CD variables ou Dependency Proxy) pour bénéficier de quotas étendus.
Migrer les images critiques vers un registre privé et contrôlé, comme le GitLab Container Registry, mais aussi des solutions externes et robustes comme Harbor ou Nexus. Ces registres offrent un meilleur contrôle, une mise en cache locale, des règles de sécurité personnalisées et une haute disponibilité.

On peut ainsi construire un écosystème de build résilient, moins dépendant d’un service tiers, tout en respectant les bonnes pratiques DevOps. Ce changement n’est pas qu’une contrainte, c’est aussi l’opportunité de reprendre la main sur la chaîne d’approvisionnement logicielle de mes projets.

Bref, le 1er avril c’est demain. Au boulot !

Merci à Guillaume ↗ qui m’a remonté l’info.

Source ↗