Docker vs Podman : quel moteur de conteneurs choisir
Docker vs Podman, expliqué simplement : la vraie différence entre les deux, ce qu'elle change pour votre sécurité et votre budget, et lequel choisir.
Un conteneur, c’est une façon d’emballer un logiciel avec tout ce dont il a besoin pour tourner, afin qu’il se comporte exactement de la même manière sur le portable d’un développeur, sur un serveur de test et en production. Deux outils se partagent le travail de fabrication et de lancement de ces conteneurs : Docker et Podman. La plupart des gens dégainent Docker par habitude, puis se demandent si Podman vaut le détour. La réponse honnête, dans n’importe quelle comparaison Docker vs Podman, tient en une phrase : les deux font tourner exactement les mêmes conteneurs, donc le choix ne se joue presque jamais sur les fonctionnalités. Il se joue sur une seule décision de conception, et sur ce que cette décision implique pour votre sécurité et votre budget.
La seule différence qui compte vraiment : qui commande
Docker fait tourner un programme permanent en arrière-plan, toujours actif, qui est propriétaire de tous les conteneurs de la machine. Vos commandes parlent à ce programme, et c’est lui qui exécute le travail. Par défaut, il tourne avec les pleins droits d’administrateur, ce que Linux appelle le compte root : le compte tout-puissant, capable de toucher à n’importe quoi sur le système. Ce gestionnaire central est pratique, parce qu’une seule chose supervise tout. C’est aussi une cible unique, et puissante. Si un attaquant atteint le programme de fond de Docker, il atteint la machine entière avec les droits d’administrateur — et c’est précisément ce qui a piégé certaines équipes qui avaient donné à un conteneur un accès trop large à ce programme.
Ce gestionnaire central a une seconde conséquence, plus discrète. Comme un seul programme possède tout, le redémarrer touche d’un coup tous les conteneurs de la machine, et s’il plante, il peut entraîner l’ensemble dans sa chute. Confortable quand tout va bien, fragile le jour où ça va mal.
Podman, lui, n’a aucun gestionnaire de ce genre. Il n’y a pas de programme toujours allumé au milieu. Chaque conteneur tourne directement sous votre compte ordinaire, sans privilège particulier, comme n’importe quel autre programme que vous auriez lancé. Les conteneurs sont indépendants les uns des autres : un problème sur l’un n’atteint pas les autres. Et si quelque chose tourne mal à l’intérieur d’un conteneur, l’incident reste enfermé dans votre compte limité, au lieu de détenir les clés de la machine.
Voilà toute l’histoire, une fois le jargon mis de côté. La vraie ligne de partage n’est pas ce que les deux outils savent faire, mais ce que vous obtenez sans avoir à y penser. On peut configurer Docker pour qu’il tourne sans ces droits d’administrateur, et on peut rendre Podman plus proche de Docker, mais le point de départ est inversé. Avec Podman, la configuration sûre est celle que vous avez d’office. Avec Docker, il faut savoir la demander — et la plupart des équipes ne s’y mettent jamais.
Pourquoi ce sont les réglages par défaut qui décident
Les réglages livrés activés deviennent la façon dont presque tout le monde se sert d’un outil. Une protection qu’il faut lire, comprendre, puis activer protège bien moins de monde qu’une protection simplement déjà là. C’est l’idée durable à retenir de tout ce débat : avec Podman, le choix prudent est le réglage par défaut ; avec Docker, c’est le choix pratique. À peu près tout le reste en découle.
Pour quelqu’un qui fait tourner du code qu’il n’a pas écrit lui-même, ou qui partage un serveur de build avec toute une équipe, ce réglage par défaut représente de l’argent réel, en incidents évités. Une intrusion qui aboutit à l’intérieur de votre compte limité, c’est un dégât circonscrit. Une intrusion qui aboutit avec les droits d’administrateur sur la machine, c’est une mauvaise journée pour toute l’entreprise.
Là où Docker garde toute sa valeur
Rien de tout cela ne fait de Docker un mauvais choix. La vraie force de Docker n’est pas technique, c’est sa gravité. Il est arrivé le premier, et il est partout. Presque chaque tutoriel, chaque service d’hébergement, chaque logiciel prêt à l’emploi et chaque réponse trouvée en ligne partent du principe que vous utilisez Docker. Quand votre but est de livrer quelque chose plutôt que d’étudier le fonctionnement des conteneurs, cette familiarité a une valeur bien réelle. Vous rencontrez moins de surprises, et quand vous en rencontrez une, quelqu’un a déjà écrit la solution quelque part.
Docker vend aussi une application de bureau qui gomme une vraie aspérité : les ordinateurs Mac et Windows ne peuvent pas faire tourner des conteneurs Linux directement. L’application installe donc discrètement un petit environnement Linux caché et vous offre une fenêtre soignée pour le piloter. Pour un développeur qui veut des conteneurs fonctionnels en dix minutes, ce vernis a son prix, et il reste un cran plus fluide que les alternatives gratuites sur les portables qui ne tournent pas sous Linux.
La question du coût
C’est ici que le budget entre en jeu. Le cœur de Docker est gratuit, et vous pouvez le faire tourner sur un serveur Linux sans rien débourser. C’est l’application de bureau que les entreprises paient, et la facture grandit avec la taille de l’entreprise. Les propres conditions d’utilisation de Docker réservent l’application de bureau gratuite aux particuliers et aux petites structures. Dès qu’une organisation dépasse quelques centaines de salariés ou environ dix millions de dollars de chiffre d’affaires annuel, chaque développeur qui utilise l’application de bureau a besoin d’une licence payante. Pour une équipe de quarante personnes, c’est une dépense récurrente, qui gonfle à mesure que vous recrutez. Le prix exact par licence et par mois bouge avec le temps et selon les formules : le chiffre compte donc moins que la forme générale, un coût par personne qui monte avec les effectifs.
L’application de bureau équivalente chez Podman est gratuite et open source, sans plafond d’effectifs ni seuil de chiffre d’affaires à surveiller. Pour une entreprise qui regarde ses dépenses, « gratuit et sans petites lignes » est une conversation vite réglée. La contrepartie, c’est le vernis évoqué plus haut, et un peu plus d’attention à la configuration sur Mac et Windows.
Une idée plus durable se cache dans cette ligne de coût. Les conditions tarifaires de Docker ont déjà changé une fois, et un outil dont le prix peut changer est un coût que vous ne maîtrisez pas entièrement. Une partie de ce qui a poussé les équipes vers l’option gratuite n’était pas l’économie sur la facture de cette année, mais le confort de ne pas dépendre des décisions tarifaires de quelqu’un d’autre l’année suivante. Quand une alternative gratuite et sans contrainte fait presque le même travail, cette indépendance est en soi une raison de la choisir, indépendamment de l’argent économisé aujourd’hui.
Ce qui ne change pas, quel que soit votre choix
Avant de vous tourmenter sur la décision, il est utile de mesurer tout ce que les deux outils ont en commun, parce que cela abaisse considérablement les enjeux. Les deux fabriquent des conteneurs à partir du même genre de recette, qu’on appelle une image : un instantané figé d’une application accompagnée de tout ce qui l’entoure et dont elle a besoin. Une image construite avec un outil tourne parfaitement bien sous l’autre. Les commandes du quotidien sont volontairement quasi identiques, assez proches pour que les réflexes acquis passent directement de l’un à l’autre.
Choisir entre les deux n’est donc pas un mariage. Vous pouvez faire tourner les deux sur la même machine, et déplacer un projet de l’un vers l’autre avec très peu de frictions. Cela vaut la peine de le garder en tête quand le choix paraît lourd de conséquences. Il l’est rarement — et c’est justement pour ça que tant d’équipes se sont senties libres d’essayer Podman dès que la tarification de Docker leur a donné une raison de regarder ailleurs.
Alors, lequel choisir
Il n’y a pas de vainqueur unique, mais la situation pointe en général clairement dans une direction.
Si vous travaillez seul sous Linux, Podman est le choix évident. Vous obtenez la configuration sûre par défaut, aucun programme permanent à surveiller en arrière-plan, et aucune licence à garder à l’œil. Les commandes sont assez proches de celles de Docker pour que l’habitude se transfère en une après-midi. La seule raison de rester sous Docker serait un outil précis dont vous dépendez et qui refuse de fonctionner avec autre chose.
Si vous êtes sur un portable Mac ou Windows, l’application de bureau de Docker reste l’expérience la plus fluide, et en tant que particulier vous relevez de toute façon de l’offre gratuite. L’application de bureau de Podman est une alternative tout à fait correcte si vous préférez ne dépendre de Docker en rien.
Si vous êtes une petite équipe avec des machines de build partagées, appuyez-vous sur Podman là où ça compte : sur les serveurs, où son comportement isolé par défaut comble une vraie faille de sécurité, et laissez chacun utiliser ce qu’il veut sur son propre portable. Les conteneurs sont interchangeables, donc le choix de l’outil sur le portable a rarement de l’importance.
Si vous êtes une grande entreprise, surtout sur un système Red Hat, Podman est la voie de moindre résistance. C’est l’option intégrée et officiellement supportée sur cette plateforme, elle s’accorde avec le reste de l’environnement, et elle retire entièrement la question des licences de la table.
Questions fréquentes
Puis-je passer de Docker à Podman sans tout réapprendre ?
En grande partie, oui. Les commandes sont volontairement quasi identiques, et beaucoup de gens font le saut sans le moindre accroc. La friction apparaît avec les autres outils qui attendent spécifiquement le gestionnaire de fond de Docker, et avec la configuration occasionnelle où les réglages plus stricts de Podman vous prennent au dépourvu. Pour fabriquer et lancer des conteneurs au quotidien, traitez ça comme un échange réalisable en une après-midi. Pour une installation existante compliquée, prévoyez d’y passer un peu de temps à ajuster et à tester.
L’un est-il plus rapide que l’autre ?
Pour le logiciel qui tourne à l’intérieur du conteneur, la différence est trop infime pour se remarquer. Les deux confient le travail réel à la même machinerie sous-jacente de Linux, donc un programme en cours d’exécution se comporte de la même façon dans les deux cas. Podman peut être plus léger quand il ne se passe rien, parce qu’il n’a aucun programme permanent qui occupe la mémoire à attendre — un avantage surtout sur les petites machines et pour les tâches courtes et fréquentes, plutôt que pour des charges lourdes et continues.
Suis-je obligé de payer pour Docker ?
Dans un seul cas. Faire tourner Docker sur un serveur Linux est gratuit pour tout le monde. La partie payante, c’est l’application de bureau sur Mac et Windows, et seulement une fois que votre entreprise dépasse le seuil de taille fixé par Docker. Si vous voulez éviter complètement la question, l’application de bureau de Podman fait le même travail gratuitement sur toutes les plateformes — c’est précisément pour ça qu’une vague d’entreprises a migré quand les règles de tarification ont changé.
Mes fichiers de configuration existants fonctionneront-ils encore ?
En général, oui. Si vous décrivez vos applications dans le format de fichier multi-conteneurs courant que Docker a popularisé, Podman sait lire les mêmes fichiers. Les configurations simples, comme un site web et sa base de données, fonctionnent le plus souvent sans modification. Les plus élaborées peuvent demander quelques retouches : le réflexe sûr est de copier votre configuration, de la lancer, et de corriger les rares points qui coincent, plutôt que de miser sur un premier essai impeccable.
Photo : Lukas Blazek / Pexels
