Bien qu'il existe de nombreux bons blogs et tutoriels sur Podman et Buildah, les utilisateurs de Docker manquent clairement d'explications claires et concises sur la façon dont ils passent à Podman, pourquoi Buildah est nécessaire dans d'autres problèmes de ce type.
Nous essaierons de répondre à ces questions et de vous expliquer comment migrer en toute transparence de Docker vers Podman.
Comment fonctionne Docker
Commençons par clarifier le fonctionnement de Docker afin de comprendre pourquoi Podman et Buildah sont nés. Comme vous le savez, les commandes Docker ne fonctionnent que lorsque le processus du démon Docker est en cours d'exécution. L'idée avec le démon, semble-t-il, était de rassembler en un seul endroit tous les trucs sympas que Docker fait, et en même temps d'organiser des API utiles pour travailler avec lui pour l'avenir. Comme le montre la figure ci-dessous, le démon Docker contient toutes les fonctionnalités nécessaires pour effectuer les tâches suivantes:
- Tirer et pousser des opérations lorsque vous travaillez avec le registre d'images;
- Créer des copies d'images dans le stockage de conteneur local et ajouter des couches à ces conteneurs;
- Validation des modifications dans les conteneurs et suppression des images de conteneur du référentiel local sur l'hôte;
- Demande au noyau du système d'exploitation de lancer le conteneur dans l'espace de noms, cgroup, etc. correspondant
En substance, le démon Docker s'occupe de tout le travail avec les registres, les images, les conteneurs et le noyau. Et vous lui dites simplement quoi faire via l'interface de ligne de commande (CLI).
Ici, nous ne peserons pas les avantages et les inconvénients de cette approche, lorsque tout est assemblé en un seul processus démoniaque. De nombreux arguments peuvent être avancés en sa faveur, et au moment de l'émergence de Docker, cela avait tout son sens. Cependant, avec l'utilisation active de Docker, des questions ont commencé à lui surgir, par exemple:
- Un processus unique signifie un point de défaillance unique;
- Le processus démon possède tous les processus enfants (exécution de conteneurs);
- Lorsque le démon part, les processus enfants restent orphelins;
- L'assemblage du conteneur a des trous de sécurité;
- Pour effectuer des opérations Docker, les utilisateurs ont besoin de privilèges root complets.
Il y avait d'autres plaintes. On peut ne pas être d'accord avec cela ou dire que ces lacunes ont déjà été éliminées, mais nous n'allons pas discuter. Les développeurs de Podman pensent qu'ils ont réussi à résoudre bon nombre de ces problèmes, et si vous souhaitez profiter de Podman, cet article est pour vous.
L'essence de Podman est d'interagir avec le registre d'images, avec les conteneurs et le stockage d'images, ainsi qu'avec le noyau Linux, non pas via un démon, mais directement via le processus runC, qui est responsable du lancement des conteneurs.
Maintenant que nous avons partiellement compris les motivations des développeurs Podman, il est temps de discuter de ce que la transition vers Podman signifie pour l'utilisateur. Et ici, nous devons comprendre et clarifier (nous le ferons ci-dessous) ce qui suit:
- Podman remplace Docker. En même temps, il n'est plus nécessaire de démarrer une sorte de processus démon, comme le démon Docker;
- Les commandes Docker familières fonctionnent de la même manière dans Podman;
- Podman ne stocke pas les conteneurs et les images au même endroit que Docker;
- Les images Podman et Docker sont compatibles;
- Dans les environnements Kubernetes, Podman est capable de plus que Docker;
- Et nous analyserons également ce qu'est Buildah et pourquoi il est nécessaire.
Installation de Podman
Si vous utilisez Docker, vous pouvez le supprimer lorsque vous décidez de faire un changement. Cependant, vous pouvez quitter Docker pendant que vous essayez Podman. Il y a quelques
leçons utiles et de grandes
démos qu'il pourrait être utile de lire et de voir pour commencer afin que vous puissiez mieux comprendre le processus de transition. Un exemple dans la démo nécessite Docker pour montrer la compatibilité.
Pour installer Podman sur
Red Hat Enterprise Linux 7.6 ou version ultérieure, utilisez ce qui suit; si vous utilisez Fedora, remplacez yum par dnf:
# yum -y install podman
Podman utilise les mêmes commandes que Docker
Podman a été conçu pour être facile à passer de Docker. Par conséquent, toutes les équipes que vous connaissez de Docker fonctionnent de la même manière dans Podman. De plus, il est soutenu que les scripts d'appel Docker devraient fonctionner correctement si vous créez l'alias approprié, comme ceci: alias docker = podman - essayez-le. Bien sûr, avant cela, vous devez arrêter Docker (systemctl stop docker). De plus, vous pouvez installer le package podman-docker, qui fera toutes les conversions nécessaires pour vous. Il place simplement un script dans / usr / bin / docker qui exécute Podman avec les mêmes arguments que Docker utilise.
Les commandes Docker habituelles, telles que pull, push, build, run, commit, tag, etc., sont toutes dans Podman. Consultez le manuel de Podman pour plus d'informations. Une différence importante est que dans Podman, certaines équipes ont ajouté des indicateurs de commodité, par exemple, les indicateurs --all (-a) pour les commandes podman rm et podman rmi, que beaucoup trouveront très utiles.
De plus, Podman peut être exécuté en tant qu'utilisateur normal, sans privilèges root. Certes, jusqu'à présent, cela ne fonctionne que dans Fedora et avec Podman 1.0, et dans RHEL devrait apparaître à partir des versions 7.7 et 8.1. Cela a été rendu possible grâce aux améliorations de la protection de l'espace utilisateur. Exécuter en tant qu'utilisateur normal signifie que par défaut Podman stocke des images et des conteneurs dans le répertoire personnel de l'utilisateur, nous en discuterons plus en détail dans la section suivante. Pour en savoir plus sur la façon d'exécuter Podman sans privilèges root, consultez l'article de Dan Walsh
Comment fonctionne Podman sans racine? .
Images Podman et conteneur
Lorsque vous entrez pour la première fois dans la commande podman images, vous serez très probablement découragé, car vous ne verrez aucune image Docker qui a déjà été téléchargée sur votre ordinateur auparavant. Le fait est que le référentiel Podman local se trouve dans le dossier / var / lib / containers et non dans le répertoire / var / lib / docker. Cela a été fait non seulement comme ça, mais dans le cadre d'une nouvelle structure de stockage qui répond aux normes OCI (Open Containers Initiative).
En 2015, Docker, Red Hat, CoreOS, SUSE, Google et d'autres créateurs de tendances de conteneurs Linux ont créé l'Open Container Initiative, un organisme indépendant pour gérer la spécification de normes pour le format des images de conteneurs et leur exécution. Dans le cadre de l'OCI, des projets conteneurs / image et conteneurs / stockage ont été créés sur GitHub.
Étant donné que Podman peut être exécuté sans privilèges root, il a besoin d'un emplacement séparé pour enregistrer les images. Par conséquent, le référentiel Podman se trouve dans le répertoire de base de l'utilisateur ~ / .local / share / containers. Cela permet d'éviter une situation où ils peuvent tout écrire dans / var / lib / containers, et par rapport à d'autres pratiques dangereuses du point de vue de la sécurité. De plus, chaque utilisateur dispose désormais de son propre ensemble de conteneurs, de sorte que plusieurs utilisateurs peuvent travailler simultanément sur l'hôte à la fois. Une fois le travail terminé, les utilisateurs peuvent envoyer par push au registre général pour mettre leurs images à la disposition des autres.
Lors du passage de Docker à Podman, la connaissance des nouveaux chemins d'emplacement de conteneur sera utile lors du débogage, ainsi que lorsque vous souhaitez effacer le référentiel local avec la commande rm -rf / var / lib / containers pour tout recommencer. Cependant, en passant à Podman, vous commencerez très probablement à utiliser la nouvelle option -all pour les commandes podman rm et podman rmi au lieu de cette commande.
Compatibilité des conteneurs entre Podman et d'autres runtimes
Malgré les différents emplacements des référentiels locaux, Docker et Podman créent des images de conteneur compatibles avec la norme OCI. Podman peut utiliser des registres de conteneurs populaires, tels que Quay.io ou Docker Hub, ainsi que des registres privés dans les deux sens (push et pull). Par exemple, avec Podman, vous pouvez télécharger et exécuter la dernière image Fedora à partir du Docker Hub. Si vous ne spécifiez pas de registre, Podman recherchera par défaut les registres répertoriés dans le fichier registries.conf, en suivant l'ordre spécifié dans ce fichier. Initialement, le premier de ce fichier est le registre Docker Hub.
$ podman pull fedora:latest $ podman run -it fedora bash
Les images qui ont été téléchargées dans le registre à l'aide de Docker peuvent être téléchargées et exécutées à l'aide de Podman. Par exemple, si nous avons créé une image myfedora à l'aide de Docker et l'avons téléchargée dans notre référentiel Quay.io (ipbabble), vous pouvez la télécharger à l'aide de Podman, voici comment:
$ podman pull quay.io/ipbabble/myfedora:latest $ podman run -it myfedora bash
Podman vous permet de déplacer facilement et avec élégance des images entre les répertoires / var / lib / docker et / var / lib / containers en utilisant les commandes push et pull, par exemple:
$ podman push myfedora docker-daemon:myfedora:latest
Il est clair que si vous omettez le démon docker dans cet exemple, l'envoi push ira au Docker Hub. Si vous spécifiez quay.io/myquayid/myfedora, l'image sera téléchargée dans le registre Quay.io (ici myquayid est le nom de notre compte sur Quay.io):
$ podman push myfedora quay.io/myquayid/myfedora:latest
Si vous décidez que vous êtes prêt à abandonner Docker, pour le désinstaller, fermez simplement le démon, puis supprimez le package Docker à l'aide du gestionnaire de packages. Mais avant cela, assurez-vous de télécharger toutes les images dont vous avez besoin à l'aide de Docker dans le registre externe (non local) afin de pouvoir les télécharger ultérieurement. Ou vous pouvez utiliser Podman pour les télécharger du référentiel Docker local vers le référentiel OCI Podman local. Par exemple, dans RHEL, le transfert d'une image fedora se fait comme ceci:
# systemctl stop docker # podman pull docker-daemon:fedora:latest # yum -y remove docker # optional
Podman facilite le passage à Kubernetes
Podman offre un certain nombre de fonctionnalités supplémentaires - par rapport à Docker - qui sont utiles aux développeurs et aux opérateurs informatiques lorsqu'ils travaillent avec Kubernetes, en particulier, des commandes utiles que Docker n'a tout simplement pas. Si vous connaissez Docker et envisagez de passer à Kubernetes / OpenShift en tant que plate-forme de conteneur, alors Podman vous sera utile.
Podman peut générer un fichier Kubernetes YAML basé sur un conteneur en cours d'exécution à l'aide de la commande podman generate kube. Et lors du débogage de pods en cours d'exécution, en plus des commandes standard pour travailler avec des conteneurs, vous pouvez également utiliser la commande podman pod. Pour plus d'informations sur la façon dont Podman aide à passer à Kubernetes, consultez l'article de Brent Baude Podman peut désormais faciliter la transition vers Kubernetes et CRI-O.
Buildah - qu'est-ce que c'est et pourquoi
Buildah est apparu plus tôt que Podman. Et cela décourage parfois les utilisateurs de Docker: «Pourquoi les apologistes de Podman parlent-ils soudainement de Buildah? Podman ne sait pas comment construire? "
Nous nous empressons de rassurer, Podman le peut et le fait comme Docker. Autrement dit, l'assemblage peut être effectué à l'aide du Dockerfile et de la commande de construction podman, ou vous pouvez démarrer le conteneur, apporter les modifications nécessaires, puis les valider (exécuter la validation), en créant une nouvelle balise dans l'image du conteneur. Dans notre interprétation, Buildah est un ensemble étendu de commandes pour créer et gérer des images de conteneur, et donc il offre un contrôle beaucoup plus fin lorsque vous travaillez avec des images. La commande de construction Podman contient partiellement la fonctionnalité Buildah et utilise le même code de programme pour la construction que Buildah lui-même.
La façon la plus efficace d'utiliser Buildah est d'écrire des scripts Bash pour créer des images, tout comme vous écrivez pour un Dockerfile.
Quant à la chronologie de l'apparition de Buildah et Podman, les événements se sont produits approximativement comme suit. Lorsque Kubernetes a appris à travailler avec CRI-O basé sur la norme OCI pour les temps d'exécution des conteneurs, le démon Docker n'était plus nécessaire. Autrement dit, il n'était plus nécessaire d'installer Docker sur tous les nœuds du cluster Kubernetes pour y exécuter des pods et des conteneurs. Kubernetes peut désormais appeler CRI-O, et que l'on peut exécuter RunC directement, qui, à son tour, démarre les processus de conteneur. Cependant, si en même temps nous voulons utiliser le même cluster Kubernetes non seulement pour le lancement, mais aussi pour l'assemblage de conteneurs (comme, par exemple, dans OpenShift), alors nous avons besoin d'un nouvel outil de construction qui ne dépendrait pas du démon Docker et , par conséquent, ne nécessiterait pas l'installation de Docker. En outre, un tel outil, créé sur la base des projets conteneurs / stockage et conteneurs / image, éliminerait les risques de sécurité associés au socket ouvert du démon Docker lors de l'assemblage, et de nombreux utilisateurs Docker sont préoccupés par ces risques.
Et Buildah est devenu un nouvel outil (le nom se lit «construire» et imite l'accent bostonien du chef de projet Dan Walsh tout en prononçant le mot «constructeur»). Vous trouverez plus d'informations sur Buildah sur buildah.io, ainsi que des blogs et des guides de liens à la fin de cet article.
Il y a quelques détails supplémentaires à savoir si vous souhaitez utiliser Buildah:
- Il offre un contrôle plus précis lors de la création de couches d'image. En particulier, il vous permet de faire ce que de nombreux utilisateurs de conteneurs souhaitent depuis longtemps: valider de nombreuses modifications à la fois avec une seule couche.
- La course de Buildah et celle de Podman sont deux choses différentes. Parce que Buildah est conçu pour créer des images, sa commande d'exécution est essentiellement la même que la commande RUN dans le Dockerfile. William Henry, l'un des développeurs de Buildah, se souvient de l'origine de cette solution: «Je me plaignais en quelque sorte qu'un port ou un montage ne fonctionnait pas du tout comme je m'y attendais. Dan Walsh (@rhatdan) a tout pesé et a déclaré que Buildah ne devrait pas du tout fonctionner avec des conteneurs de cette façon. Tous, plus de mappages de ports et aucun volume de montage. Nous supprimons ces indicateurs et utilisons buildah run à la place pour exécuter les commandes nécessaires à la création d'images de conteneur, par exemple, buildah run dnf -y install nginx. "
- Buildah peut créer des images à partir de zéro (images à gratter). Autrement dit, des images dans lesquelles il n'y a rien, littéralement. En effet, si vous regardez le stockage de conteneur créé à la suite de la commande buildah from scratch, il y aura un répertoire vide. Ceci est très utile du point de vue de la création d'images super légères contenant uniquement les packages nécessaires à l'exécution de l'application.
Pourquoi construire à partir de zéro? Comparons l'image de développement d'une application Java avec son image pour un environnement de production ou pour un environnement intermédiaire. Au stade du développement, l'image peut contenir le compilateur Java, Maven et d'autres outils dont le développeur a besoin. Mais lors de la traduction en production, seuls le runtime Java et vos packages doivent rester dans l'image. Et en passant, pour supprimer le superflu, vous n'avez pas du tout besoin d'un gestionnaire de packages, comme DNF / YUM, et vous n'avez même pas besoin de Bash - vous pouvez tout faire via l'interface CLI de Buildah, comme le montre la figure ci-dessous, où le conteneur multicouche traditionnel est à gauche et un conteneur à couche unique est à droite gratter l'image. Voir
Création d'une image de conteneur Buildah pour Kubernetes et
démonstration d'introduction Buildah pour plus de détails .
Revenons à la chronologie. Ainsi, Kubernetes a appris à travailler avec CRI-O et runC, et pour la version que nous avons empilée Buildah - tout, de Docker sur l'hôte Kubernetes, vous pouvez refuser? Non, le débogage reste. Comment résoudre les problèmes de conteneurs si l'hôte ne dispose pas des outils appropriés? Ne mettez pas Docker dessus, sinon nous retournons à nouveau au démon et tous les efforts ont été vains. Et puis Podman entre en scène.
Autrement dit, Podman résout deux problèmes à la fois. Tout d'abord, il permet aux opérateurs informatiques d'inspecter les conteneurs et les images à l'aide de commandes familières. Et deuxièmement, il donne ces mêmes outils aux développeurs. En conséquence, tous les utilisateurs de Docker - développeurs et opérateurs - peuvent passer à Podman et effectuer calmement les tâches pour lesquelles ils ont précédemment utilisé Docker, ainsi que résoudre toute une série de nouvelles tâches.
Ressources nécessaires:
- Site Web pour les projets Podman.io et Buildah.io.
- Projets sur github.com/containers (connectez-vous, étudiez la source et voyez ce qui est en cours de développement:
- libpod (Podman);
- buildah;
- image (code pour travailler avec des images OCI de conteneur);
- stockage (code pour le stockage local des images de conteneurs).
Liens utiles: