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 :

1
2
3
4
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│ Docker CLI   │ ──► │ Docker Daemon│ ──► │  Conteneur   │
│ (client)     │     │ (dockerd)    │     │              │
└──────────────┘     └──────────────┘     └──────────────┘
  • 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 :

1
2
3
4
┌──────────────┐     ┌──────────────┐
│ Podman CLI   │ ──► │  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
1
2
3
4
5
# Podman : conteneurs sans privilèges root
podman run -it alpine sh

# Docker : nécessite le groupe docker ou sudo (traditionnellement)
sudo docker run -it alpine sh

Gagnant sécurité : Podman

2. Compatibilité des commandes

La syntaxe est presque identique.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Docker
docker run -d -p 8080:80 nginx
docker ps
docker images
docker build -t mon-app .

# Podman (mêmes commandes !)
podman run -d -p 8080:80 nginx
podman ps
podman images
podman build -t mon-app .

Vous pouvez créer un alias pour une transition sans douleur :

1
alias docker=podman

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 :

  1. podman-compose : réimplémentation Python
  2. podman compose : intégré dans les versions récentes (utilise Compose spec)
1
2
3
4
5
# Avec Podman récent
podman compose up -d

# Avec podman-compose (installation séparée)
podman-compose up -d

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
1
2
3
4
5
6
7
8
# Podman peut utiliser les images Docker Hub
podman pull docker.io/library/nginx

# Sauvegarder une image
podman save -o nginx.tar nginx

# La charger dans Docker
docker load -i nginx.tar

5. Pods : une fonctionnalité propre à Podman

Podman supporte nativement les pods, des groupes de conteneurs qui partagent l’espace de noms réseau :

1
2
3
4
5
6
7
8
# Créer un pod
podman pod create --name mon-pod -p 8080:80

# Ajouter des conteneurs au pod
podman run -d --pod mon-pod nginx
podman run -d --pod mon-pod redis

# Les conteneurs dans le pod communiquent via localhost

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 :

1
2
3
4
5
# Générer un fichier service systemd depuis un conteneur
podman generate systemd --name mon-conteneur > mon-conteneur.service

# Activer le conteneur au démarrage du système
systemctl --user enable mon-conteneur.service

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 :

AspectDockerPodman
Démarrage conteneurLégèrement plus rapideLégèrement plus lent
Mémoire de base~50-100 Mo (daemon)~0 Mo (pas de daemon)
Build imagesRapide (BuildKit)Comparable
I/O disqueExcellentExcellent

La différence est négligeable pour la plupart des usages.

Docker vs Podman en un coup d’œil

CaractéristiqueDockerPodman
DaemonOuiNon
Rootless par défautNonOui
Compatibilité commandes-99%
Docker ComposeNatifVia podman-compose
Pods natifsNonOui
Intégration systemdLimitéeNative
Support KubernetesDocker DesktopNatif
GUI DesktopDocker DesktopPodman Desktop
PlateformesLinux, Win, MacLinux, Win, Mac
LicenceApache 2.0Apache 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

1
2
3
4
5
6
7
8
# Fedora/RHEL
sudo dnf install podman

# Ubuntu/Debian
sudo apt install podman

# Mac (avec Homebrew)
brew install podman

2. Créez l’alias

1
2
# Dans votre .bashrc ou .zshrc
alias docker=podman

3. Testez vos workflows

La plupart des commandes fonctionneront identiquement. Vérifiez :

  • Le build des images
  • Docker Compose (utilisez podman compose ou podman-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.

Articles associés