Dans cet article, je vous montre comment utiliser Quay.io pour héberger des images de conteneurs et comment éviter de surcharger votre registre de conteneurs en limitant les demandes d'images inutiles. J'utilise Buildah, Skopeo et Quay.io, mais les conseils pour limiter les extractions d'images fonctionneront avec n'importe quel registre de conteneurs que vous pourriez utiliser.
Fin novembre 2020, Docker Hub a commencé à étrangler ou à limiter le nombre d'images de conteneurs que vous pouvez extraire de manière anonyme ou en tant que Hub Docker gratuit utilisateur. Si vous êtes un anonyme utilisateur, vous ne pouvez extraire que 100 images de conteneurs sur une période de 6 heures. Si vous êtes un utilisateur de Docker Hub gratuit, vous pouvez extraire 200 images de conteneurs sur une période de 6 heures.
Lorsque nous effectuons nos tests fonctionnels des outils de conteneur sur lesquels nous travaillons, comme Buildah et Podman, cette limite n'est généralement pas un problème. Par exemple, lorsque vous créez une image de conteneur à l'aide d'un Containerfile, puis que vous testez le conteneur résultant pour voir comment il se comporte après avoir exécuté des commandes particulières dessus, vous extrayez généralement l'image de conteneur principale spécifiée dans le FROM instruction dans le Containerfile une fois. Si vous reconstruisez ultérieurement le conteneur à partir de zéro, vous réutilisez généralement l'image de conteneur déjà extraite et n'atteignez donc pas le compteur. Dans ce scénario, l'étranglement ne cause aucune douleur, mais c'est toujours dans mon esprit.
Réduction initiale des interactions Docker Hub
Nous avons cependant trouvé un endroit où nous avons rencontré l'étranglement sur Docker Hub. Ed, mon collègue et l'un des responsables QE du moteur de conteneur, a créé une très belle solution de contournement. Tout d'abord, un peu de contexte. Il y a plusieurs mois, Ed a réduit le nombre de fois où nous avons récupéré les images de conteneur utilisées par les tests d'intégration continue (CI) de Buildah en réutilisant le cache que Podman avait déjà créé. Avant cela, le Buildah CI abusait des pauvres alpine image de conteneur qui réside dans le Docker Hub sur docker.io/library sans fin, avec le fedora , busybox , et quelques autres images de conteneurs assorties là-bas, les tirant une multitude de fois. Ce schéma de prélecture mis au point par Ed a non seulement accéléré nos tests, mais il nous a également permis de réduire la bande passante que nous utilisions sur Docker Hub.
Malgré ces changements, le Buildah CI a commencé à échouer plusieurs fois par jour en novembre avec cette erreur :Vous avez atteint votre limite de taux de traction . Atteindre la limite de taux était dû au nombre de fois où nos tests CI ont été exécutés chaque jour. Même si la prélecture avait réduit le nombre de fois que le CI Buildah devait extraire les images, le CI se heurtait toujours à la limitation du Docker Hub.
[ Vous aimerez peut-être également lire : Comment mettre en œuvre un simple registre d'images de conteneurs Linux personnel/privé à usage interne ]
Résoudre la limitation
La solution fournie par Ed utilise la flexibilité de Buildah et les outils de conteneur sous le référentiel Containers sur GitHub. Tout d'abord, Ed a créé un compte gratuit sur quay.io, y a copié des images et les a rendues publiques. Ed a choisi quay.io parce que c'est là que nous stockons beaucoup de nos images de conteneurs, et c'est pratique pour nous. Néanmoins, il aurait pu s'agir d'un référentiel d'images de conteneurs local ou du référentiel d'une autre entreprise.
En prime, quay.io n'est pas limité comme Docker Hub.
Utiliser Skopeo pour copier l'image initiale
Disons que votre projet nécessite le alpine et centos:8 images. Vous commencerez par créer un compte gratuit sur quay.io, avec le nom myquayaccountname . Sur un hôte avec Skopeo installé, vous exécuteriez alors :
skopeo login -u myquayaccountname quay.io
skopeo copy --all docker://docker.io/library/alpine:latest docker://quay.io/myquayaccountname/alpine:latest
Répétez ensuite en remplaçant alpine:latest avec centos:8 , et ainsi de suite pour toutes les images nécessaires.
Configurer quay.io
Les images sont maintenant sur quay.io, mais elles sont privées par défaut. Pour les rendre publiques, reconnectez-vous à l'interface utilisateur Web quay.io, cliquez sur chaque nom d'image. Cela vous amènera à une nouvelle page montrant les détails de l'image. Cliquez sur l'icône d'engrenage en bas de la barre de navigation de gauche, recherchez le bouton Rendre public bouton et appuyez dessus. Vous devrez confirmer OK puis répétez pour toutes les images affichant une icône de cadenas rose.
Dans notre cas, la première chose qu'Ed a faite a été d'extraire les images de conteneur que nous utilisons de Docker Hub et de les placer dans le référentiel d'images de conteneur libpod sur quay.io qu'il avait créé.
Configurer les registres.conf pour la mise en miroir
Nous avons résolu le problème de limitation en déplaçant ces images. Cependant, nous avions maintenant le problème de changer les centaines, voire les milliers de références de tests à ces images afin que le CI tire de quay.io/libpod plutôt que docker.io/library . Ce changement nécessaire était une vitrine parfaite pour la flexibilité qu'offrent les outils de conteneurs. Ed a résolu ce problème en modifiant relativement peu la configuration, plutôt qu'en modifiant globalement tous les tests.
Voici ce qu'Ed a élaboré. Lorsque Buildah recherche une image de conteneur, elle n'est pas codée en dur pour être extraite de docker.io. Au lieu de cela, il lit le fichier /etc/containers/registries.conf et détermine de quel référentiel d'images de conteneurs Buildah doit tirer.
Ed a simplement changé ce fichier de sorte que quay.io/libpod est contacté chaque fois que les tests cherchaient docker.io/library . En utilisant notre exemple ci-dessus, vous ajouteriez les lignes suivantes à /etc/containers/registries.conf sur tous les systèmes où vous souhaitez utiliser votre cache :
toml
[[registry]]
prefix=" docker.io/library"
location=" quay.io/myquayaccountname"
Tous les podman pull alpine suivants les commandes seront extraites de votre miroir. Vous pouvez voir la modification qu'Ed a apportée à Podman ici dans cette demande d'extraction.
Pour mettre davantage en évidence les capacités de mise en miroir dans le projet conteneurs/image, que Buildah utilise, vous pouvez définir un miroir pour les images de conteneurs vous permettant de tirer avec l'ancien nom d'un registre différent. La mise en miroir a été initialement ajoutée pour prendre en charge les environnements déconnectés. Les environnements sans connexion Internet exécutant des logiciels comme OpenShift ne peuvent souvent pas extraire d'images de registres non locaux. Nous permettons donc aux utilisateurs de refléter les images dans des registres internes sans avoir à modifier le logiciel.
Voici un extrait avec plus d'informations du containers-registries.conf fichier, qui fait partie du container/image projet :
$ man containers-registries.conf
Remapping and mirroring registries
The user-specified image reference is, primarily, a "logical" image name, always
used for naming the image. By default, the image reference also directly specifies
the registry and repository to use, but the following options can be used to redi‐
rect the underlying accesses to different registry servers or locations (e.g., to
support configurations with no access to the internet without having to change
Dockerfiles, or to add redundancy). Mises en garde :Cette procédure effectue une copie unique des images de conteneur. Votre image en cache ne récupérera pas comme par magie les correctifs de sécurité envoyés à docker.io. (Il ne captera pas non plus le vandalisme aléatoire tel que les fichiers binaires supprimés ou d'autres changements de rupture - ne me lancez pas.)
Travaux supplémentaires
Compte tenu de la mise en garde, la maintenance de l'image dépend maintenant de vous et vous pouvez envisager d'ajouter les commandes Skopeo pour copier l'image au début de votre procédure de test. Une autre solution de contournement possible consiste à activer un miroir public tel que Google Cloud Registry (GCR) ou éventuellement à affiner davantage le registries.conf fichier pour configurer plusieurs miroirs. Mieux encore, c'est probablement un bon choix pour la commande skopeo-sync car il a une belle CLI et peut être utilisé avec un fichier YAML offrant un large éventail d'options de configuration.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Récapitulez
Il existe différentes façons de résoudre la limitation de Docker Hub mise en place, mais la méthode utilisée par Ed était rapide, indolore et a remis notre CI en ligne rapidement. Maintenant que nous avons un peu de répit, nous pouvons travailler sur une solution plus complète.
Avec ce changement en place, les tests Buildah ne dépassent plus la limite et ne sont plus limités par Docker Hub, le problème de limitation est donc résolu.