test: exported blogposts
Compare changes
Files
3- Plumtree3D authored
+ 0
− 114
Le 24 août 2020, [Docker a annoncé des changements dans son modèle d'abonnement](https://www.docker.com/blog/scaling-docker-to-serve-millions-more-developers-network-egress/) 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](https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/topics/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.
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.](https://docs.docker.com/registry/recipes/mirror/#how-does-it-work)
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.
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](https://docs.docker.com/registry/recipes/mirror/).
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.
Mettre en place un miroir de registre Docker peut également augmenter vos coûts d'infrastructure. Avec les nouvelles [limites de débit DockerHub,](https://docs.docker.com/docker-hub/download-rate-limit/) 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).
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](https://about.gitlab.com/blog/2020/10/30/minor-breaking-change-dependency-proxy/).
**Crédits** [](https://creativecommons.org/licenses/by-sa/4.0/deed.fr) Le contenu de cet article est en Licence Libre Creative Commons Cet article est une traduction [issue du site de GitLab.](https://about.gitlab.com/blog/2020/10/30/mitigating-the-impact-of-docker-hub-pull-requests-limits/)