Docker a annoncé qu'il va limiter le nombre de pull requests faites à son service dans son offre gratuite. Nous partageons nos stratégies pour atténuer l'impact de cette nouvelle limitation de pull requests pour les utilisateurs et les clients qui gèrent leur propre instance GitLab. Le 24 août 2020, Docker a annoncé des changements dans son modèle d'abonnement et a initié un mouvement vers des limitations basées sur la consommation. Ces limitations concernent le nombre d'images de conteneurs Docker qui peuvent être extraites. Cela prend effet le 1er novembre 2020. Pour les pull requests faites par des utilisateurs anonymes, la limitation est à présent de 100 pulls requests toutes les 6 heures; les utilisateurs authentifiés ont une limite de 200 pull requests par 6 heures.
En tant que membre de la communauté globale du DevOps, nous avons tous pris l'habitude de compter sur Docker comme partie intégrante des processus CI / CD. Il n'est pas surprenant que chez GitLab, ils ont eu des retours de plusieurs membres de la communauté ainsi que de clients qui souhaitaient des conseils car ce changement de limitation Docker pouvait affecter leur flux de travail CI/CD en production.
Utiliser un miroir de registre
Vous pouvez utiliser la fonctionnalité de miroir de registre pour connaître le nombre de pull requests d'images générées sur DockerHub. Quand le miroir est configuré et GitLab Runner indique à Docker d'extraire des images, Docker va vérifier le miroir en premier; si c'est la première fois que l'image est extraite, une connexion va être faite à DockerHub. Les extractions suivantes de cette image utiliserons ensuite votre miroir au lieu de se connecter au DockerHub. Vous pouvez trouver plus de détails sur comment ça marche ici.
Si vous êtes un utilisateur ou un client de GitLab SaaS
Pour les Shared Runners sur GitLab.com ils utilisent le miroir Google pour les images du Docker Hub. Cela signifie que les utilisateurs des CI jobs sur GitLab Shared Runners ne seront pas affectés par cette nouvelle politique concernant les pull requests. Ils vont continuer à surveiller l'impact de ces changements effectués par Docker.
SI vous auto-hébergez des GitLab Runners
Tout d'abord, vérifiez si votre fournisseur d'hébergement ou de cloud ne vous fournit pas déjà un miroir de registre d'images. Si c'est le cas, c'est sûrement l'option la plus simple et la plus performante. Si pour une quelconque raison un registre de miroir hébergé ne peut pas être utilisé, l'administrateur peut installer son propre miroir DockerHub.
Démarrer le miroir de registre
Veuillez suivre les instructions dans la documentation GitLab:
- Connectez-vous sur une machine dédiée où le proxy de miroir de registre tournera
- Assurez-vous que Docker Engine est installé sur cette machine
- Créez un nouveau registre de conteneur
Vous pouvez modifier le numéro de port (6000) pour exposer le registre avec un port différent. Cela démarrera le serveur avec http. Si vous souhaitez activer TLS (https) suivez la documentation officielle.
- Vérifiez l'adresse IP du serveur :
De préférence, choisissez l'adresse IP du réseau privé. Le réseau privé est généralement la solution la plus rapide pour les communications interne entre les machines d'un seul fournisseur (DigitalOcean, AWS, Azure..). Généralement, l'utilisation d'un réseau privé n'est pas prise en compte dans votre limite de bande passante mensuelle.
- Le registre Docker sera accessible sous
MY_REGISTRY_IP:6000
Configurer Docker pour l'utiliser
La partie finale est d'avoir le processus dockerd configuré pour qu'il utilise votre miroir quand docker pull tourne.
Docker
Ajouter l'option --registry-mirror lorsque vous démarrez le daemon Docker dockerd manuellement ou editez /etc/docker/daemon.json et ajoutez la clé et la valeur registry-mirrors pour que le changement soit permanent.
docker+machine executor
Mettez à jour le fichier de configuration du GitLab Runner config.toml pour spécifier engine-registry-mirror à l'intérieur des paramètres MachineOptions.
Docker-in-Docker pour construire des images Docker
Il y a différentes manière d'y parvenir, et cela dépend de votre configuration. Vous en trouverez une liste complète dans notre documentation.
Vérifiez que ça fonctionne
Assurez-vous que Docker est configuré pour utiliser le miroir
Si vous exécutez docker info où dockerd est configuré pour utiliser le miroir vous devriez voir ce qui suit apparaître :
Vérifiez le catalogue du registre
L'API Docker Registry peut vous montrer quel dépôt il a mis en cache localement.
Etant donné que nous avons executé docker pull node pour la première fois avec dockerd configuré pour utiliser le miroir nous pouvons le voir en listant les dépots.
Vérifiez les logs du registre
Lorsque vous faites des pull d'images vous devriez voir des logs venir concernant les informations demandées en exécutant docker logs registry, où registry est le nom du conteneur qui exécute le miroir.
Des alternatives aux miroirs DockerHub
Mettre en place un miroir de registre Docker peut également augmenter vos coûts d'infrastructure. Avec les nouvelles limites de débit DockerHub, il pourrait être utile d'authentifier les pulls au lieu d'avoir votre limite augmentée ou pas de limite du tout (suivant votre abonnement).
Il y a différentes façons de s'authentifier avec DockerHub sur GitLab CI et c'est documenté en détail. Voici quelques exemples:
- la variable
DOCKER_AUTH_CONFIGest fournie. - le fichier
config.jsonest placé dans le répertoire$HOME/.dockerde l'utilisateur exécutant le processus GitLab Runner. - Lancez
docker loginsi vous utilisez un flux de travail Docker-in-Docker.
En résumé
Comme vous pouvez le voir, il y a plusieurs manières de s'adapter aux nouvelles limites du Docker Hub et nous encourageons les utilisateurs à choisir la plus pertinente suivant les besoins de leur organisation. Outre les options décrites dans cet article, il est également possible de rester dans l'écosystème GitLab en utilisant le GitLab Container Proxy, qui sera bientôt disponible pour les utilisateurs Core.
Vous cherchez des utilisateurs ou une instance GitLab hébergée en France ? Rejoignez la Communautés Froggit.
Crédits 
Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction issue du site de GitLab.
