Ah, Podman. Ce nom qui traîne dans les threads Reddit, les conférences DevOps et les slides des gens qui aiment bien dire qu’ils ont « migré ». Si tu utilises docker depuis des années sans te plaindre, tu te demandes peut-être pourquoi certains en font tout un plat. C’est pas juste pour le plaisir de réinventer la roue a mon avis, voyons ca...
Podman, c’est quoi ? Un Docker en mieux ?
Podman, c’est un outil de gestion de conteneurs, comme Docker. Sauf que là où Docker repose sur un daemon (dockerd) qui tourne en root et gère tout en arrière-plan, Podman est daemonless. Traduction : pas de processus central qui monopolise les ressources et qui, accessoirement, peut devenir un joli point d’entrée pour les attaques si tu ne fais pas gaffe.
Podman utilise runc (comme Docker) pour lancer les conteneurs, mais il le fait directement via des appels système, sans intermédiaire. Résultat : moins de surcharge, et surtout, la possibilité de lancer des conteneurs en rootless sans bidouiller des heures avec user namespaces. Pour les paranoïaques de la sécurité (ou ceux qui bossent dans des boîtes où le mot « compliance » donne des sueurs froides), c’est un argument de poids.
Autre différence notable : Podman gère nativement les pods, ces groupes de conteneurs qui partagent un même réseau et un même stockage. Pratique si tu veux reproduire un peu l’expérience Kubernetes sans te taper un cluster entier. Docker, lui, a besoin de docker-compose pour faire à peu près la même chose, et encore, c’est moins intégré.
Pour qui Podman est-il fait ? ...pas pour tout le monde
Si tu es un dev solo qui lance deux conteneurs en local pour tester ton app, Podman ne va pas révolutionner ta vie. docker run et docker-compose up font très bien le job, et l’absence de daemon ne te fera ni chaud ni froid. En revanche, si tu es dans l’un de ces cas, Podman peut t’intéresser :
- Tu travailles dans un environnement ultra-sécurisé : les conteneurs rootless, c’est la vie. Plus besoin de donner des droits root à ton utilisateur ou de prier pour que personne ne trouve une faille dans
dockerd. - Tu utilises Kubernetes : Podman est compatible avec
kubectlviapodman play kube. Pas besoin de Docker Desktop ou de Minikube pour tester tes manifests en local. - Tu es allergique aux daemons : certains admins système ont une phobie des processus qui tournent en arrière-plan. Podman, c’est leur thérapie.
- Tu veux éviter Docker Desktop : depuis que Docker a décidé de faire payer son outil pour les entreprises, certains cherchent des alternatives. Podman +
buildah(pour les builds) +skopeo(pour les push/pull) forment un trio qui peut remplacer Docker sans trop de douleur.
En revanche, si tu es un utilisateur occasionnel ou que tu dépends d’outils qui s’attendent à trouver docker sous le capot (comme certains CI/CD ou IDE), Podman peut te compliquer la vie. La compatibilité avec les commandes Docker est bonne, mais pas parfaite. Par exemple, docker build devient buildah build, et docker push se transforme en skopeo copy. Pas insurmontable, mais ça demande un peu de réapprentissage.
Docker vs Podman : le match des commandes (et des trolls)
Podman se veut compatible avec les commandes Docker. En théorie, tu peux même créer un alias alias docker=podman et continuer à bosser comme avant. En pratique, il y a quelques différences qui peuvent te faire perdre des cheveux :
- Le daemon :
docker psinterrogedockerd,podman psinterroge directement les conteneurs en cours d’exécution. Pas de daemon = pas de risque de le voir planter et emporter tous tes conteneurs avec lui. - Les volumes : Podman gère les volumes différemment, surtout en rootless. Si tu montes un volume en local, assure-toi que les permissions sont bonnes, sinon tu risques de te retrouver avec des erreurs du type
permission denied. - Les réseaux : Podman utilise
netavarketaardvark-dnspar défaut, alors que Docker utiliselibnetwork. Rien de dramatique, mais si tu as des scripts qui dépendent de la configuration réseau de Docker, il faudra peut-être les adapter.
Un exemple concret pour illustrer la différence. Avec Docker, pour lancer un conteneur Nginx :
docker run -d --name nginx -p 8080:80 nginx
Avec Podman, c’est presque la même chose :
podman run -d --name nginx -p 8080:80 nginx
Jusqu’ici, tout va bien. Mais si tu veux builder une image, Docker utilise docker build, alors que Podman te redirige vers buildah :
buildah build -t mon-image .
Pas dramatique, mais ça casse un peu le flow si tu es habitué à Docker.
Podman, c’est la fin de Docker ?
Non. Docker reste l’outil le plus utilisé, le plus documenté, et celui qui a la plus grande communauté. Podman est une alternative solide, mais il n’a pas (encore) l’écosystème de Docker. Si tu es un dev qui utilise Docker en local pour tester des trucs, Podman ne va pas te faire gagner du temps. En revanche, si tu es dans un environnement où la sécurité est critique, ou si tu veux éviter Docker Desktop, Podman est une option sérieuse.
Le vrai débat n’est pas « Podman vs Docker », mais « est-ce que j’ai besoin de ce que Podman apporte ? ». Si la réponse est non, continue à utiliser Docker sans culpabiliser. Si la réponse est oui, Podman est là, prêt à te sauver de dockerd et de ses caprices. Et si tu veux vraiment rigoler, essaie de lancer les deux en même temps et regarde qui gagne. A mon avis ton CPU va pleurer.
En résumé : Podman n’est pas une révolution, mais c’est un outil qui a sa place. À toi de voir si cette place est dans ton PATH ou dans un coin de ta mémoire, entre « les trucs que j’ai testés une fois » et « les trucs que j’utiliserai peut-être un jour ».