Pourquoi je suis passé de Docker à Podman

 (codesmash.dev)
14 points par GN⁺ 2025-09-06 | 8 commentaires | Partager sur WhatsApp
  • Docker a longtemps été critiqué pour des problèmes de failles de sécurité et de consommation de ressources liés à son architecture à démon en arrière-plan (dockerd)
  • Podman adopte une architecture sans démon, ce qui permet aux conteneurs de s’exécuter directement avec les permissions de l’utilisateur, réduisant la surface d’attaque et renforçant la stabilité
  • Grâce à l’intégration avec systemd, à une conception pensée pour Kubernetes et à la prise en charge d’outils séparés fondés sur la philosophie Unix comme Buildah/Skopeo, l’exploitation gagne en efficacité
  • La compatibilité élevée avec la CLI Docker permet à la plupart des workflows existants de fonctionner tels quels avec un simple alias docker=podman
  • Même en production, la sécurité et la gestion des ressources deviennent plus simples, et pour les nouveaux projets, Podman s’impose comme une option plus rationnelle et tournée vers l’avenir

Les limites de Docker et les problèmes de sécurité

  • Docker repose sur une architecture où le démon dockerd s’exécute en permanence avec les privilèges root
    • Si une faille du démon est découverte, l’ensemble de l’hôte peut être exposé
  • Exemples marquants d’incidents de sécurité
    • 2019 : évasion de conteneur runC (CVE-2019-5736)
    • 2022 : faille Linux Dirty Pipe, évasion via cgroups v1
    • 2024 : runC « Leaky Vessels », faille BuildKit
    • 2024 : campagne de cryptojacking via exposition de l’API Docker
  • La répétition de ces incidents a mis en lumière le risque fondamental d’une architecture basée sur un démon

L’architecture daemonless de Podman

  • Podman n’utilise pas de démon en arrière-plan
    • Lors de l’exécution de podman run, le conteneur fonctionne comme processus enfant direct de la commande lancée
    • En mode rootless, même les privilèges root à l’intérieur du conteneur ne correspondent, sur l’hôte, qu’aux droits d’un utilisateur ordinaire
  • Avantages
    • Sécurité renforcée : en cas d’évasion de conteneur, l’étendue des dégâts est réduite
    • Stabilité accrue : si un conteneur s’arrête, les autres ne sont pas affectés
    • Efficacité des ressources : l’absence de démon résident réduit l’usage mémoire

Les fonctionnalités distinctives de Podman

  • Intégration avec systemd
    • podman generate systemd permet de générer automatiquement un fichier d’unité systemd
    • Les services peuvent être gérés avec les commandes standard systemctl
  • Affinité avec Kubernetes
    • La notion de Pod est intégrée nativement, ce qui facilite le développement d’applications multi-conteneurs
    • podman generate kube permet de générer directement du YAML Kubernetes
  • Philosophie Unix
    • Podman se concentre sur l’exécution des conteneurs, tandis que la construction d’images est assurée par Buildah et la gestion des registres par Skopeo
    • Il est ainsi possible d’utiliser des outils optimisés selon leur objectif

Migration et compatibilité

  • Le passage de Docker à Podman se fait presque sans interruption
    • La CLI étant compatible, on peut généralement remplacer docker par podman tel quel
    • Les Dockerfile existants continuent de fonctionner sans modification
  • Différences à connaître
    • En mode rootless, il est impossible de binder des ports inférieurs à 1024 → un reverse proxy est recommandé
    • Il faut gérer les permissions des volumes
    • Les outils dépendant du socket Docker peuvent utiliser le mode de compatibilité API Docker de Podman

Mise en pratique et bénéfices

  • Après adoption de Podman en environnement de production
    • La charge liée aux contrôles de sécurité diminue, avec une sécurité rootless appliquée par défaut
    • Les schémas d’utilisation des ressources deviennent plus simples et plus prévisibles
  • Docker reste très répandu, mais pour les nouveaux projets ou lorsqu’on a de la latitude dans ses choix techniques, Podman est plus adapté
    • Intégration naturelle avec les mécanismes d’administration Linux
    • Architecture orientée Kubernetes
    • Fournit un environnement d’exécution de conteneurs plus sûr et plus rationnel

