Podman vs. Docker : quel futur pour le monde des con­te­neurs ?

Le support officiel de Docker, l'outil populaire de gestion des con­te­neurs, ayant été abandonné dans Red Hat En­ter­prise Linux 8 (RHEL 8), les ad­mi­nis­tra­teurs doivent se préparer à une nouvelle option. Un autre produit de Red Hat se veut son suc­ces­seur direct : Podman. Son fonc­tion­ne­ment sans Daemon et sans pri­vi­lèges roots permet de répondre aux problèmes de sécurité de son pré­dé­ces­seur. Pour le reste, Docker comme Podman se res­semblent, même ce dernier fait toujours face à des bugs per­sis­tants.

Docker, l’une des solutions con­te­neurs les plus répandues, ne bénéficie plus d'un support officiel dans Red Hat En­ter­prise Linux 8. L’éditeur Red Hat fournit toutefois la solution au problème : Podman. L’en­vi­ron­ne­ment CRI-O est présenté par Red Hat comme une solution 100 % équi­va­lente, de sorte que les fans de Docker oublient leurs in­quié­tudes… Mais savoir si Podman rem­pla­cera Docker sans res­tric­tion est une autre histoire. Pour y répondre, prenons la peine d’examiner d’abord les deux tech­no­lo­gies de gestion de con­te­neurs en détail.

Depuis la sortie de Docker en 2013 en tant que logiciel open source, cette tech­no­lo­gie a été largement utilisée. Solution à la fois légère, pratique et fiable pour le dé­ve­lop­pe­ment d’ap­pli­ca­tions, Docker permet une approche plus libre pour les ad­mi­nis­tra­teurs. Grâce aux images des con­te­neurs, il est possible de trans­por­ter et d’installer fa­ci­le­ment les paquets sous forme de données. Une seule image Docker peut créer un nombre illimité de con­te­neurs, par exemple pour réaliser des Clouds OpenStack. Docker est to­ta­le­ment isolé, à l’exception de quelques in­ter­faces avec le système d’ex­ploi­ta­tion ou le matériel. Les con­te­neurs eux-mêmes ne con­tien­nent que les in­for­ma­tions réel­le­ment né­ces­saires, ce qui les rend assez peu vo­lu­mi­neux.

Pour remplacer Docker, c’est Podman que met en avant Red Hat Linux. Podman est conçu comme un ges­tion­naire de pods pour la création et le trai­te­ment ultérieur de con­te­neurs, en com­pa­ti­bi­lité avec la spé­ci­fi­ca­tion OCI des con­te­neurs. Con­trai­re­ment à Docker, Podman n’a pas besoin de pri­vi­lèges root, ce qui est censé le rendre plus sûr. Podman se base sur Docker et était ini­tia­le­ment prévu comme un outil de débogage avant de devenir une al­ter­na­tive, voire le suc­ces­seur des anciens outils de gestion. Pour faciliter la tran­si­tion, on peut utiliser des commandes de Docker dans Podman, ce qui ne suffit pas à faire de Podman un suc­ces­seur à la hauteur.

Voilà bien la question centrale. Avec la fin de la prise en charge de Docker, les uti­li­sa­teurs doivent se réo­rien­ter et trouver une al­ter­na­tive com­pa­rable. Alors que Red Hat Linux voit Podman comme un suc­ces­seur de même niveau, ce n’est pas l’avis de nombreux dé­ve­lop­peurs. Pour évaluer cor­rec­te­ment le duel Docker vs. Podman, regardons en détail les points forts et les fai­blesses du chal­len­ger.

Le plus gros avantage de Podman vs. Docker est l’absence de Daemon central et de pri­vi­lèges Root. Cela ne permet pas seulement un démarrage plus rapide – ce chan­ge­ment est aussi le bienvenu en matière de sécurité. Ainsi, le système hôte est protégé et les processus avec des pri­vi­lèges Root ne peuvent plus accéder au noyau. La com­pa­ti­bi­lité de Podman avec Docker est également un grand avantage pour ses uti­li­sa­teurs. Le chan­ge­ment devient donc re­la­ti­ve­ment simple à effectuer : ses dif­fé­rentes étapes restent largement in­tui­tives pour les ad­mi­nis­tra­teurs habitués à l’ancienne gestion.

De plus, Podman permet d’utiliser des registres de con­te­neurs po­pu­laires comme Docker Hub ou Quay.io. Il est aussi possible de créer des fichiers YAML pour Ku­ber­netes. Podman demande glo­ba­le­ment moins d’espace de stockage, reste ex­trê­me­ment rapide et re­la­ti­ve­ment efficace. C’est la raison pour laquelle Podman est devenu la solution par défaut de nom­breuses dis­tri­bu­tions Linux comme Fedora CoreOS.

Malgré toute la force de per­sua­sion de Red Hat pour Podman, le moteur de con­te­neurs n’est pas exempt de défauts. On y retrouve notamment quelques erreurs de débutants et bugs qui laissent de nombreux ad­mi­nis­tra­teurs perplexes quant au bien-fondé de Podman et cherchent d’autres al­ter­na­tives à Docker, voire lui préfèrent des solutions hybrides du type Kata Con­tai­ners.

Les erreurs de ma­ni­pu­la­tion des con­te­neurs sont plus fré­quentes. Sans Daemon sur le réseau, la création et la gestion des con­te­neurs via un hôte distant restent com­pli­quées. Même si Podman propose des ébauches de solutions, ces problèmes ne sont pas en­tiè­re­ment résolus. Même topo pour la com­pa­ti­bi­lité promise entre Podman et Docker : il ne comprend pas encore toutes les requêtes.

