Podman vs. Docker : quel futur pour le monde des conteneurs ?

Le support officiel de Docker, l'outil populaire de gestion des conteneurs, ayant été abandonné dans Red Hat Enterprise Linux 8 (RHEL 8), les administrateurs doivent se préparer à une nouvelle option. Un autre produit de Red Hat se veut son successeur direct : Podman. Son fonctionnement sans Daemon et sans privilèges roots permet de répondre aux problèmes de sécurité de son prédécesseur. Pour le reste, Docker comme Podman se ressemblent, même ce dernier fait toujours face à des bugs persistants.

Docker, l’une des solutions conteneurs les plus répandues, ne bénéficie plus d'un support officiel dans Red Hat Enterprise Linux 8. L’éditeur Red Hat fournit toutefois la solution au problème : Podman. L’environnement CRI-O est présenté par Red Hat comme une solution 100 % équivalente, de sorte que les fans de Docker oublient leurs inquiétudes… Mais savoir si Podman remplacera Docker sans restriction est une autre histoire. Pour y répondre, prenons la peine d’examiner d’abord les deux technologies de gestion de conteneurs en détail.

Depuis la sortie de Docker en 2013 en tant que logiciel open source, cette technologie a été largement utilisée. Solution à la fois légère, pratique et fiable pour le développement d’applications, Docker permet une approche plus libre pour les administrateurs. Grâce aux images des conteneurs, il est possible de transporter et d’installer facilement les paquets sous forme de données. Une seule image Docker peut créer un nombre illimité de conteneurs, par exemple pour réaliser des Clouds OpenStack. Docker est totalement isolé, à l’exception de quelques interfaces avec le système d’exploitation ou le matériel. Les conteneurs eux-mêmes ne contiennent que les informations réellement nécessaires, ce qui les rend assez peu volumineux.

Pour remplacer Docker, c’est Podman que met en avant Red Hat Linux. Podman est conçu comme un gestionnaire de pods pour la création et le traitement ultérieur de conteneurs, en compatibilité avec la spécification OCI des conteneurs. Contrairement à Docker, Podman n’a pas besoin de privilèges root, ce qui est censé le rendre plus sûr. Podman se base sur Docker et était initialement prévu comme un outil de débogage avant de devenir une alternative, voire le successeur des anciens outils de gestion. Pour faciliter la transition, on peut utiliser des commandes de Docker dans Podman, ce qui ne suffit pas à faire de Podman un successeur à la hauteur.

Voilà bien la question centrale. Avec la fin de la prise en charge de Docker, les utilisateurs doivent se réorienter et trouver une alternative comparable. Alors que Red Hat Linux voit Podman comme un successeur de même niveau, ce n’est pas l’avis de nombreux développeurs. Pour évaluer correctement le duel Docker vs. Podman, regardons en détail les points forts et les faiblesses du challenger.

Le plus gros avantage de Podman vs. Docker est l’absence de Daemon central et de privilèges Root. Cela ne permet pas seulement un démarrage plus rapide – ce changement est aussi le bienvenu en matière de sécurité. Ainsi, le système hôte est protégé et les processus avec des privilèges Root ne peuvent plus accéder au noyau. La compatibilité de Podman avec Docker est également un grand avantage pour ses utilisateurs. Le changement devient donc relativement simple à effectuer : ses différentes étapes restent largement intuitives pour les administrateurs habitués à l’ancienne gestion.

De plus, Podman permet d’utiliser des registres de conteneurs populaires comme Docker Hub ou Quay.io. Il est aussi possible de créer des fichiers YAML pour Kubernetes. Podman demande globalement moins d’espace de stockage, reste extrêmement rapide et relativement efficace. C’est la raison pour laquelle Podman est devenu la solution par défaut de nombreuses distributions Linux comme Fedora CoreOS.

Malgré toute la force de persuasion de Red Hat pour Podman, le moteur de conteneurs n’est pas exempt de défauts. On y retrouve notamment quelques erreurs de débutants et bugs qui laissent de nombreux administrateurs perplexes quant au bien-fondé de Podman et cherchent d’autres alternatives à Docker, voire lui préfèrent des solutions hybrides du type Kata Containers.