Résumé du guide de migration FastAPI

  • Les Dockerfile existants peuvent être utilisés tels quels
  • Remplacement simple avec podman build et podman run
  • Enregistrement comme service systemd avec podman generate systemd
  • Les Pods permettent de prendre en charge des environnements multi-services comme les bases de données
  • Le workflow Docker Compose peut être géré avec podman-compose ou via une conversion avec kompose

À lire aussi

8 commentaires

 
shortstories 2025-09-09

Ici, il est écrit qu’une transition sans interruption de service est possible, mais dans un environnement de production réel, il y a pas mal de bizarreries. Par exemple, sur macOS, comme la configuration par défaut utilise la compression zstd, l’image construite a tendance à occuper pas mal d’espace dans le registre...
 
codemasterkimc 2025-09-08

Docker, Podman, tout pareil....

securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL

securityContext:
runAsNonRoot: true
runAsUser: UID
 
koxel 2025-09-08

En réalité, la compatibilité avec Docker n’est pas si bonne, donc l’ergonomie n’est pas terrible…
Je suis passé à Podman en pensant au mode rootless, puis je suis finalement revenu à Docker.
Comme l’a dit quelqu’un d’autre, si c’est pour l’utiliser avec Kubernetes, autant utiliser directement containerd.
 
click 2025-09-08

Je me demande si, puisque Docker Compose ne fonctionne pas bien et que l’avantage mis en avant est une bonne compatibilité avec Kubernetes, il ne vaudrait pas mieux utiliser directement Kubernetes.
J’ai aussi essayé de l’utiliser, mais comme ça ne fonctionnait pas d’un coup et qu’on ne peut pas non plus faire soi-même le mapping des ports inférieurs à 1024, j’utilise finalement une combinaison de k3s et de nerdctl pour construire les images.
 
ndrgrd 2025-09-07

J’avais envie de faire le changement depuis un moment, mais quand j’ai essayé auparavant, contrairement à ce que disaient les développeurs, beaucoup trop de projets docker compose ne fonctionnaient tout simplement pas correctement...
 
afewgoodman 2025-09-07

Docker ne prend même pas en charge le réseau.
 
devsepnine 2025-09-07

Je crois savoir que, comme Docker, il prend aussi en charge les fonctionnalités réseau.
Y a-t-il encore des points qui ne fonctionnent pas correctement ?
 
