Podman est un moteur de conteneurs - un outil pour développer, gérer et exécuter des conteneurs et des images de conteneurs. Ces derniers sont des paquets logiciels standardisés et autonomes qui contiennent tous les éléments nécessaires pour fonctionner n’importe où sans besoin de personnalisation, intégrant le code d’application et les librairies de support. Les applications basées sur les conteneurs ont révolutionné le développement logiciel au cours de la dernière décennie, en rendant les systèmes distribués et basés sur le cloud faciles à déployer et à maintenir. Podman est un projet open source de Red Hat disponible en téléchargement. Il est relativement nouveau sur la scène de la conteneurisation, la version 1.0 ayant été publiée en 2019. Podman a depuis fait de grands progrès, et son ascension a été accélérée par le déclin progressif de Docker, le projet qui, à bien des égards, a mis en orbite l’environnement des conteneurs – créés à l’origine par Oracle - tel que nous le connaissons aujourd’hui.

Podman et Kubernetes

Si vous êtes un tant soit peu familier avec le développement basé sur les conteneurs, vous connaissez le nom de Kubernetes. Les applications conteneurisées devenant de plus en plus complexes, les développeurs avaient besoin d’outils capables de coordonner des conteneurs qui interagissaient les uns avec les autres tout en s’exécutant sur différentes machines virtuelles, voire sur différentes machines physiques. Un tel outil s’appelle une plate-forme d’orchestration de conteneurs, et Kubernetes en est de loin l’exemple le plus marquant. Elle peut fonctionner avec tout conteneur répondant à la spécification d’image de l’Open Container Initiative (OCI), ce qui est le cas des conteneurs de Podman.

L’une des caractéristiques importantes de Kubernetes est le concept de pod, un regroupement éphémère d’un ou plusieurs conteneurs qui est la plus petite unité de calcul que la plateforme peut gérer. Podman est également centré sur l’idée d’un pod, comme son nom l’indique. Un pod Podman comprend également un ou plusieurs conteneurs, qui sont regroupés dans un espace de noms, un réseau et un contexte de sécurité uniques. Cette similitude fait que Podman et Kubernetes s’accordent naturellement, et dès le début, l’un des objectifs de Red Hat était de permettre aux utilisateurs de Podman d’orchestrer des conteneurs avec Kubernetes.

Podman vs. Docker

L’autre grand nom du monde des conteneurs est bien entendu Docker. Ce dernier n’a pas été le premier moteur de conteneurs mais, à bien des égards, il a défini la conteneurisation. Une grande partie du fonctionnement de Docker est la norme de facto pour le développement basé sur les conteneurs, à tel point que de nombreuses personnes utilisent à tort Docker comme raccourci pour les conteneurs. Si Docker et Podman occupent un espace similaire dans l’écosystème des conteneurs, ils ne sont pas identiques et 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 collabore avec d’autres projets à certaines fins - par exemple, il s’appuie sur Buildah pour construire des images de conteneurs.

Il existe également des différences architecturales : Docker n’a pas de concept natif de pods, par exemple. Une autre différence importante est que Docker s’appuie sur un programme démon tournant en permanence en arrière-plan pour créer des images et exécuter des conteneurs, alors que Podman lance les conteneurs et les pods en tant que processus mineurs distincts. Cet aspect de la conception de Docker a des implications importantes pour la sécurité, que nous aborderons prochainement.

Une introduction à Podman par Doug Tidwell, développeur chez Red Hat. 

Commandes Docker sur Podman

Par conception et par nécessité, Podman et Docker sont globalement compatibles. Une partie de cette compatibilité peut être attribuée à l’adhésion à des normes ouvertes. Comme les deux moteurs fonctionnent avec des conteneurs conformes à la norme OCI, vous pouvez créer un conteneur avec Docker et le modifier dans Podman, ou vice versa, puis déployer l’un ou l’autre conteneur sur Kubernetes.

Lorsque Podman a été lancé en 2019, Docker était tellement dominant que son interface en ligne de commande faisait partie des routines de programmation et de la mémoire morte de nombreux développeurs. Afin de rendre une migration potentielle vers Podman plus transparente, les créateurs de la solution 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 redirige les commandes de Docker vers Podman

Une meilleure sécurité avec les conteneurs rootless

Podman et Docker fonctionnant de manière si similaire à bien des égards, pourquoi choisir l’un plutôt que l’autre ? Eh bien, une raison importante est la sécurité. Vous vous souvenez que Docker s’appuie sur un démon pour effectuer la plupart de ses tâches courantes ? Ce démon fonctionne en tant que root, ce qui en fait un point d’entrée potentiel pour les attaquants. Il ne s’agit pas d’un obstacle insurmontable à la sécurité informatique, mais cela signifie que vous devez réfléchir à la manière de gérer les problèmes de sécurité de Docker

Après l'éléphant ou le pingouin, le monde animal est de nouveau utilisé dans l'open source pour symboliser une plateforme logiciel. (Crédit Red Hat)

Dans certaines situations, vous voudrez exécuter un conteneur avec des privilèges d’administrateur sur sa machine hôte, et Podman vous permet de le faire. Mais si vous préférez que vos conteneurs soient limités à l’espace utilisateur, vous pouvez également le faire en exécutant ce que l’on appelle un conteneur sans statut admin (rootless). Ce dernier n’a pas plus de privilèges que l’utilisateur qui l’a lancé ; à l’intérieur du conteneur, cet utilisateur a les privilèges adminisrateurs. Vous pouvez également utiliser des drapeaux de ligne de commande pour ajouter des privilèges à vos conteneurs de manière granulaire.

