L'un des problèmes de la programmation informatique est que les mêmes noms sont constamment utilisés à des fins différentes. Par exemple, le terme espace de noms est utilisé de différentes manières. Je suis souvent confus lorsque les gens parlent d'espaces de noms dans Kubernetes. Par exemple, certaines personnes entendent le terme et pensent à des clusters virtuels, mais quand je l'entends, je pense aux espaces de noms Linux utilisés avec les pods et les conteneurs. De même, image peut faire référence à une image de machine virtuelle, à une image de conteneur ou à une image OCI stockée dans un registre de conteneurs.
[ Vous pourriez également aimer : 7 fonctionnalités amusantes de transport d'images/de conteneurs Linux ]
Mais dans le monde des conteneurs, il n'y a pas de terme plus surutilisé que container .
Récemment, un utilisateur a créé un problème Podman, exprimant sa frustration face à cette terminologie :
Terminologie peu claire :image ou conteneur
D'après ce que j'ai compris, cette image est un modèle en lecture seule, alors que le conteneur est un élément en lecture-écriture. Toujours. Ainsi, si quelque chose est un conteneur, alors podman et buildah le considèrent comme un conteneur. Quand quelque chose est une image, alors podman et buildah le considèrent comme une image.
J'appelle buildah à partir de --name abc scratch. les images buildah et les images podman ont la même sortie et elles ne considèrent pas la nouvelle chose comme une image.
podman containers ls ne montre rien, donc la nouveauté n'est pas un conteneur du point de vue de podman.
buildah containers renvoie cependant la nouvelle chose, de sorte que la nouvelle chose est un conteneur (avec CONTAINER NAME=abc , IMAGE NAME=scratch , BUILDER=*=yes IMAGE ID ="").
Donc, la nouveauté est un conteneur du point de vue buildah, mais ce n'est pas un conteneur du point de vue du podman. C'est complètement déroutant.
Veuillez préciser la différence entre le conteneur en termes de buildah et les conteneurs en termes de podman.
Je pense aux conteneurs comme l'exécution de processus dans un environnement ou quelque chose qui est prêt à être exécuté. En revanche, les images sont des conteneurs validés, qui sont prêts à être partagés avec d'autres pour créer de nouveaux conteneurs.
Les moteurs de conteneurs avec lesquels nous travaillons (Podman, Buildah, CRI-O et Skopeo) partagent tous le même concept d'images.
Les images sont définies dans des conteneurs/image et stockées dans différents stockages ou transports, tels que des registres de conteneurs, des archives Docker, des archives OCI, docker-daemon et des conteneurs/stockage. J'ai écrit sur ces types de stockage ou transports dans un article précédent.
La plupart des gens pensent que les images sont placées dans des conteneurs/stockages ou des registres de conteneurs. Pour la suite de cette description, nous nous concentrerons sur les conteneurs/stockage.
Soit dit en passant, Skopeo n'est pas vraiment un moteur de conteneurs puisqu'il n'a pas de concept de conteneurs. Au lieu de cela, Skopeo traite uniquement les images de conteneurs et les déplace entre différents types de stockage de conteneurs.
Conteneur/conteneurs de stockage
La bibliothèque de conteneur/stockage fournit également son propre concept de conteneur de stockage. Fondamentalement, les conteneurs de stockage sont du contenu de stockage intermédiaire qui n'a pas encore été validé. Considérez cela comme des fichiers sur disque et du JSON décrivant le contenu.
Podman, Buildah et CRI-O utilisent tous des conteneurs de stockage . Les trois moteurs de conteneurs disposent également de données supplémentaires qui leur sont propres.
Conteneurs de construction
Les conteneurs Buildah incluent du contenu supplémentaire faisant référence aux différentes commandes qui composent le Containerfile ou Dockerfile.
Par exemple, Workingdir, les variables Env et d'autres données sont utilisées pour créer une image de conteneur.
Conteneurs Podman
Podman possède son propre magasin de données de données liées à un conteneur Podman. Il y a beaucoup plus de données stockées dans la base de données Podman que dans la base de données Buildah. Vous pourriez considérer la base de données Buildah comme un sous-ensemble de la base de données Podman.
Conteneurs CRI-O
CRI-O dispose également de son propre datastore pour décrire ses conteneurs.
Les trois outils ont évolué différemment et ont des idées et des exigences différentes pour leurs propres conteneurs.
Par exemple, les conteneurs CRI-O ont évolué en s'appuyant sur un seul démon les contrôlant. L'accent est mis sur les performances et la nécessité de partager des centaines/milliers de réponses au CRI Kubernetes par seconde. Étant donné que CRI-O sait qu'il est le seul à s'occuper du magasin de données, il peut profiter du stockage des informations en mémoire. CRI-O n'a pas besoin de se préoccuper des autres processus entrant et changeant les conteneurs à son insu.
Podman, en revanche, doit gérer plusieurs utilisateurs de ses conteneurs en même temps. Il doit s'appuyer davantage sur le verrouillage du système de fichiers et garantir que des centaines d'exécutables Podman peuvent partager de manière fiable le même magasin de données. Nous avons parlé d'éventuellement fusionner le magasin de données de Podman dans CRI-O afin que CRI-O et Podman puissent mieux travailler ensemble, mais avec le temps, nous estimons que le rapport risque/bénéfice est difficile à justifier la fusion.
Buildah a également été développé comme un outil indépendant. Les mainteneurs ont repoussé le poids et la complexité inutiles du magasin de données Podman pour peu ou pas d'avantages supplémentaires. Les conteneurs Buildah ont un seul objectif :créer une image de conteneur, alors que la plupart des conteneurs Podman concernent davantage l'exécution d'applications et de services. Les conteneurs Buildah ne contiennent pas toutes les informations dont Podman aurait besoin.
Comment Podman gérerait-il un conteneur créé avec le buildah from scratch commande ?
Nous aurions encore besoin de traiter différemment ces conteneurs partiellement créés. Par conséquent, Podman les considère comme équivalents ou même répertoriés par défaut dans podman ps commande conduirait les utilisateurs à la confusion.
Compatibilité
Podman peut réellement fonctionner avec ces conteneurs.
Les dernières versions de Podman peuvent désormais lister les conteneurs de stockage disponibles sur le système :
$ podman ps -a --external | grep buildah
578edf9430ee scratch buildah 13 days ago storage working-container Vous pouvez monter et démonter ces conteneurs :
# podman mount working-container
/home/dwalsh/.local/share/containers/storage/overlay/a4f596beaabdc78efc7694a67d690097e327aa12bbc59165d011e62b646e93c0/merged
# podman unmount working-container
working-container Vous pouvez également supprimer ces conteneurs :
$ podman rm working-container
working-container
Vous pouvez également créer ces conteneurs à l'aide de podman build . Bien sûr, ces conteneurs ne sont créés que temporairement lors de la construction. Étant donné que ces conteneurs Buildah n'ont pas les mêmes données qu'un conteneur Podman, Podman ne peut pas les démarrer et les arrêter, et podman ps ne les montre pas lorsqu'ils sont en cours d'exécution.
Podman a également une capacité similaire à travailler avec des conteneurs CRI-O.
[ Apprenez les bases de l'utilisation de Kubernetes dans cet aide-mémoire gratuit. ]
Récapitulez
En ce qui concerne le terme conteneur , le contexte est souvent critique. Comprendre la différence entre les utilisations est essentiel. En ce qui concerne nos outils de conteneur, nous partageons la plupart du contenu, du stockage et des bibliothèques sous-jacents. Mais il existe des raisons légitimes pour lesquelles chaque outil a des concepts ou des définitions légèrement différents ou leurs conteneurs.