GN⁺ 2025-09-06
Avis Hacker News
  • En 2001/2002, j’ai dû mettre en place des boîtiers de hotspots Wi‑Fi. À l’époque, j’étais fan d’OpenBSD et je voulais alléger au maximum une distribution écrite en Python. Pour éviter les copies de fichiers inutiles et les problèmes de dépendances, j’ai choisi les concepts de chroot et de jail. Mon code de déploiement exécutait le logiciel hors de l’environnement jail et surveillait, via ptrace, les fichiers ouverts par le processus. À partir de cette sortie, j’extrayais une liste de dépendances pour en faire un paquet. Au final, le déploiement était petit, immuable et plus sûr. Quand Docker est arrivé, ça m’a rappelé cette ancienne méthode, et je me suis demandé s’il existait un outil similaire qui surveille réellement l’usage des fichiers d’un conteneur Docker pour réduire la distribution
    • Le meilleur pipeline CI/CD que j’aie utilisé, c’était un déploiement freelance Django. Un hook git post‑receive automatisait, à chaque git push, la construction des fichiers statiques et le redémarrage de httpd. Il suffisait de faire git push live master pour déployer. J’ai beaucoup utilisé Docker, mais c’était malgré tout le déploiement le plus simple. Je vois bien les avantages de Docker, mais configurer du HTTP sur Ubuntu ou OpenBSD n’est pas si difficile. Je me demande si la reproductibilité propre à Docker vaut vraiment toute cette surcharge de gestion
    • Le premier résultat Google est slimtoolkit/slim, avec 22k étoiles
    • Dans l’environnement OpenWrt, il existe un outil appelé ujail : on lui passe un exécutable ELF, il analyse les dépendances de bibliothèques nécessaires et ne monte en lecture seule dans un tmpfs que les fichiers indispensables
      Lien vers le code concerné
  • Podman est pour moi une expérience vraiment excellente. J’ai trouvé Docker difficile à utiliser, avec plein de pièges, alors que Podman n’a absolument rien à lui envier. Surtout, dans l’entreprise où je travaille, on n’a pas à se soucier des licences. C’est du gagnant-gagnant total
    • Je suis curieux de savoir si les licences étaient vraiment un sujet d’inquiétude dans ton entreprise. La politique de licence payante de Docker Desktop est raisonnable. C’est gratuit pour les structures de moins de 250 employés ou de moins de 10 millions de dollars de chiffre d’affaires. Même à 90 $ par an, vu le salaire d’un développeur aux États‑Unis, ça ne représente même pas le prix d’un déjeuner. Et en plus, on dispose d’un outil officiellement pris en charge sur tous les OS
    • En réalité, une entreprise n’a pas vraiment à se soucier des licences. Docker Engine est entièrement open source, donc gratuit. Seul Docker Desktop nécessite une licence distincte en usage entreprise. Mais la plupart des fonctionnalités sont déjà disponibles dans Docker Engine
    • Podman est bien meilleur que Docker. On n’a pas à se préoccuper de la gestion des permissions utilisateur/groupe ni des problèmes de sécurité liés aux processus root. Il n’y a pas non plus besoin d’envoyer des données à un démon
    • Sur certains PC, le désinstalleur Windows de Podman ne supprime pas correctement tous les composants, ce qui laisse des erreurs au redémarrage. Même en supprimant les services à la main, le problème persiste. C’est une source d’agacement assez fréquente
  • J’aime beaucoup Podman, mais il ne fonctionne pas toujours bien avec tous les conteneurs. Par exemple, de gros conteneurs comme GitLab dépendent souvent de l’histoire complexe et des particularités de Docker, ce qui provoque régulièrement des erreurs avec Podman. Je pense que les images que j’ai créées moi‑même tournent pour la plupart très bien avec Podman. Pour contourner les conteneurs problématiques, je lance une VM Incus et je les exécute dedans. L’accès au GPU est aussi incohérent, aussi bien avec Podman qu’avec Docker, ce qui est pénible. Malgré cela, je trouve Podman un peu meilleur. Le mode rootless, surtout, est un gros avantage
    • Je suppose que la plupart des problèmes viennent d’images qui démarrent PID 1 en root. Podman étant rootless par défaut, cela provoque ce genre de souci. Si tu veux aussi utiliser des images root sans Docker, tu peux séparer Podman en modes rootful et rootless et utiliser le flag --connection pour cibler l’environnement voulu. Si besoin, Podman peut même créer automatiquement une VM pour toi (via lima). Podman Desktop propose aussi une couche de compatibilité Docker qui atténue les problèmes de compatibilité
    • Le fait même que certains conteneurs ne fonctionnent pas avec Podman est probablement la raison d’être de ce billet de blog. Si la base d’utilisateurs devient assez grande, on prendra l’habitude de vérifier aussi l’environnement Podman avant publication
    • Nous faisons tourner le serveur GitLab et les runners entièrement sous Podman. Personnellement, j’aimerais migrer les runners vers k8s, mais pour l’instant, avec Traefik, cela fonctionne bien
    • J’utilise beaucoup de fonctionnalités liées à buildx ; sur le papier, ça marche aussi avec Podman, mais en pratique, pas vraiment
  • Le plus gros problème, c’est le support de Podman sur Ubuntu. La version fournie par défaut est tellement ancienne qu’elle est inutilisable telle quelle. Moi, j’utilise Podman v5, GitHub Actions tourne en v3, et mes collègues utilisent Docker. Résultat : je dois faire en sorte que mes scripts fonctionnent à la fois avec un vieux Podman, un Podman récent et Docker, ce qui ajoute une complexité inutile
    • Il n’existe pas de dépôt fiable pour des builds .deb. Il n’y a pas de .deb officiel, et tout ce que j’ai trouvé est soit obsolète, soit indiqué comme non maintenu à l’avenir. Du coup, la question reste entière : pourquoi Podman ne simplifie-t-il pas davantage l’installation ? À mon avis, c’est parce que RedHat n’a pas envie de consacrer des ressources de développement au support de produits concurrents. C’est compréhensible, mais on a l’impression que tout ce qui n’est pas dans l’écosystème RedHat est traité comme un citoyen de seconde zone
    • Je pense que c’est là le vrai problème. Le manque de notoriété face à Docker compte, mais les écarts de version sont bien davantage ce qui cantonne Podman à une niche. Des distributions comme Ubuntu fournissent souvent des logiciels anciens ; c’est certes un problème que les mainteneurs devraient résoudre eux‑mêmes, mais l’équipe Podman ne semble pas très active sur ce terrain. C’est d’ailleurs pour cela que j’ai fini par remplacer mon home server par une machine de type Red Hat, simplement pour avoir un Podman récent
    • Le fait qu’il n’y ait pas de .deb officiel upstream fourni de manière continue nous empêche d’utiliser Podman en interne. Quand on voit à quel point le dépôt .deb officiel de Docker est bien entretenu, c’est difficile de ne pas être jaloux
    • C’est aussi l’une des raisons pour lesquelles je n’utilise pas Ubuntu/Debian : les mises à jour y arrivent trop lentement. On pourrait peut‑être l’utiliser via flatpak, mais j’aimerais que ce type de logiciel soit proposé par défaut
    • Podman étant open source, des distributions comme Ubuntu peuvent empaqueter et mettre à jour le logiciel elles‑mêmes. On peut aussi comprendre que RedHat hésite à prendre en charge le packaging de logiciels pour des systèmes concurrents
  • J’ai récemment dû mettre en place Podman pour le travail, et ça a été l’une des pires expériences que j’aie eues. La combinaison Podman rootless + SELinux + utilisateur non privilégié dans le conteneur, c’est un véritable enfer
    • On peut toujours se compliquer la vie avec n’importe quoi, mais en pratique, la plupart du temps, ça marche bien. Je fais tourner plusieurs services (Forgejo, runner, uptime-kuma, etc.) dans des conteneurs rootless derrière un reverse proxy nginx sur des machines RHEL10 avec SELinux activé, et ça fonctionne correctement
    • Je n’ai jamais perçu le moindre avantage concret au rootless. Si la machine appartient à un seul domaine de sécurité, on peut tout aussi bien l’exécuter en root ; et si ce n’est pas le cas, il faut alors un vrai environnement isolé (par exemple Firecracker/Kata VM, etc.). Le rootless demande beaucoup d’efforts pour un bénéfice qui me semble discutable
    • J’ai vécu la même situation en entreprise, mais en adoptant la manière de faire propre à Podman (cf. la doc), ça devient utilisable. Le point clé est de lire la documentation des versions récentes
    • Cela fait plus de 7 ans que j’utilise uniquement Podman sur Fedora
    • Notre organisation a entièrement migré de Docker vers Podman ; il y a eu quelques accrocs au passage, mais l’équipe SysDev a pu les résoudre sans trop de difficultés
  • On dit souvent que si un workflow Docker Compose devient trop complexe, il faut directement le convertir en YAML Kubernetes, mais d’après mon expérience, le YAML K8s est bien plus complexe que docker compose. Et tout le monde n’utilise pas Kubernetes
    • Je ne suis pas d’accord. Le YAML K8s est d’une complexité comparable à docker compose, voire parfois plus simple. Il est juste incroyablement verbeux. Un compose de 100 lignes peut se transformer en 20 fichiers YAML de 50 lignes chacun. J’aimerais que kubectl fournisse une sorte de sucre syntaxique pour convertir dans les deux sens entre YAML simple et complexe
    • Utiliser un LLM comme couche lors de la conversion de docker compose vers du YAML k8s fonctionne étonnamment bien. À noter que Podman sait aussi générer du YAML k8s, donc la migration peut se faire assez naturellement
    • Je ne sais pas écrire un fichier compose, mais je sais écrire du YAML k8s. Du coup, c’est compose qui me paraît plus « complexe »
  • La commande podman generate systemd mentionnée dans l’article est désormais deprecated. L’alternative, ce sont les Podman Quadlets, qui fonctionnent un peu comme un docker-compose.yaml défini à l’intérieur d’un fichier d’unité systemd
    • Déléguer Compose/l’orchestration à systemd est logique. Comme ce n’est pas une architecture client-serveur comme Docker mais de vrais processus utilisateur, c’est un choix tout à fait cohérent
    • Le problème, c’est qu’il n’y a quasiment pas de documentation
  • Il est difficile de mapper un conteneur multi‑UID sur un seul utilisateur hôte. Par défaut, root dans le conteneur est mappé à l’utilisateur qui l’exécute sur l’hôte, mais récemment beaucoup d’applications ont commencé à utiliser des utilisateurs non root dans le conteneur (par exemple www-data, l’utilisateur 1000, etc.). Ceux‑ci sont alors mappés à des ID secondaires sur l’hôte, et avec les montages de volumes, cela laisse des propriétaires de fichiers orphelins, ce qui crée beaucoup de confusion. Il manque une option simple pour mapper tous les UID vers un seul utilisateur, et les options existantes (uidmap de crun, userns) ne fonctionnent pas bien. Je m’interroge sur l’utilité réelle des mappings d’ID secondaires
    • Si je comprends bien, c’est une limite des namespaces Linux. Pour que des outils comme Docker ou Podman prennent en charge ce genre de mapping, il faudrait que Linux le supporte lui‑même. La raison pour laquelle un mapping UID 1:1 est indispensable, c’est que si les utilisateurs 1000 et 0 du conteneur sont mappés vers le même utilisateur hôte, les informations de propriétaire des fichiers deviennent incohérentes
    • Tu peux aussi regarder du côté des idmapped mounts. Cela ne règle que le remappage au niveau du système de fichiers, pas les appels noyau
    • J’aimerais bien qu’il existe un moyen de simplement fonctionner « en tant que soi‑même » à l’intérieur du conteneur, avec des propriétaires affichés tels quels aussi dans les logs
    • En utilisant l’option ignore_chown_errors, on peut appliquer simplement le mapping de root vers l’ID utilisateur sans mappings supplémentaires
  • J’ai tenté plusieurs fois de migrer vers Podman, mais j’ai échoué sur plusieurs points. D’abord, les performances de Podman étaient nettement inférieures à celles de Docker sur mon petit VPS (je passe les détails). Ensuite, l’écosystème de développement n’a pas complètement suivi. Beaucoup d’outils dépendent du socket Docker, et Podman ne fonctionne pas bien avec eux à cause de problèmes de permissions ou de différences de compatibilité API. Podman n’est pas un remplacement drop-in parfait
    • Si tu utilises Podman rootless, un réseau lent peut venir de slirp4netns. pasta est plus rapide. Docker, lui, configure le réseau via un démon privilégié par défaut, donc si tu utilises Podman en root, il ne devrait pas y avoir de différence de performances
    • Les erreurs de permissions SELinux avec podman et quadlet continuent d’être une vraie plaie. En général, il est plus simple de créer un pod avec des privilèges sur tout l’hôte, d’y monter uniquement les /dev nécessaires et d’exposer un programme très limité sur un réseau isolé
    • C’est amusant, mais sur mes systèmes pauvres en ressources, Podman a largement surpassé Docker en performances et en consommation de ressources. Cela semble venir de la différence entre crun et runc. Et comme Podman n’a pas de démon, il est plus léger
  • J’ai abandonné Docker et Podman pour passer à FreeBSD Jails
    • Plus d’informations et des outils d’administration sont disponibles ici,
      ici,
      ici,
      ici
    • Peut-on exécuter instantanément MS SQL Server ou des milliers de conteneurs Docker dans un jail FreeBSD ? Choisir FreeBSD implique un coût important, notamment en termes de compatibilité. C’est aussi pour cela que les jails ne se sont pas imposés plus largement
    • Il y a vraiment beaucoup de configuration ; je me demande s’il existe aussi quelque chose comme containerd sur FreeBSD
    • Les jails FreeBSD sont une fonctionnalité spécifique à cette distribution
    • Je me demande quelle est la différence entre faire tourner une VM sur un hôte Linux et utiliser un jail FreeBSD