Pour savoir qui triom­phera dans le duel Docker vs. Podman entre le quasi-standard pla­né­taire au succès non démenti depuis des années et le chal­len­ger, une com­pa­rai­son directe des deux moteurs est décisive. Quelles sont donc les dif­fé­rences entre les deux systèmes de gestion ?

Con­trai­re­ment à Docker, Podman renonce à un Daemon central pour le dé­ve­lop­pe­ment, la gestion et l’exécution des con­te­neurs OCI. Au lieu de cela, Podman se base sur le concept des pods Ku­ber­netes. Dans ce cas, plusieurs con­te­neurs se re­grou­pent au sein d’un espace de noms Linux commun et donne la pos­si­bi­lité de créer des con­fi­gu­ra­tions et des com­bi­nai­sons flexibles. Docker n’offre pas cette pos­si­bi­lité sans une con­fi­gu­ra­tion sup­plé­men­taire via docker-compose.

Cet angle met en lumière l’une des prin­ci­pales critiques faites à Docker : son Daemon demande en effet toujours un privilège Root, ce qui crée un risque de sécurité potentiel. Les con­te­neurs ont ainsi la pos­si­bi­lité de s’échapper via Docker et d’agir également sur l’hôte. Dans certaines cir­cons­tances, cela peut entraîner des dommages im­por­tants sur le noyau, par exemple si un conteneur mal configuré accède à un hôte. Podman résout ce problème en per­met­tant aux con­te­neurs de démarrer sans pri­vi­lèges Root. Une bonne chose du point de vue de la sécurité, qui implique en con­tre­par­tie iné­vi­ta­ble­ment que les ad­mi­nis­tra­teurs ne puissent pas exécuter de commande qui nécessite des droits d’accès Root sur l’hôte.

Dans le duel Ku­ber­netes vs. Docker, les dif­fé­rences sont nom­breuses entre les deux poids lourds. Mais pour ce qui touche à la gestion de con­te­neurs, les deux outils tra­vail­lent bien ensemble. Cela va pro­ba­ble­ment changer avec Ku­ber­netes 1.24, car Ku­ber­netes cessera de supporter Docker. La col­la­bo­ra­tion avec Podman devrait toutefois rester possible sans problème. Le nom du nouveau système indique déjà que Podman (et non Docker) supporte en plus les Pods établis par Ku­ber­netes.

Con­trai­re­ment à Docker, Podman fonc­tionne selon le modèle Fork-Exec et en­re­gistre les mo­di­fi­ca­tions dans le système auditd. Docker fonc­tionne dif­fé­rem­ment, sans en­re­gis­tre­ment.

Cette dif­fé­rence va cer­tai­ne­ment s’amenuiser avec le temps. À l’heure actuelle, la do­cu­men­ta­tion sur Docker dépasse de loin celle sur Podman. Depuis 2013 déjà, Docker est devenu plus ou moins le système standard avec une immense com­mu­nauté qui vient en aide aux ad­mi­nis­tra­teurs quand sur­gis­sent des problèmes. Son suc­ces­seur, de cinq ans plus jeune, ne peut pas encore rivaliser. À l’avenir, les do­cu­men­ta­tions des deux outils seront toutefois égales.

Les in­ter­faces de Docker et Podman sont certes dif­fé­rentes, mais cela n’est pas très important au quotidien. Ceux qui con­nais­sent Docker s’y re­trou­ve­ront très pro­ba­ble­ment aussi avec Podman, d’autant plus que de nom­breuses commandes connues peuvent être reprises fa­ci­le­ment.

C’est pré­ci­sé­ment ce qui rend le chan­ge­ment de Docker vers Podman assez facile. Non seulement les commandes du type « pull », « push », « build », « run », « commit » et d’autres encore restent en grande partie iden­tiques, mais les images de Docker sont en plus com­pa­tibles avec Podman. C’était un des objectifs annoncé par les dé­ve­lop­peurs. Avant de faire le chan­ge­ment, assurez-vous surtout que Docker soit arrêté. Ensuite, installez Podman ou utilisez le logiciel préins­tallé dans certaines versions de Linux. Vous devez ensuite renommer « Do­cker­file » et docker-compose.yml en « Con­tai­ner­file » et container-compose.yml. Autre point important : Podman en­re­gistre ses con­te­neurs et ses images à un autre endroit que son pré­dé­ces­seur.

Podman vs. Docker est un combat inégal, car l’outil le plus ancien a beau posséder une avance certaine, mais il n’est plus soutenu par Red Hat. Il y a de bonnes raisons à cela : il faut notamment regarder du côté des failles de sécurité. Dans ce domaine, Docker a longtemps eu besoin d’aide et Podman comble justement ces lacunes. L’absence de Daemon central et la pro­tec­tion améliorée qui en résulte pour­raient finir par con­vaincre même les ad­mi­nis­tra­teurs les plus réticents. Podman n’est cependant pas sans défaut et quelques petits problèmes doivent toujours être résolus. S’il y parvient, Podman l’emportera sur Docker, mais ce sera de justesse.

Même les derniers fidèles uti­li­sa­teurs con­vain­cus de Docker devront tôt ou tard changer de système et se réo­rien­ter par exemple vers une al­ter­na­tive Ku­ber­netes avec laquelle Docker peut encore être utilisé. Mais en raison de la grande si­mi­li­tude des deux moteurs de con­te­neurs et de la volonté de Red Hat Linux d’établir Podman en tant que suc­ces­seur, il y a de fortes chances que ce chan­ge­ment fonc­tionne cor­rec­te­ment.