Docker et Podman exécutent les mêmes images avec les mêmes commandes. Ce qui les sépare, c’est l’architecture : Podman n’a pas de daemon en arrière-plan et tourne rootless par défaut, tandis que Docker apporte l’outillage mature, Docker Desktop et un Compose de première classe. Voici les différences qui pèsent vraiment sur votre travail : daemon, root, Compose et pods.
Qu’est-ce que Podman ?
Podman (Pod Manager) est un outil pour gérer les conteneurs et les pods, développé par Red Hat comme alternative open source à Docker. Sa caractéristique principale ? Il n’a pas besoin d’un daemon en cours d’exécution.
Le nom “Podman” vient du concept de “pod”, le même utilisé dans Kubernetes : un groupe de conteneurs qui partagent des ressources.
La différence fondamentale : daemon ou daemonless
Docker : architecture client-serveur
Docker fonctionne avec un daemon (dockerd) toujours en cours d’exécution en arrière-plan :
| |
- Le daemon s’exécute en tant que root
- Toutes les commandes passent par le daemon
- Si le daemon plante, vous perdez l’accès aux conteneurs
Podman : architecture fork-exec
Podman n’a pas de daemon. Chaque commande crée directement le processus du conteneur :
| |
- Pas de processus en arrière-plan
- Les conteneurs sont des enfants directs de la commande Podman
- Chaque utilisateur gère ses propres conteneurs
Docker vs Podman, point par point
1. Sécurité : rootless par défaut
Docker :
- Le daemon s’exécute traditionnellement en tant que root
- Mode rootless disponible mais pas par défaut
- Un exploit dans le daemon = accès root au système
Podman :
- Rootless par défaut
- Chaque utilisateur a ses propres conteneurs isolés
- Pas de daemon privilégié à attaquer
| |
Gagnant sécurité : Podman
2. Compatibilité des commandes
La syntaxe est presque identique.
| |
Vous pouvez créer un alias pour une transition sans douleur :
| |
Compatibilité : Presque totale pour l’usage quotidien
3. Docker Compose vs Podman Compose
Docker Compose est le standard de facto pour orchestrer plusieurs conteneurs en développement.
Podman offre deux options :
- podman-compose : réimplémentation Python
- podman compose : intégré dans les versions récentes (utilise Compose spec)
| |
Note : La compatibilité est bonne mais pas parfaite. Certains fichiers docker-compose.yml pourraient nécessiter de petits ajustements.
4. Gestion des images
Les deux utilisent le même format d’images (OCI), donc vous pouvez :
- Utiliser les mêmes images de Docker Hub
- Construire des images avec le même Dockerfile
- Transférer des images entre Docker et Podman
| |
5. Pods : une fonctionnalité propre à Podman
Podman supporte nativement les pods, des groupes de conteneurs qui partagent l’espace de noms réseau :
| |
C’est comme ça que vous simulez un pod Kubernetes sur votre portable : les conteneurs partagent un namespace réseau et se joignent donc sur localhost.
Docker n’a pas d’équivalent direct (il utilise les networks).
6. Intégration avec systemd
Podman s’intègre nativement avec systemd, le système init de Linux :
| |
Cela permet de gérer les conteneurs comme des services système normaux, sans avoir besoin d’un daemon séparé.
7. Performances
Les performances sont comparables dans la plupart des cas :
| Aspect | Docker | Podman |
|---|---|---|
| Démarrage conteneur | Légèrement plus rapide | Légèrement plus lent |
| Mémoire de base | ~50-100 Mo (daemon) | ~0 Mo (pas de daemon) |
| Build images | Rapide (BuildKit) | Comparable |
| I/O disque | Excellent | Excellent |
La différence est négligeable pour la plupart des usages.
Docker vs Podman en un coup d’œil
| Caractéristique | Docker | Podman |
|---|---|---|
| Daemon | Oui | Non |
| Rootless par défaut | Non | Oui |
| Compatibilité commandes | - | 99% |
| Docker Compose | Natif | Via podman-compose |
| Pods natifs | Non | Oui |
| Intégration systemd | Limitée | Native |
| Support Kubernetes | Docker Desktop | Natif |
| GUI Desktop | Docker Desktop | Podman Desktop |
| Plateformes | Linux, Win, Mac | Linux, Win, Mac |
| Licence | Apache 2.0 | Apache 2.0 |
Quand choisir Docker
Docker reste le meilleur choix si :
- Vous travaillez en équipe qui utilise déjà Docker
- Vous avez besoin de Docker Compose avec une compatibilité parfaite
- Vous utilisez Docker Desktop et ses fonctionnalités (Kubernetes intégré, extensions)
- Vous suivez des tutoriels et de la documentation (presque tous utilisent Docker)
- Vous avez besoin d’un support commercial
Quand choisir Podman
Podman est préférable si :
- La sécurité est prioritaire (environnements enterprise, production)
- Vous travaillez sur RHEL, CentOS, Fedora (intégration native)
- Vous voulez des conteneurs rootless sans configuration supplémentaire
- Vous devez gérer des conteneurs comme des services systemd
- Vous apprenez Kubernetes (les pods sont un avantage)
- Vous ne voulez pas d’un daemon toujours en cours d’exécution
Comment migrer de Docker vers Podman
Si vous voulez essayer Podman tout en maintenant la compatibilité :
1. Installez Podman
| |
2. Créez l’alias
| |
3. Testez vos workflows
La plupart des commandes fonctionneront identiquement. Vérifiez :
- Le build des images
- Docker Compose (utilisez
podman composeoupodman-compose) - Les volumes et networks
4. Résolvez les incompatibilités
Les plus courantes :
- Certains flags spécifiques à Docker n’existent pas
- Le socket Docker (
/var/run/docker.sock) n’existe pas par défaut - Certaines intégrations CI/CD pourraient nécessiter des ajustements
Docker et Podman peuvent-ils coexister ?
Oui ! Docker et Podman peuvent coexister sur le même système. Ils utilisent un stockage séparé, donc les conteneurs et images ne sont pas partagés, mais vous pouvez utiliser les deux pour des besoins différents.
Lequel utiliser
Vous partez de zéro, ou vous apprenez : prenez Podman. Rootless par défaut, pas de daemon, et les pods font comprendre les concepts de Kubernetes plus tôt. La compatibilité des commandes fait que le changement ne coûte presque rien ensuite.
Vous travaillez dans une équipe qui utilise déjà Docker, ou vous vous appuyez sur Docker Compose et Docker Desktop : restez sur Docker. L’écosystème est plus mature et chaque tutoriel le suppose. Rien n’oblige à migrer une installation en place.
Quoi que vous appreniez avec l’un, cela se reporte presque entièrement sur l’autre.