Si vous êtes dans le monde de la virtualisation et de la conteneurisation, vous avez probablement rencontré Podman et Docker et vous vous demandez peut-être en quoi ils sont différents l’un de l’autre.
Dans cet article, nous allons explorer les différences entre Docker et Podman et essayer de trouver celui qui vous conviendra le mieux !
Docker
Docker est une technologie de conteneurisation qui facilite la gestion des dépendances au sein d’un projet à tous les niveaux (développement et déploiement).
Disponible sous Linux, Windows et Mac OS, le mécanisme de Docker est centré sur les conteneurs et leur orchestration, et c’est là que la conteneurisation se distingue de la virtualisation.
Docker se compose de deux éléments principaux : Docker CLI et Docker Daemon.
Docker Daemon :
Il s’agit d’un processus constant en arrière-plan qui aide à gérer les images Docker, les conteneurs, les réseaux et les volumes de stockage. Docker utilise son API REST Docker Engine pour interagir avec le démon Docker, accessible via le protocole HTTP.
CLI Docker :
Il s’agit du client de ligne de commande Docker permettant d’interagir avec le démon Docker. C’est ce que vous utilisez lorsque vous exécutez une commande Docker.
Le fonctionnement de Docker est basé sur le noyau Linux et les fonctions de ce noyau, telles que les cgroups et les espaces de noms. Ces fonctions séparent les processus afin qu’ils puissent s’exécuter indépendamment, car l’objectif des conteneurs est d’exécuter plusieurs processus et applications séparément.
C’est ce qui permet d’optimiser l’utilisation de l’infrastructure sans réduire le niveau de sécurité par rapport aux systèmes séparés.
Tous les outils de conteneurs, comme Docker, s’accompagnent d’un modèle de déploiement basé sur l’image. Ce modèle simplifie le partage d’une application ou d’un ensemble de services entre plusieurs environnements.
De plus, Docker permet d’automatiser le déploiement des applications dans un environnement de conteneurs. Grâce à ces différents outils, les utilisateurs ont un accès complet aux applications et peuvent accélérer le déploiement, contrôler les versions et les attribuer.
Podman
Podman (le POD MANager) construit, exécute et gère les conteneurs OCI et les images de conteneurs. Développé par Red Hat et destiné à l’origine à son Linux d’entreprise 8, il est utilisé pour la gestion des conteneurs et fait office de successeur officiel de Docker.
Red Hat a donc cessé de soutenir Docker, mais a assuré que le changement serait facile pour les utilisateurs puisque Podman est basé sur Docker, bien qu’à l’origine il n’ait été conçu que comme un outil de débogage.
Il gère l’ensemble de l’écosystème des conteneurs à l’aide de la bibliothèque libpod. Podman ne fonctionnant que sur les plateformes Linux, une API REST et des clients sont actuellement en cours de développement pour permettre aux systèmes Mac et Windows d’appeler le service.
Cependant, , 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é, y compris la confiance et la vérification des images.
Elle prend également en charge les pods pour gérer des groupes de conteneurs ensemble et plusieurs formats d’image, y compris les formats d’image OCI et Docker.
Dans les environnements très petits et gérables, Podman peut même servir de précurseur à Kubernetes. Il comble le fossé entre la gestion singulière des instances individuelles des premières années de l’engouement pour les conteneurs et l’orchestration moderne avec Kubernetes.
Les utilisateurs ambitieux de conteneurs peuvent déjà profiter du niveau suivant avec les pods. La construction et l’exploitation d’un cluster Kubernetes ne sont plus nécessaires. Dans le cas le plus simple, les pods nouvellement conçus peuvent être testés et améliorés dans le cadre d’opérations individuelles. Même un transfert ultérieur vers Kubernetes est possible.
La commande podman generate kube fournit les fichiers de configuration correspondants. Ceux-ci servent ensuite, un à un, d’entrée pour l’outil Kubernetes kubectl.
Les versions actuelles de Podman peuvent même créer des fichiers de configuration pour systemd – une aubaine pour tous ceux qui utilisent l’omniprésent successeur init pour l’orchestration de conteneurs.
Podman vs Docker : Différences
Docker s’est rapidement imposé comme le cheval de bataille de la gestion des conteneurs. Cependant, Docker présente de nombreux avantages, notamment le répertoire d’images qui s’enrichit rapidement, ainsi que des inconvénients et des risques éventuels pour la sécurité. En outre, Docker n’ est plus pris en charge en tant que conteneur pour Kubernetes.
Le fait que les conteneurs, contrairement aux systèmes virtuels, n’aient pas besoin de leur noyau est généralement considéré comme l’un des grands avantages. Cependant, cela pose un risque de sécurité majeur avec Docker car les conteneurs Docker ne peuvent être exécutés qu’avec les privilèges de root.
Cela permet aux processus s’exécutant dans les conteneurs d’accéder au noyau avec les privilèges root et d’attaquer ainsi le système hôte.
La première distinction est évidente lorsque vous l’utilisez pour la première fois. Alors que Docker nécessite le démarrage préalable du démon Docker, un conteneur Podman peut être démarré directement à partir de la ligne de commande. Il n’y a donc pas de processus d’arrière-plan, et l’application n’est exécutée qu’en cas de besoin.
Du point de vue de la sécurité, c’est une bonne chose car Podman est moins vulnérable aux attaques si le démon n’a pas à fonctionner 24 heures sur 24 et 7 jours sur 7 avec les privilèges d’un superutilisateur. Podman ne nécessite pas de processus d’arrière-plan en raison de son architecture, qui diffère fondamentalement de celle de Docker.
Alors que Docker suit le modèle client-serveur, où le client Docker communique avec le démon Docker via une API, Podman suit le modèle fork-exec. Chaque conteneur s’exécute en tant que processus enfant de Podman.
Un espace de noms utilisateur est créé lors de la première utilisation lorsque Podman est exécuté avec des privilèges d’utilisateur normaux. Dans l’espace de noms de l’utilisateur, Podman s’exécute avec les privilèges de l’administrateur (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 dispose que des 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, mais que ceux-ci ne sont pas visibles pour les autres utilisateurs et le superutilisateur.
Podman étant exploité indépendamment de Docker, les développeurs disposent d’une grande marge de manœuvre et peuvent répondre aux souhaits de la communauté. Les ajouts intéressants à Podman comprennent la commande mount/unmount et l’intégration de systemd.
L’hôte peut utiliser la commande mount/unmount pour monter le système de fichiers du conteneur, par exemple pour accéder à des fichiers ou les modifier, puis les démonter à nouveau.
Bien que la surveillance des conteneurs à l’aide de systemd ne fonctionne pas en raison du démon dans Docker avec Podman, les conteneurs peuvent être démarrés, surveillés et même redémarrés via systemd.
En outre, Podman propose la commande podman generate systemd, qui génère un service systemd correspondant pour le conteneur concerné et décharge ainsi l’utilisateur de la création des services systemd, ce qui signifie que l’intégration sur le système hôte est disponible.
Une autre différence cruciale entre Podman et Docker est que ce dernier ne modifie pas les règles du pare-feu ou l’installation actuelle de dnsmasq en raison de sa capacité à créer un réseau interne. En revanche, Docker doit écraser les règles du pare-feu pour permettre la communication entre les conteneurs.
| Podman | Docker | |
| Architecture | Daemon | Daemon moins |
| Gestion des services | Systemd | Moteur Docker |
| Compatibilité avec les pare-feux | Écrase les règles de pare-feu | Respecte les règles de pare-feu |
| Plateforme | Prise en charge native de Linux | Linux, Windows et Mac |
Quand devriez-vous migrer de Docker à Podman ?
Si vous déployez des conteneurs dans un environnement basé sur RHEL, dans ce cas, vous n’avez pas beaucoup d’options à part utiliser Podman car il est natif de RHEL. Vous pouvez également migrer vers Podman ou choisir Podman plutôt que Docker si vous avez de petits déploiements avec peu de conteneurs.
Cependant, si vous voulez aller plus loin, ayez 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 beaucoup mieux la mise en réseau.
De même, si vous commencez tout juste à entrer dans le monde des conteneurs, dans ce cas, Docker est une meilleure option car il est stable, bien établi avec une documentation appropriée, et a une courbe d’apprentissage peu profonde par rapport à Podman, qui manque encore de stabilité et n’a pas de documentation bien définie.
Migration de Podman vers Docker
Si vous êtes en ligne de commande, il est assez facile de passer de Docker Engine à Podman. Dans sa forme la plus simple, une commande $ alias docker=podman fonctionne la plupart du temps.
Bien sûr, cela suppose que le logiciel approprié soit installé sur le système. Dans le cas de Linux, ce n’est pas un problème non plus ; des logiciels prêts à l’emploi 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 fonctionne car de nombreuses commandes Docker ont un équivalent Podman.
Mais il y a aussi des exceptions, 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 l’univers Podman. Pour l’instant, cela n’affecte que la gestion des volumes qui ont déjà été configurés.
La transition est un peu plus difficile lorsque des outils graphiques tels que Docker Desktop sont utilisés. Cela devrait particulièrement affecter les développeurs qui travaillent avec Windows ou macOS.
Les utilisateurs de Docker Desktop devront s’habituer à la ligne de commande, et il en va de même pour Docker compose. Il existe cependant le projet podman-compose. Écrit en Python, le logiciel sert de remplacement à Docker compose.
Dernières paroles
Le remplacement de Docker par Podman peut être considéré comme presque terminé. Pour les utilisateurs et les administrateurs, la plupart des aspects de ce changement sont simples. De nombreuses fonctionnalités de Docker ont des équivalents identiques dans Podman.
L’absence de processus démon unique et de privilèges root, sans parler de l’utilisation naturelle de groupes de conteneurs, constitue un réel avantage. Cependant, il convient de mentionner que Docker reste la principale technologie concernant les conteneurs, mais cela changera très probablement à long terme.