Qu’en est-il des performances ?

Les performances sont un domaine dans lequel Docker a une longueur d’avance sur Podman, du moins selon certains. Bien qu’il existe peu d’informations concrètes à ce sujet, il n’est pas difficile de trouver des développeurs frustrés sur Hacker News, Stack Overflow et Reddit se plaignant des performances de Podman, en particulier lorsqu’il fonctionne sans racine. Des étudiants d’une université suédoise ont réalisé une série de tests sur plusieurs plates-formes de conteneurs différentes et ont constaté que Podman n’était pas à la hauteur, même s’il s’agissait d’une ancienne version pré-1.0 de Podman. Bien qu’il n’y ait pas beaucoup d’informations techniques sur ce sujet, Podman est critiqué pour ses performances. 

Podman remplacera-t-il Docker ?

D’après la discussion qui a eu lieu jusqu’à présent, il ne semble pas qu’un grand changement soit en préparation pour remplacer Docker par Podman. Mais un changement majeur est en train de se produire, qui délogera Docker de l’un de ses créneaux de toujours : Kubernetes lui-même.

Depuis plusieurs années, Kubernetes et Docker sont les deux géants du monde des conteneurs. Mais leur coexistence a toujours été quelque peu difficile. L’essor de Kubernetes est intervenu alors que Docker était bien établi dans son créneau - en fait, on pourrait dire que Kubernetes est devenu populaire en partie parce que Docker n’était pas en mesure de gérer tous les conteneurs qui devaient être coordonnés dans une grande application distribuée. En 2015, Docker (la société) a développé sa propre plate-forme d’orchestration de conteneurs, baptisée Swarm, qui était conçue pour jouer sur les forces de Docker. Swarm a été lancé en grande pompe, mais n’a jamais vraiment rattrapé Kubernetes. Si Swarm a encore des fidèles, Kubernetes est devenu la norme de facto pour l’orchestration des clusters de  conteneurs, tout comme Docker l’est devenu pour d’autres aspects de l’écosystème des conteneurs. Précisons que Docker n’a jamais vraiment fait bon ménage avec Kubernetes en ce qui concerne son moteur d’exécution de conteneurs, le composant de bas niveau du moteur de conteneurs qui, entre autres tâches, travaille avec le noyau du système d’exploitation (OS) sous-jacent et monte les images de conteneurs individuelles. Docker et Kubernetes sont tous deux conformes à la spécification d’image OCI, que Kubernetes utilise pour coordonner les images construites pour les conteneurs. Mais Kubernetes s’appuie également sur des moteurs d’exécution de conteneurs compatibles avec une API de plug-in normalisée appelée Container Runtime Interface (CRI), que Docker n’a jamais réussi à mettre en œuvre.

Pendant longtemps, la popularité de Docker a obligé Kubernetes à utiliser Dockershim de Rancher, une couche conforme à la CRI qui servait d’intermédiaire entre Kubernetes et le démon Docker. Cependant, cela a toujours été une sorte de piratage et, au début de cette année, Kubernetes a abandonné la prise en charge de Dockershim. (Podman, en revanche, utilise le runtime compatible CRI-O de la Cloud Native Computing Foundation). Cette situation s’inscrit dans le cadre d’une histoire plus large concernant les tentatives et les échecs de Docker pour devenir une entreprise. En bref, Docker n’a jamais pu se détacher complètement de Kubernetes. Kubernetes, quant à lui, n’a plus autant besoin de Docker qu’auparavant.

On ne sait pas encore si Podman remplacera Docker, mais il sera certainement l’un des prétendants. Le fait que Podman ne soit pas un produit phare cherchant à être monétisé, mais plutôt une offre unique de technologie open source émanant d’une entreprise beaucoup plus importante, est un atout. On peut s’attendre à ce que Podman et Kubernetes restent imbriqués pendant un certain temps encore. 

Quel moteur de conteneurs utiliser ?

Nous espérons que cette discussion vous donne une idée des facteurs qui vous aideront à choisir entre ces deux moteurs de conteneurs. Si Podman est basé sur une architecture plus sécurisée, Docker est encore bien implanté sur le marché. Toutefois Podman est natif de Kubernetes, alors que Docker fonctionne naturellement avec  Swarm. Docker comprend toutes les fonctionnalités dont les développeurs ont besoin pour de nombreuses tâches liées aux conteneurs. Podman est toutefois plus modulaire et permet d’expérimenter différents outils à des fins différentes.

Cela dit, la question "Podman vs. Docker" est en quelque sorte un faux débat. Les deux plates-formes créent des images conformes à la spécification OCI et sont toutes deux pilotées par les mêmes commandes, de sorte qu’il est possible de passer de l’une à l’autre sans problème. Il est, par exemple, possible d’utiliser Docker pour le développement en local, puis d’exploiter Podman pour déployer les conteneurs créés dans Kubernetes. L’une des caractéristiques qui distingue Docker est qu’il est fourni avec un support payant. Mais même cela a un revers de la médaille : alors que Docker (la société) tente de monétiser son offre phare, elle a commencé à faire payer l’environnement de développement Docker Desktop. Red Hat, quant à lui, semble se contenter de laisser Podman gratuit pour le moment.