Si nous examinons de près les produits LEGO®, nous pouvons voir qu'ils sont tous constitués des mêmes blocs de construction. Cependant, la composition de ces blocs est le différenciateur clé pour savoir si nous construisons un château ou un vaisseau spatial. C'est à peu près la même chose pour Podman et ses projets frères Buildah, Skopeo et CRI-O. Cependant, au lieu de plastique recyclé, les blocs de construction de nos outils de conteneurs sont constitués de code open source. Le partage de ces blocs de construction nous permet de fournir des outils de conteneurs solides et de niveau entreprise. Les fonctionnalités sont livrées plus rapidement, les bogues sont corrigés plus rapidement et le code est testé au combat. Et bien, au lieu d'apporter de la joie dans les salles de jeux, les outils de conteneurs apportent de la joie dans les centres de données et les postes de travail.
Le bloc de construction le plus basique pour nos outils de conteneurs est la bibliothèque de conteneurs/stockage, qui stocke et gère localement les conteneurs et les images de conteneurs. En montant un niveau plus haut, on trouve la bibliothèque conteneurs/images. Comme son nom l'indique, cette bibliothèque traite des images de conteneurs et est incroyablement puissante. Il nous permet de tirer et de pousser des images, de manipuler des images (par exemple, de changer la compression des couches), d'inspecter les images avec leur configuration et leurs couches, et de copier des images entre les soi-disant transports d'images. Un transport peut faire référence à un stockage de conteneurs local, à un registre de conteneurs, à une archive tar et bien plus encore. Dan Walsh a écrit un excellent article de blog sur les différents transports que je recommande vivement de lire.
La bibliothèque d'images prend également en charge plusieurs fichiers de configuration où, sans aucun doute, le registries.conf est le plus important pour la grande majorité des utilisateurs. Je souhaite dédier ce billet de blog au registries.conf fichier de configuration, expliquez ses différentes options et boutons, et comment nous pouvons les utiliser en production.
Gestion des registres de conteneurs avec registries.conf
Le registries.conf La configuration est en jeu chaque fois que nous poussons ou tirons une image. Ou, plus généralement, chaque fois que nous contactons un registre de conteneurs. C'est une règle simple. L'emplacement à l'échelle du système est /etc/containers/registries.conf , mais si vous souhaitez modifier cela pour un seul utilisateur, vous pouvez créer un nouveau fichier dans $HOME/.config/containers/registries.conf .
Alors plongeons-y dedans. Dans les sections suivantes, nous allons passer en revue quelques exemples qui expliquent les différentes options de configuration dans le registries.conf . Les exemples sont des scénarios réels et peuvent être une source d'inspiration pour aborder votre cas d'utilisation individuel.
Extraction par noms courts
Les humains sont paresseux, et je ne fais pas exception à cela. Il est bien plus pratique de faire un podman pull ubi8 plutôt que podman pull registry.access.redhat.com/ubi8:latest . J'oublie toujours quelle image réside sur quel registre, et il existe de nombreuses images et de nombreux registres. Il existe Docker Hub et Quay.io, ainsi que des registres pour Amazon, Microsoft, Google, Red Hat et de nombreuses autres distributions Linux.
Docker a résolu notre paresse en se résolvant toujours au Docker Hub. Un docker pull alpine résoudra en docker.io/library/alpine:latest , et docker pull repo/image:tag résoudra en docker.io/repo/image:tag (notez le référentiel spécifié). Podman et ses projets frères ne voulaient pas enfermer les utilisateurs dans l'utilisation d'un seul registre, donc les noms courts peuvent être résolus en plus de docker.io, et comme vous pouvez vous y attendre, nous pouvons configurer cela dans le registries.conf comme suit :
unqualified-search-registries = ['registry.fedoraproject.org', 'registry.access.redhat.com', 'registry.centos.org', 'docker.io']
L'extrait ci-dessus est tiré directement de registries.conf dans Fedora 33. Il s'agit d'une liste de registres qui sont contactés dans l'ordre spécifié lors de l'extraction d'une image de nom court. Si l'image est introuvable sur le premier registre, Podman tentera de l'extraire du second registre et ainsi de suite. Buildah et CRI-O suivent la même logique mais notez que Skopeo se normalise toujours sur docker.io.
[ Vous pourriez également aimer : Quelle est la prochaine charge de travail Linux que vous prévoyez de conteneuriser ? ]
Recherche d'images
Semblable à la section précédente sur le tirage, les images sont généralement recherchées par nom. Lors d'une recherche podman search , je ne sais généralement pas ou j'ai simplement oublié sur quel registre l'image donnée se trouve. Lorsque vous utilisez Docker, vous ne pouvez effectuer une recherche que sur Docker Hub. Podman donne plus de liberté aux utilisateurs et permet de rechercher des images sur n'importe quel registre. Et sans surprise, registries.conf a une solution.
Semblable à l'extraction, les unqualified-search-registries sont également utilisés lors de l'utilisation d'un nom court avec podman search . Un podman search foo recherchera les images nommées foo dans tous les registres de recherche non qualifiée.
Les grandes entreprises ont généralement des registres de conteneurs sur site. L'intégration de tels registres dans votre flux de travail est aussi simple que de les ajouter à la liste des registres de recherche non qualifiée.
Alias de noms courts
Les nouvelles versions de Podman, Buildah et CRI-O sont livrées avec une nouvelle façon de résoudre les noms courts, principalement en utilisant des alias. Les alias sont une simple table TOML [aliases] sous la forme "name" = "value" , similaire au fonctionnement des alias Bash. Nous maintenons une liste centrale d'alias avec la communauté en amont sur github.com/containers/shortnames . Si vous possédez une image et souhaitez avoir un alias, n'hésitez pas à ouvrir une demande d'extraction ou à nous contacter.
Certaines distributions, comme RHEL8, prévoient d'envoyer leurs propres listes de noms abrégés pour aider les utilisateurs et les empêcher d'extraire accidentellement des images du mauvais registre.
Expliquer en détail le fonctionnement des alias de nom court étofferait considérablement cet article de blog. Si vous êtes intéressé, veuillez vous reporter à un article de blog précédent sur les alias de nom court.
Configuration d'un registre de conteneurs local
L'exécution d'un registre de conteneurs local est assez courante. J'en ai un qui fonctionne tout le temps, je peux donc mettre en cache des images et développer et tester de nouvelles fonctionnalités telles que les mises à jour automatiques dans Podman. La bande passante de mon bureau à domicile est limitée, j'apprécie donc les poussées et les tractions rapides. Étant donné que tout s'exécute localement, je n'ai pas à me soucier de la configuration de TLS pour le registre. Cela implique de se connecter au registre via HTTP plutôt que via HTTPS. Podman vous permet de le faire en spécifiant --tls-verify=false sur la ligne de commande, ce qui ignorera la vérification TLS et autorisera les connexions non sécurisées.
Une approche alternative pour ignorer la vérification TLS via la ligne de commande consiste à utiliser le registries.conf . Cela peut être plus pratique, en particulier pour les scripts automatisés où nous ne voulons pas ajouter manuellement des indicateurs de ligne de commande. Jetons un coup d'œil à l'extrait de configuration ci-dessous.
[[registry]]
location="localhost:5000"
insecure=true
Le format des registres.conf est TOML. Les doubles accolades de [[registry]] indiquent que nous pouvons spécifier une liste (ou table) de [registry] objets. Dans cet exemple, il n'y a qu'un seul registre où l'emplacement (c'est-à-dire son adresse) est défini sur localhost:5000 . C'est là qu'un registre local s'exécute généralement. Chaque fois que les containers/image bibliothèque se connecte à un registre de conteneurs avec cet emplacement, il recherchera sa configuration et agira en conséquence. Dans ce cas, le registre est configuré pour être non sécurisé et la vérification TLS sera ignorée. Podman et les autres outils de conteneur peuvent désormais communiquer avec le registre local sans que les connexions soient rejetées.
Bloquer un registre, un espace de noms ou une image
Si vous souhaitez empêcher les utilisateurs ou les outils d'extraire d'un registre spécifique, vous pouvez procéder comme suit.
[[registry]]
location="registry.example.org"
blocked=true
Le blocked=true empêche les connexions à ce registre, ou du moins bloque l'extraction de données à partir de celui-ci.
Cependant, il est étonnamment courant chez les utilisateurs de bloquer uniquement des espaces de noms spécifiques ou des images individuelles, mais pas l'intégralité du registre. Supposons que nous voulions empêcher les utilisateurs d'extraire des images de l'espace de noms registry.example.org/namespace . Le registries.conf ressemblera maintenant à ceci :
[[registry]]]
location="registry.example.org"
prefix="registry.example.org/example"
blocked=true
Je viens d'introduire un nouveau bouton de configuration :prefix . Un préfixe indique uniquement de sélectionner la configuration spécifiée lorsque nous tentons d'extraire une image qui correspond au préfixe spécifique. Par exemple, si nous exécutons un podman pull registry.example.org/example/image:latest , le préfixe spécifié correspondrait et Podman serait empêché d'extraire l'image. Si vous souhaitez bloquer une image spécifique, vous pouvez la définir en utilisant ce qui suit :
prefix="registry.example.org/namespace/image"
L'utilisation d'un préfixe est un outil très puissant pour répondre à toutes sortes de cas d'utilisation. Il peut être combiné avec tous les boutons d'un [registry] . Notez que l'utilisation d'un préfixe est facultative. Si aucun n'est spécifié, le préfixe sera par défaut l'emplacement (obligatoire).
Mise en miroir des registres
Supposons que nous exécutons notre charge de travail dans un environnement isolé. Tous nos serveurs sont déconnectés d'internet. Il y a plusieurs raisons à cela. Nous pouvons fonctionner à la périphérie ou fonctionner dans un environnement hautement sensible à la sécurité qui nous interdit de nous connecter à Internet. Dans ce cas, nous ne pouvons pas nous connecter au registre d'origine mais devons exécuter un registre qui reflète le contenu du réseau local.
Un miroir de registre est un registre qui sera contacté avant d'essayer d'extraire de celui d'origine. Il s'agit d'un cas d'utilisation courant et de l'une des demandes de fonctionnalités les plus anciennes de l'écosystème des conteneurs.
[[registry]]
location="registry.access.redhat.com"
[[registry.mirror]]
location="internal.registry.mirror"
Avec cette configuration, lors de l'extraction de l'image de base universelle via podman pull ubi8 , l'image serait extraite du miroir au lieu du registre de conteneurs de Red Hat.
Notez que nous pouvons spécifier plusieurs miroirs qui seront contactés dans l'ordre spécifié. Voyons rapidement ce que cela signifie :
[[registry]]
location="registry.example.com"
[[registry.mirror]]
location="mirror-1.com"
[[registry.mirror]]
location="mirror-2.com"
[[registry.mirror]]
location="mirror-3.com"
Supposons que nous essayons d'extraire l'image registry.example.com/myimage:latest . Les miroirs sont contactés dans l'ordre spécifié (c'est-à-dire de haut en bas), ce qui signifie que Podman essaiera d'abord d'extraire l'image de mirror-1.com . Si l'image n'est pas présente ou si l'extraction échoue pour d'autres raisons, Podman contactera mirror-2.com et ainsi de suite. Si toutes les extractions de miroir échouent, Podman contactera le principal registry.example.com .
Notez que les miroirs prennent également en charge le insecure bouton. Si vous souhaitez ignorer la vérification TLS pour un miroir spécifique, ajoutez simplement insecure=true .
Remappage des références
Comme nous l'avons vu ci-dessus, un prefix est utilisé pour sélectionner un [registry] spécifique dans le registries.conf . Bien que les préfixes soient un moyen puissant pour empêcher l'extraction d'espaces de noms spécifiques ou de certaines images, ils peuvent également être utilisés pour remapper des images entières. Semblable aux miroirs, nous pouvons utiliser un préfixe pour extraire d'un registre différent et d'un espace de noms différent.
Pour illustrer ce que je veux dire par remapper , considérons que nous courons dans un environnement isolé. Nous ne pouvons pas accéder aux registres de conteneurs car nous sommes déconnectés d'Internet. Notre charge de travail utilise des images de Quay.io, Docker Hub et du registre de conteneurs de Red Hat. Bien que nous puissions avoir un miroir réseau local par registre, nous pouvons également n'en utiliser qu'un avec la configuration suivante.
[[registry]]
prefix="quay.io"
location="internal.registry.mirror/quay"
[[registry]]
prefix="docker.io"
location="internal.registry.mirror/docker"
[[registry]]
prefix="registry.access.redhat.com"
location="internal.registry.mirror/redhat"
Un podman pull quay.io/buildah/stable:latest va maintenant extraire à la place internal.registry.mirror/quay/buildah/stable:latest . Cependant, l'image extraite restera quay.io/buildah/stable:latest puisque le remappage et la mise en miroir se produisent de manière transparente pour Podman et les autres outils de conteneur.
Comme nous pouvons le voir dans l'extrait ci-dessus, internal.registry.mirror est notre miroir réseau local que nous utilisons pour extraire des images au nom de Quay.io, Docker Hub et du registre de conteneurs de Red Hat. Les images de chaque registre résident sur des espaces de noms distincts sur le registre (c'est-à-dire "quay", "docker", "redhat") - une astuce simple mais puissante pour remapper les images lors de l'extraction. Vous pouvez vous demander comment nous pouvons pré-remplir le miroir interne avec les images des trois registres. Je ne recommande pas de le faire manuellement mais d'utiliser skopeo sync Au lieu. Avec skopeo sync , un administrateur système peut facilement charger toutes les images sur une clé USB, les transférer dans un cluster isolé et précharger le miroir.
Il existe d'innombrables cas d'utilisation où un tel remappage peut aider. Par exemple, lors de l'utilisation d'un autre registre pendant les tests, il peut être utile d'extraire de manière transparente d'un autre registre (test ou staging) qu'en production. Aucune modification de code n'est nécessaire.
Tom Sweeney et Ed Santiago ont utilisé le remappage pour développer une solution créative pour répondre aux limites de débit de Docker Hub. Fin novembre 2020, Docker Hub a commencé à limiter le nombre de tirages par utilisateur dans un délai donné. Au début, nous étions inquiets car une grande partie de nos systèmes de test et d'intégration continue utilisaient des images Docker Hub. Mais avec un simple changement dans le registries.conf sur nos systèmes, Tom et Ed ont trouvé une excellente solution. Cela nous a épargné la tâche manuelle et fastidieuse de changer toutes les images faisant référence à docker.io dans nos tests.
Gestion avancée de la configuration via des fichiers de configuration supplémentaires
La gestion des configurations est difficile. Nos systèmes sont mis à jour en permanence, et les mises à jour peuvent entraîner des changements de configuration. Nous pouvons vouloir ajouter de nouveaux registres, configurer de nouveaux miroirs, corriger les paramètres précédents ou étendre la configuration par défaut de Fedora. Les motivations sont multiples, et pour certaines registries.conf le prend en charge via des fichiers de configuration dits "drop-in".
Lors du chargement de la configuration, les containers/image la bibliothèque chargera d'abord le fichier de configuration principal à /etc/containers/registries.conf puis tous les fichiers dans le /etc/containers/registries.conf.d répertoire par ordre alphanumérique.
Utiliser un tel drop-in registries.conf fichiers est simple. Placez simplement un .conf fichier dans le répertoire et Podman obtiendra la configuration mise à jour. Notez que les tables de la configuration sont fusionnées tandis que les boutons simples sont remplacés. Cela signifie, en pratique, que le [[registry]] tableau peut facilement être étendu avec de nouveaux registres. Si un registre avec le même préfixe existe déjà, le paramètre de registre sera remplacé. Il en va de même pour les [aliases] table. Les boutons de configuration simples tels que les registres de recherche non qualifiés sont toujours remplacés.
[ Vous débutez avec les conteneurs ? Découvrez ce cours gratuit. Déploiement d'applications conteneurisées :présentation technique. ]
Conclusion
Le registries.conf est un élément central de nos outils de conteneurs. Il permet de configurer toutes sortes de propriétés lors de la communication avec un registre de conteneurs. Si vous souhaitez étudier la configuration plus en détail, vous pouvez soit faire un man containers-registries.conf pour lire la page de manuel sur votre machine Linux ou consulter la documentation en amont.