Si l’univers de la virtualisation et de la conteneurisation vous est familier, vous avez probablement croisé Podman et Docker. Une interrogation légitime se pose alors : quelles sont leurs différences fondamentales ?
Cet article a pour objectif de décortiquer les divergences entre Docker et Podman, afin de vous aider à déterminer la solution la plus adaptée à vos besoins.
Docker
Docker est une technologie de conteneurisation qui simplifie la gestion des dépendances d’un projet, aussi bien en phase de développement qu’en phase de déploiement.
Disponible sur Linux, Windows et macOS, Docker s’articule autour des conteneurs et de leur orchestration. C’est précisément là que la conteneurisation se distingue de la virtualisation.
L’architecture de Docker repose sur deux piliers principaux : l’interface de ligne de commande (CLI) Docker et le démon Docker.
Démon Docker :
Il s’agit d’un processus d’arrière-plan, constamment actif, qui prend en charge la gestion des images Docker, des conteneurs, des réseaux et des volumes de stockage. Le démon Docker communique avec l’extérieur via une API REST Docker Engine, accessible par le protocole HTTP.
Interface de ligne de commande Docker :
Crédit d’image: Redhat
Cette interface constitue le client de ligne de commande qui permet d’interagir avec le démon Docker. C’est l’outil que vous utilisez lorsque vous exécutez une commande Docker.
Le fonctionnement de Docker s’appuie sur le noyau Linux et certaines de ses fonctionnalités, telles que les cgroups et les espaces de noms. Ces mécanismes permettent d’isoler les processus afin qu’ils puissent fonctionner de manière indépendante. L’objectif étant d’exécuter plusieurs processus et applications distinctes dans des conteneurs.
Cette approche permet d’optimiser l’utilisation de l’infrastructure sans compromettre la sécurité par rapport à des systèmes séparés.
Tous les outils de conteneurisation, comme Docker, suivent un modèle de déploiement basé sur l’image. Ce modèle facilite le partage d’une application, ou d’un ensemble de services, dans différents environnements.
De plus, Docker permet d’automatiser le déploiement d’applications dans un environnement conteneurisé. Grâce à ces outils, les utilisateurs bénéficient d’un accès complet aux applications et peuvent accélérer le déploiement, contrôler les versions et effectuer des mises à jour.
Podman
Podman, acronyme de « POD MANager », a pour fonction de construire, d’exécuter et de gérer les conteneurs OCI et les images de conteneurs. Développé par Red Hat, il était initialement destiné à son système d’exploitation Linux 8. Il est utilisé pour la gestion des conteneurs et se présente comme le successeur officiel de Docker.
Red Hat a cessé le support de Docker, mais a assuré que la transition serait aisée pour les utilisateurs, Podman étant basé sur Docker, bien qu’à l’origine, il n’ait été conçu que comme un outil de débogage.
Podman gère l’ensemble de l’écosystème de conteneurs via la bibliothèque libpod. Puisque Podman ne fonctionne que sur les plateformes Linux, une API REST et des clients sont en cours de développement afin de permettre aux systèmes Mac et Windows d’interagir avec le service.
Néanmoins, il existe actuellement un client distant basé sur Varlink qui fonctionne sur les plateformes Mac ou Windows et qui permet la communication à distance avec un serveur Podman basé sur Linux. La bibliothèque libpod prend en charge plusieurs méthodes pour télécharger des images en toute sécurité, notamment la confiance et la vérification d’image.
Il prend également en charge les pods pour gérer des groupes de conteneurs ensemble, ainsi que plusieurs formats d’image, notamment les formats OCI et Docker.
Dans des environnements petits et gérables, Podman peut même servir de précurseur à Kubernetes. Il comble le fossé entre la gestion individuelle des instances des premières années de la conteneurisation et l’orchestration moderne avec Kubernetes.
Les utilisateurs de conteneurs peuvent déjà profiter d’un niveau supérieur avec les pods. La création et l’exploitation d’un cluster Kubernetes ne sont plus indispensables. Dans le cas le plus simple, les pods nouvellement conçus peuvent être testés et améliorés lors d’opérations individuelles. Même un transfert ultérieur vers Kubernetes est envisageable.
La commande `podman generate kube` fournit les fichiers de configuration correspondants, qui servent d’entrée à l’outil Kubernetes `kubectl`.
Les versions actuelles de Podman peuvent même générer des fichiers de configuration pour systemd, un avantage pour les utilisateurs de ce système d’initialisation pour l’orchestration des conteneurs.
Podman contre Docker : Différences
Docker s’est rapidement imposé comme la référence en matière de gestion de conteneurs. Bien qu’il présente de nombreux avantages, notamment son vaste répertoire d’images, il n’est pas exempt d’inconvénients et de risques de sécurité potentiels. De plus, Docker n’est plus pris en charge comme conteneur pour Kubernetes.
Le fait que les conteneurs, contrairement aux systèmes virtuels, ne nécessitent pas leur propre noyau est généralement considéré comme un avantage majeur. Cependant, cela présente un risque de sécurité important avec Docker, car les conteneurs Docker ne peuvent être exécutés qu’avec des privilèges root.
Cela permet aux processus exécutés dans les conteneurs d’accéder au noyau avec des privilèges root et ainsi potentiellement d’attaquer le système hôte.
Une première distinction est perceptible dès la première utilisation. Alors que Docker nécessite le démarrage préalable du démon Docker, un conteneur Podman peut être lancé directement depuis la ligne de commande. Il n’y a donc pas de processus en arrière-plan et l’application n’est exécutée qu’en cas de nécessité.
Du point de vue de la sécurité, c’est un atout, car Podman est moins vulnérable aux attaques si le démon n’a pas à fonctionner 24h/24 et 7j/7 avec des privilèges de superutilisateur. L’architecture de Podman, qui diffère fondamentalement de Docker, explique l’absence de processus d’arrière-plan.
Alors que Docker suit le modèle client-serveur, où le client Docker communique avec le démon Docker via une API, Podman adopte le modèle fork-exec. Chaque conteneur s’exécute en tant que processus enfant de Podman.
Un espace de noms d’utilisateur est créé lors de la première utilisation, lorsque Podman est exécuté avec des privilèges d’utilisateur normaux. Dans cet espace de noms, Podman s’exécute avec les privilèges root et a le droit de monter des systèmes de fichiers et de créer des conteneurs.
Par conséquent, le conteneur Podman ne possède que les droits de l’utilisateur qui l’exécute. L’utilisation d’espaces de noms d’utilisateurs signifie que chaque utilisateur peut créer et gérer ses propres conteneurs, qui ne sont pas visibles par les autres utilisateurs ou le superutilisateur.
Parce que Podman fonctionne indépendamment de Docker, les développeurs disposent d’une grande marge de manœuvre et peuvent répondre aux besoins de la communauté. Les ajouts notables de Podman incluent les commandes `mount/unmount` et l’intégration systemd.
L’hôte peut utiliser la commande `mount/unmount` pour monter le système de fichiers du conteneur, par exemple pour accéder ou modifier des fichiers, puis le démonter à nouveau.
Bien que la surveillance des conteneurs à l’aide de systemd ne soit pas possible en raison du démon Docker, avec Podman, les conteneurs peuvent être démarrés, surveillés et redémarrés via systemd.
De plus, Podman fournit la commande `podman generate systemd`, qui génère un service systemd correspondant pour le conteneur concerné, soulageant ainsi l’utilisateur de la création des services systemd. L’intégration sur le système hôte est donc facilitée.
Une autre différence cruciale entre Podman et Docker réside dans la gestion du pare-feu. Docker doit modifier les règles de pare-feu pour permettre la communication entre les conteneurs, alors que Podman n’altère pas les règles de pare-feu ou l’installation actuelle de dnsmasq, grâce à sa capacité à créer un réseau interne.
| Podman | Docker | |
| Architecture | Sans démon | Avec démon |
| Gestion des services | Systemd | Docker Engine |
| Compatibilité avec le pare-feu | Respecte les règles de pare-feu | Remplace les règles de pare-feu |
| Plateforme | Prise en charge native de Linux | Linux, Windows et Mac |
Quand migrer de Docker vers Podman
Si vous déployez des conteneurs dans un environnement basé sur RHEL, Podman est la solution naturelle, car il est natif de ce système. Vous pouvez également migrer vers Podman ou le choisir si vous avez de petits déploiements avec peu de conteneurs.
Cependant, si vos besoins dépassent cette simplicité, avec plusieurs conteneurs et une pile de conteneurs coordonnés avec docker-compose/podman-compose sur un réseau, il est préférable d’utiliser Docker, car il gère mieux la mise en réseau.
De même, si vous débutez dans le monde des conteneurs, Docker est un meilleur choix, car il est stable, bien établi, dispose d’une documentation adéquate et sa courbe d’apprentissage est moins abrupte que celle de Podman, qui manque encore de stabilité et de documentation bien définie.
Migration de Podman vers Docker
Si vous utilisez la ligne de commande, il est relativement aisé de passer de Docker Engine à Podman. Dans sa forme la plus simple, un alias `$ docker=podman` fonctionne la plupart du temps.
Bien sûr, cela suppose que le logiciel approprié est installé sur le système. Sous Linux, ce n’est pas un problème ; des packages précompilés sont disponibles pour les distributions commerciales.
Windows ou macOS ne font pas partie des systèmes d’exploitation pris en charge. L’approche par alias est efficace car de nombreuses commandes Docker ont un équivalent Podman.
Cependant, des exceptions existent, car certaines commandes Docker n’ont pas d’équivalent dans le monde Podman. De même, certaines commandes se comportent différemment dans Docker et dans Podman. Pour le moment, cela n’affecte que le traitement des volumes déjà configurés.
La transition est un peu plus délicate lorsque des outils graphiques, tels que Docker Desktop, sont utilisés. Cela concerne particulièrement les développeurs qui travaillent sous Windows ou macOS.
Les utilisateurs de Docker Desktop devront se familiariser avec la ligne de commande, et il en va de même pour Docker compose. Heureusement, le projet podman-compose, écrit en Python, offre une alternative à Docker compose.
Derniers mots
Le remplacement de Docker par Podman peut être considéré comme presque abouti. Pour les utilisateurs et les administrateurs, la plupart des aspects de ce changement sont simples. De nombreuses fonctionnalités de Docker ont des équivalents dans Podman.
L’absence d’un processus démon unique et de privilèges root, sans oublier l’utilisation naturelle des groupes de conteneurs, sont des avantages significatifs. Il convient cependant de noter que Docker reste la technologie dominante en matière de conteneurs, mais cette situation pourrait évoluer à long terme.
N’hésitez pas à explorer certaines commandes Docker pour mieux gérer vos conteneurs.