Podman est un moteur de conteneurs : un outil permettant d’établir, de gérer et d’exécuter des conteneurs et des images de conteneurs. Les conteneurs sont des ensembles d’applications logicielles standardisées et autonomes qui contiennent tous les aspects nécessaires pour s’exécuter n’importe où sans nécessiter de personnalisation, y compris le code d’application et les bibliothèques de prise en charge. Les applications basées sur des conteneurs ont réinventé le développement d’applications logicielles au cours des années précédentes, rendant les systèmes dispersés et basés sur le cloud faciles à déployer et à entretenir.
Podman est un projet de Red Hat qui est open source et téléchargeable gratuitement. C’est un nouveau venu sur la scène de la conteneurisation, avec la version 1.0 lancée en 2019. Podman a en fait fait de grands progrès, et sa montée a été aggravée par le déclin progressif de Docker, le projet qui à bien des égards a produit le monde de conteneurs tels que nous les comprenons aujourd’hui.
Podman et Kubernetes
Si vous êtes ne serait-ce qu’un peu informé sur l’avancement basé sur les conteneurs, vous comprendrez le nom Kubernetes. Au fur et à mesure que les applications conteneurisées devenaient plus compliquées, les développeurs avaient besoin d’outils capables de collaborer avec des conteneurs qui communiquaient entre eux tout en travaillant sur divers fabricants virtuels, ou même sur divers appareils physiques. Un tel outil s’appelle une plate-forme d’orchestration de conteneurs, et Kubernetes en est de loin l’exemple le plus frappant. Kubernetes peut gérer n’importe quel conteneur qui répond à la spécification d’image Open Container Effort (OCI), ce que font les conteneurs de Podman.
L’une des caractéristiques importantes de Kubernetes est l’idée d’un pod , un regroupement éphémère de plusieurs conteneurs qui est le plus petit système de calcul que Kubernetes puisse gérer. Podman est également attaché au concept de pod, comme son nom l’indique. Un pod Podman se compose également d’un ou plusieurs conteneurs, qui sont organisés ensemble dans un espace de noms, un réseau et un contexte de sécurité uniques. Cette similitude fait de Podman et Kubernetes un complément naturel, et dès le début, l’un des objectifs de Red Hat était de faire en sorte que les utilisateurs de Podman orchestrent les conteneurs avec Kubernetes.
Podman contre Docker
L’autre grand nom du monde des conteneurs que vous avez probablement entendu est Docker. Docker n’était pas le tout premier moteur de conteneurs, mais à bien des égards, il s’agissait en fait de définir la conteneurisation. Une grande partie du fonctionnement de Docker est l’exigence de facto pour l’avancement basé sur les conteneurs – suffisamment pour que de nombreuses personnes utilisent » Docker » comme raccourci pour les conteneurs.
Alors que Docker et Podman occupent une zone comparable dans l’environnement des conteneurs, ils ne sont pas exactement les mêmes et ils ont des philosophies et des approches différentes quant à leur fonctionnement. Par exemple, Docker est une plate-forme tout-en-un avec des outils pour des tâches spécifiques, tandis que Podman s’associe à d’autres projets à certaines fins. Par exemple, il s’appuie sur Buildah pour construire des images de conteneurs.
Là Il y a aussi des différences architecturales : Docker n’a pas de principe natif de pods. Une autre distinction importante est que Docker s’appuie sur un programme démon en arrière-plan en cours d’exécution pour développer des images et exécuter des conteneurs, tandis que Podman lance des conteneurs et des pods en tant que processus enfants différents. Cet aspect du style de Docker a des ramifications essentielles pour la sécurité, dont nous parlerons bientôt.
Commandes Docker sur Podman
Par conception et nécessité, Podman et Docker conviennent parfaitement. Une partie de cette compatibilité peut être attribuée au respect des exigences ouvertes. Étant donné que les deux moteurs fonctionnent avec des conteneurs conformes à la norme OCI, vous pouvez produire un conteneur avec Docker et le modifier dans Podman, ou vice versa, puis déployer l’un ou l’autre des conteneurs sur Kubernetes.
Lorsque Podman déployé en 2019, Docker était si dominant que son interface utilisateur en ligne de commande était en fait devenue une partie des routines de programmation et de la mémoire musculaire de nombreux développeurs. Afin de faciliter une relocalisation potentielle vers Podman, les créateurs de Podman se sont assurés que ses commandes et sa syntaxe reflétaient autant que possible celles de Docker. Ils sont allés jusqu’à rendre possible la définition d’un alias qui réachemine les commandes Docker vers Podman.
Meilleure sécurité avec des conteneurs sans racine
Avec Podman et Docker fonctionnant de manière similaire dans de nombreuses méthodes , pourquoi choisiriez-vous l’un plutôt que l’autre ? Eh bien, une raison essentielle est la sécurité. Gardez à l’esprit que Docker dépend d’un démon pour effectuer une grande partie de son travail continu ? Ce démon s’exécute en tant que root, ce qui en fait un point d’entrée potentiel pour les agresseurs. Ce n’est pas un défi écrasant pour protéger l’informatique, mais cela signifie que vous devez réfléchir à la navigation dans les problèmes de sécurité de Docker.
Dans certains scénarios, vous souhaiterez exécuter un conteneur avec des avantages root sur son fabricant d’hôtes, et Podman vous permet de le faire. Cependant, si vous préférez garder vos conteneurs en toute sécurité limités à l’espace utilisateur, vous pouvez également le faire en exécutant ce qu’on appelle un conteneur sans racine. Un conteneur sans racine n’a pas plus de privilèges que l’utilisateur qui l’a introduit ; dans le conteneur, cet utilisateur dispose d’opportunités root. Vous pouvez également utiliser des indicateurs de ligne de commande pour inclure les avantages de vos conteneurs de manière granulaire.
Qu’en est-il de l’efficacité ?
Un domaine dans lequel Docker a le dessus sur Podman est la performance, un minimum selon certains. Bien qu’il y ait peu de détails concrets sur ce sujet, il n’est pas difficile de trouver des développeurs agacés sur Hacker News, Stack Overflow et Reddit qui se plaignent de l’efficacité de Podman, en particulier lorsqu’il fonctionne sans racine. Certains étudiants universitaires suédois ont exécuté une suite de référence sur plusieurs plates-formes de conteneurs et ont constaté que Podman manquait, bien qu’il s’agisse certes d’une ancienne variante pré-1.0 de Podman. Bien qu’il n’y ait pas beaucoup de détails techniques sur ce sujet, Podman est anecdotique pour son efficacité.
Podman changera-t-il Docker ?
De la discussion jusqu’à présent, il peut ne pas sembler comme tout changement d’ambiance fantastique reste en cours pour remplacer Docker par Podman. Une modification importante est à venir qui déplacera Docker de l’un de ses créneaux spécifiques de longue date : Kubernetes lui-même.
Kubernetes et Docker sont depuis des années les géants jumeaux du monde des conteneurs. Cependant leur coexistence a toujours été assez anxiogène. L’augmentation de Kubernetes a suivi Docker était bien établi dans son créneau spécifique – en effet, on pourrait dire que Kubernetes est devenu populaire en partie parce que Docker n’était pas approximativement la tâche de gérer tous les conteneurs qui devaient être coordonnés dans une grande application dispersée .
Docker (l’entreprise) a créé sa propre plate-forme d’orchestration de conteneurs en 2015, baptisée Swarm, qui a été créée pour tirer parti des atouts de Docker. Swarm a été lancé en grande pompe, mais n’a jamais vraiment rattrapé Kubernetes. Alors que Swarm a toujours des passionnés, Kubernetes est en fait devenu la norme de facto pour l’orchestration des conteneurs, tout comme Docker a fini par être la norme de facto pour d’autres aspects du conteneur. communauté.
De plus, Docker n’a jamais plutôt bien joué avec Kubernetes en ce qui concerne son environnement d’exécution de conteneur, la partie de bas niveau du moteur de conteneur qui, pour n’en nommer que quelques tâches, traite le noyau du système d’exploitation (OS) sous-jacent et installe des images de conteneur individuelles. Docker et Kubernetes sont tous deux conformes à la spécification d’image OCI, que Kubernetes utilise pour coordonner les images construites sur des conteneurs. Kubernetes s’appuie également sur des environnements d’exécution de conteneurs adaptés à une API de plug-in standardisée appelée Container Runtime Interface (CRI), que Docker n’a jamais eu le temps de réaliser.
Pendant longtemps, l’appel de Docker a forcé Kubernetes à utiliser Dockershim, une couche conforme au CRI qui servait d’intermédiaire entre Kubernetes et le démon Docker. C’était toujours une sorte de piratage, cependant, et plus tôt cette année, Kubernetes a rejeté l’assistance à Dockershim. (Podman, en revanche, utilise le runtime CRI-O compatible de la structure informatique native du cloud.)
Cela fait partie d’une histoire plus vaste sur Docker qui tente et arrête de travailler pour devenir une entreprise. En termes simples, Docker n’a jamais été totalement capable de rompre avec Kubernetes. Kubernetes, d’autre part, n’a plus besoin de Docker au niveau qu’il avait autrefois.
On ne sait pas si Podman remplacera Docker, mais ce sera certainement l’un des prétendants. Cela aide que Podman ne soit pas un produit phare semblant générer des revenus, mais plutôt une seule offre de technologie open source d’une entreprise beaucoup plus grande. Nous pouvons nous attendre à ce que Podman et Kubernetes restent liés pendant longtemps.
Quel moteur de conteneur devriez-vous utiliser ?
Idéalement, cette discussion vous donne une idée des éléments pour vous aider vous choisissez entre ces 2 moteurs de conteneurs. Podman est basé sur une architecture plus sécurisée, tandis que Docker a une histoire beaucoup plus profonde. Podman est natif de Kubernetes, tandis que Docker fonctionne également avec Docker Swarm. Docker comprend toutes les fonctionnalités dont vous avez besoin pour de nombreuses tâches liées aux conteneurs. Podman est modulaire et vous permet d’expérimenter différents outils à des fins différentes.
Cela dit, la préoccupation « Podman contre Docker » est à un certain niveau une option incorrecte. Les deux plates-formes produisent des images conformes à la spécification OCI, et les deux sont pilotées par un grand nombre des mêmes commandes, de sorte que vous pouvez vous déplacer sans effort entre les deux. Vous pouvez, par exemple, souhaiter utiliser Docker pour l’avancement régional, puis utiliser Podman pour libérer les conteneurs que vous avez construits dans Kubernetes.
Une fonction qui distingue Docker est qu’il est fourni avec un support payant. Même cela a un revers : alors que Docker (l’entreprise) essaie de monétiser son offre phare, elle a commencé à facturer l’environnement de développement Docker Desktop. Red Hat, en revanche, semble satisfait de laisser Podman libre (comme dans la bière) pour le moment.
Jacqueline Primavera est rédactrice technique et rédactrice à Los Angeles.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