Les erreurs de manipulation des conteneurs sont plus fréquentes. Sans Daemon sur le réseau, la création et la gestion des conteneurs via un hôte distant restent compliquées. Même si Podman propose des ébauches de solutions, ces problèmes ne sont pas entièrement résolus. Même topo pour la compatibilité promise entre Podman et Docker : il ne comprend pas encore toutes les requêtes.

Pour savoir qui triomphera dans le duel Docker vs. Podman entre le quasi-standard planétaire au succès non démenti depuis des années et le challenger, une comparaison directe des deux moteurs est décisive. Quelles sont donc les différences entre les deux systèmes de gestion ?

Contrairement à Docker, Podman renonce à un Daemon central pour le développement, la gestion et l’exécution des conteneurs OCI. Au lieu de cela, Podman se base sur le concept des pods Kubernetes. Dans ce cas, plusieurs conteneurs se regroupent au sein d’un espace de noms Linux commun et donne la possibilité de créer des configurations et des combinaisons flexibles. Docker n’offre pas cette possibilité sans une configuration supplémentaire via docker-compose.

Cet angle met en lumière l’une des principales critiques faites à Docker : son Daemon demande en effet toujours un privilège Root, ce qui crée un risque de sécurité potentiel. Les conteneurs ont ainsi la possibilité de s’échapper via Docker et d’agir également sur l’hôte. Dans certaines circonstances, cela peut entraîner des dommages importants sur le noyau, par exemple si un conteneur mal configuré accède à un hôte. Podman résout ce problème en permettant aux conteneurs de démarrer sans privilèges Root. Une bonne chose du point de vue de la sécurité, qui implique en contrepartie inévitablement que les administrateurs ne puissent pas exécuter de commande qui nécessite des droits d’accès Root sur l’hôte.

Dans le duel Kubernetes vs. Docker, les différences sont nombreuses entre les deux poids lourds. Mais pour ce qui touche à la gestion de conteneurs, les deux outils travaillent bien ensemble. Cela va probablement changer avec Kubernetes 1.24, car Kubernetes cessera de supporter Docker. La collaboration 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 Kubernetes.

Contrairement à Docker, Podman fonctionne selon le modèle Fork-Exec et enregistre les modifications dans le système auditd. Docker fonctionne différemment, sans enregistrement.

Cette différence va certainement s’amenuiser avec le temps. À l’heure actuelle, la documentation 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 communauté qui vient en aide aux administrateurs quand surgissent des problèmes. Son successeur, de cinq ans plus jeune, ne peut pas encore rivaliser. À l’avenir, les documentations des deux outils seront toutefois égales.

Les interfaces de Docker et Podman sont certes différentes, mais cela n’est pas très important au quotidien. Ceux qui connaissent Docker s’y retrouveront très probablement aussi avec Podman, d’autant plus que de nombreuses commandes connues peuvent être reprises facilement.

C’est précisément ce qui rend le changement 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 identiques, mais les images de Docker sont en plus compatibles avec Podman. C’était un des objectifs annoncé par les développeurs. Avant de faire le changement, assurez-vous surtout que Docker soit arrêté. Ensuite, installez Podman ou utilisez le logiciel préinstallé dans certaines versions de Linux. Vous devez ensuite renommer « Dockerfile » et docker-compose.yml en « Containerfile » et container-compose.yml. Autre point important : Podman enregistre ses conteneurs et ses images à un autre endroit que son prédécesseur.

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 protection améliorée qui en résulte pourraient finir par convaincre même les administrateurs 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 utilisateurs convaincus de Docker devront tôt ou tard changer de système et se réorienter par exemple vers une alternative Kubernetes avec laquelle Docker peut encore être utilisé. Mais en raison de la grande similitude des deux moteurs de conteneurs et de la volonté de Red Hat Linux d’établir Podman en tant que successeur, il y a de fortes chances que ce changement fonctionne correctement.