Podman rootless : alternative Docker sans daemon — tutoriel 2026

Introduction

Imaginez un serveur VPS mutualisé en Côte d’Ivoire ou au Sénégal, partagé entre trois clients d’une PME. Vous voulez déployer une application Node.js dans un conteneur isolé, mais votre hébergeur refuse de vous donner les droits root complets, et pour cause : un daemon Docker tournant en root est une surface d’attaque béante. Une faille dans l’API Unix socket de Docker peut compromettre la machine entière, pas seulement votre conteneur. C’est exactement le problème que Podman résout à la racine, sans compromis sur la productivité.

Podman (POD MANager) est un moteur de conteneurs daemon-less et rootless développé par Red Hat et la communauté containers. Contrairement à Docker, il ne nécessite aucun processus daemon tournant en arrière-plan avec les privilèges root. Chaque commande podman run lance directement un processus enfant dans l’espace utilisateur courant, sans passer par un intermédiaire à hauts privilèges. En mode rootless, les conteneurs s’exécutent sous votre UID Linux, isolés dans leur propre espace de noms utilisateur (user namespace), sans jamais avoir besoin du compte root sur l’hôte.

Podman 5.x, la version stable actuelle en 2026, apporte des améliorations majeures : pasta comme outil réseau rootless par défaut (remplaçant slirp4netns), le support complet de Quadlet pour la gestion déclarative via systemd, et une compatibilité CLI quasi-totale avec Docker. Ce tutoriel vous guide pas à pas de l’installation à la production, en moins de 25 minutes.

Prérequis

• OS : Linux 64 bits — Ubuntu 22.04/24.04, Debian 12, Fedora 39+, RHEL/AlmaLinux/Rocky 9+, ou tout dérivé moderne. Kernel 5.15+ recommandé (user namespaces activés par défaut).
• Droits : compte utilisateur non-root avec sudo pour l’installation initiale uniquement.
• Temps estimé : environ 25 minutes pour l’ensemble du tutoriel.
• Niveau : intermédiaire — vous avez déjà utilisé Docker ou des commandes Linux de base.
• Outils tiers : git, curl, python3-pip (pour podman-compose). Tout est installable via le gestionnaire de paquets standard.

Étape 1 — Podman vs Docker : une CLI compatible, une architecture radicalement différente

Avant d’installer quoi que ce soit, il est utile de comprendre pourquoi Podman existe et ce qui le distingue fondamentalement de Docker, au-delà du marketing. Docker fonctionne selon un modèle client-serveur : la commande docker que vous tapez n’est qu’un client qui envoie des requêtes à un daemon dockerd tournant en permanence avec les droits root. Ce daemon gère tous les conteneurs, toutes les images, tous les volumes. Si ce daemon s’arrête — panne, mise à jour, crash — tous vos conteneurs s’arrêtent avec lui. Pire, n’importe quel utilisateur appartenant au groupe docker dispose en pratique de droits root sur la machine, car il peut monter /etc/passwd en lecture-écriture dans un conteneur.

Podman adopte une architecture radicalement différente : il n’y a pas de daemon. Chaque invocation de podman run forke directement un processus conmon (container monitor) qui supervise le conteneur. Ce processus appartient à votre utilisateur, pas à root. Quand votre session se termine, vos conteneurs peuvent continuer via systemd (nous verrons ça à l’Étape 5), mais aucun processus root persistant n’est nécessaire pour les maintenir en vie.

La bonne nouvelle pour les utilisateurs Docker : la CLI Podman est intentionnellement compatible. La quasi-totalité des commandes Docker fonctionnent avec Podman en remplaçant simplement docker par podman. Vous pouvez même créer un alias permanent pour ne rien changer à vos habitudes :

# Comparer les commandes équivalentes
# Docker                    Podman (équivalent exact)
docker run nginx            # podman run nginx
docker build -t app .       # podman build -t app .
docker ps                   # podman ps
docker images               # podman images
docker exec -it ctn bash    # podman exec -it ctn bash
docker-compose up -d        # podman-compose up -d

Les différences notables concernent la gestion réseau en mode rootless (pas d’accès aux ports inférieurs à 1024 sans configuration spécifique), l’absence de socket Docker par défaut (certains outils tiers qui s’appuient sur /var/run/docker.sock nécessitent une adaptation), et la gestion des pods natifs (fonctionnalité absente de Docker CLI standard). Pour l’essentiel du workflow quotidien — pull, run, build, push, logs, exec — la transition est transparente.

Étape 2 — Installer Podman 5.x

L’installation de Podman varie légèrement selon la distribution, mais les dépôts officiels couvrent toutes les distributions majeures. La règle d’or est d’utiliser le dépôt officiel du projet containers plutôt que les paquets parfois anciens des dépôts de distribution de base — Ubuntu 22.04 LTS, par exemple, proposait encore Podman 3.x dans ses dépôts par défaut, alors que Podman 5.x apporte des améliorations de sécurité et de réseau indispensables.

Sur Ubuntu 24.04 / Debian 12, Podman 5.x est disponible directement dans les dépôts officiels :

# Mettre à jour l'index des paquets
sudo apt update

# Installer Podman et ses dépendances (pasta pour le réseau rootless)
sudo apt install -y podman

# Vérifier la version installée
podman --version
# Sortie attendue : podman version 5.x.x

Pour Ubuntu 22.04 LTS (qui propose une version plus ancienne), utilisez le dépôt Kubic maintenu par la communauté containers :

# Ajouter le dépôt Kubic pour obtenir Podman 5.x sur Ubuntu 22.04
. /etc/os-release
echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_${VERSION_ID}/ /" \
  | sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:unstable.list
curl -L "https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/unstable/xUbuntu_${VERSION_ID}/Release.key" \
  | sudo apt-key add -
sudo apt update
sudo apt install -y podman

Sur Fedora / RHEL 9 / AlmaLinux / Rocky Linux, Podman est préinstallé ou disponible via dnf :

# Fedora — Podman souvent déjà présent, sinon :
sudo dnf install -y podman

# RHEL/AlmaLinux/Rocky 9 — activer le module container-tools :
sudo dnf module enable container-tools:rhel9
sudo dnf install -y podman

Après installation, une étape cruciale pour le mode rootless consiste à vérifier que votre utilisateur dispose d’une plage d’UIDs subordonnés dans /etc/subuid et /etc/subgid. Ces fichiers permettent à Podman de mapper les UIDs des processus conteneurisés vers des UIDs non-root sur l’hôte, ce qui constitue l’isolation fondamentale du mode rootless :

# Vérifier que votre utilisateur a des UIDs subordonnés
cat /etc/subuid
# Sortie attendue (exemple pour l'utilisateur "deploy") :
# deploy:100000:65536

cat /etc/subgid
# deploy:100000:65536

# Si absent, les ajouter (remplacer "deploy" par votre nom d'utilisateur) :
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy

# Mettre à jour la configuration rootless après modification
podman system migrate

Si la commande usermod --add-subuids n’est pas disponible (versions anciennes), éditez manuellement /etc/subuid en ajoutant la ligne deploy:100000:65536. La plage 100000:65536 signifie 65 536 UIDs disponibles en partant de 100 000 — largement suffisant pour tous les cas d’usage courants.

Étape 3 — Premier conteneur rootless

La vraie puissance de Podman s’apprécie dès le premier run : vous n’avez besoin d’aucun sudo, d’aucun daemon préalablement démarré, d’aucune appartenance à un groupe spécial. Vous lancez simplement la commande en tant qu’utilisateur ordinaire, et Podman gère tout le reste dans votre espace utilisateur.

# Premier conteneur rootless — aucun sudo requis
podman run --rm hello-world

# Lancer un conteneur Nginx en arrière-plan, port 8080 (pas 80 — voir note ci-dessous)
podman run -d --name mon-nginx -p 8080:80 nginx:alpine

# Vérifier que le conteneur tourne
podman ps
# CONTAINER ID  IMAGE          COMMAND               CREATED        STATUS         PORTS                 NAMES
# a1b2c3d4e5f6  nginx:alpine   nginx -g daemon o...  5 seconds ago  Up 5 seconds   0.0.0.0:8080->80/tcp  mon-nginx

# Tester
curl http://localhost:8080
# Retourne le HTML de la page Nginx par défaut

# Voir les logs
podman logs mon-nginx

# Stopper et supprimer
podman stop mon-nginx
podman rm mon-nginx

Notez l’utilisation du port 8080 et non 80 : en mode rootless, les ports inférieurs à 1024 sont réservés au noyau Linux et inaccessibles aux utilisateurs non-root par défaut. Pour exposer le port 80 en production, deux options propres existent : utiliser un reverse proxy (Nginx, Caddy, Traefik) qui écoute sur le port 80 avec les droits adéquats et transmet au conteneur sur 8080, ou modifier net.ipv4.ip_unprivileged_port_start dans sysctl pour abaisser la limite (à utiliser avec prudence sur un serveur partagé).

Les images sont stockées dans ~/.local/share/containers/storage/, séparément pour chaque utilisateur — contrairement à Docker où toutes les images partagent /var/lib/docker/ accessible uniquement par root. Cela signifie que deux utilisateurs sur la même machine peuvent avoir des versions d’images différentes sans interférence, et que supprimer votre utilisateur suffit à nettoyer tous vos conteneurs et images sans traces résiduelles.

Étape 4 — Pods : des groupes de conteneurs qui partagent le réseau

L’une des fonctionnalités les plus puissantes de Podman, et celle qui l’illustre le mieux par rapport à Docker CLI standard, est la gestion native des pods. Un pod est un groupe de conteneurs qui partagent le même espace de noms réseau — exactement comme dans Kubernetes. Concrètement, tous les conteneurs d’un même pod se voient sur localhost, partagent la même adresse IP et les mêmes ports exposés. C’est le modèle de déploiement idéal pour une application multi-tiers : backend, frontend, et proxy dans le même pod, qui communiquent via localhost sans configuration réseau complexe.

# Créer un pod avec un port exposé vers l'hôte
podman pod create --name mon-app -p 8080:80

# Ajouter un conteneur Nginx dans ce pod
podman run -d --pod mon-app --name nginx-pod nginx:alpine

# Ajouter un conteneur applicatif dans le même pod
# Il communique avec Nginx via localhost:80 (réseau partagé)
podman run -d --pod mon-app --name app-pod node:20-alpine node -e \
  "require('http').createServer((req,res)=>res.end('Hello ITS')).listen(3000)"

# Inspecter l'état du pod
podman pod ps
# POD ID        NAME      STATUS   CREATED         INFRA ID      # OF CONTAINERS
# f1e2d3c4b5a6  mon-app   Running  30 seconds ago  a0b1c2d3e4f5  3

# Les 3 conteneurs comprennent l'"infra container" (pause container)
# qui maintient le namespace réseau du pod même si les autres redémarrent
podman ps --pod

# Stopper et supprimer tout le pod d'un coup
podman pod stop mon-app
podman pod rm mon-app

L’infra container mérite une explication : c’est un micro-conteneur (image localhost/podman-pause) qui ne fait que maintenir en vie l’espace de noms réseau du pod. Il garantit que si votre conteneur applicatif redémarre, il retrouve la même configuration réseau sans avoir besoin de recréer le pod entier. C’est un concept directement hérité de Kubernetes, ce qui facilite grandement la migration de vos déploiements Podman vers un cluster k8s le moment venu.

Étape 5 — Quadlet : des unités systemd générées automatiquement

La gestion de la persistance des conteneurs entre les redémarrages est l’un des points qui déconcerte le plus les nouveaux utilisateurs venant de Docker (où --restart always suffit, puisque le daemon redémarre les conteneurs). Avec Podman, l’approche recommandée en 2026 est Quadlet : un générateur systemd intégré à Podman qui transforme des fichiers déclaratifs .container en unités systemd valides, sans écrire de fichier .service à la main.

Quadlet remplace définitivement podman generate systemd, qui est déprécié depuis Podman 4.4 et ne recevra plus de nouvelles fonctionnalités. Pour créer un service systemd pour votre utilisateur qui démarre automatiquement au login (ou au boot avec l’option lingering), voici la marche à suivre :

# Créer le répertoire Quadlet utilisateur
mkdir -p ~/.config/containers/systemd/

# Créer le fichier déclaratif pour un conteneur Nginx
cat > ~/.config/containers/systemd/nginx-web.container << 'EOF'
[Unit]
Description=Nginx web server via Podman rootless
After=network-online.target

[Container]
Image=nginx:alpine
PublishPort=8080:80
Volume=%h/www:/usr/share/nginx/html:ro,Z
Environment=NGINX_HOST=example.com

[Service]
Restart=always
RestartSec=10s

[Install]
WantedBy=default.target
EOF

# Recharger le daemon systemd utilisateur pour que Quadlet génère les unités
systemctl --user daemon-reload

# Démarrer le service (Quadlet a généré nginx-web.service automatiquement)
systemctl --user start nginx-web
systemctl --user status nginx-web

# Activer le démarrage automatique au login
systemctl --user enable nginx-web

# Activer le "lingering" pour que le service démarre au boot même sans session ouverte
# (nécessite sudo une seule fois)
sudo loginctl enable-linger $USER

La variable %h dans le chemin du volume est une directive systemd qui se résout automatiquement vers votre répertoire home. La directive :Z en fin de volume configure correctement les étiquettes SELinux sur les distributions qui l'utilisent (Fedora, RHEL) — à omettre sur Debian/Ubuntu où SELinux n'est généralement pas actif. Le fichier .container est volontairement minimaliste : Quadlet s'occupe de générer toute la verbosité systemd habituelle (ExecStartPre, ExecStop, TimeoutStopSec, etc.) de façon cohérente et maintenue par le projet Podman.

Étape 6 — podman-compose pour les utilisateurs Docker Compose

Si vous avez déjà des fichiers docker-compose.yml en production ou en développement, la migration vers Podman n'implique pas de les réécrire. podman-compose est un outil Python qui lit le format Docker Compose standard et l'exécute via Podman, bénéficiant ainsi de toutes les garanties rootless. Il couvre environ 90 % des cas d'usage Compose courants — services, réseaux, volumes, variables d'environnement, builds — avec quelques limitations sur les fonctionnalités récentes comme Compose Watch.

# Installation via pip (disponible aussi via apt/dnf selon la distribution)
pip3 install --user podman-compose

# S'assurer que ~/.local/bin est dans le PATH
export PATH="$HOME/.local/bin:$PATH"
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc

# Vérifier l'installation
podman-compose --version

# Utilisation — identique à docker-compose
# Dans le répertoire de votre projet avec docker-compose.yml :
podman-compose up -d        # Démarrer en arrière-plan
podman-compose ps           # Voir l'état des services
podman-compose logs -f      # Suivre les logs en temps réel
podman-compose down         # Arrêter et supprimer les conteneurs
podman-compose pull         # Mettre à jour les images

Pour la majorité des stacks classiques — WordPress + MariaDB, Node.js + Redis + PostgreSQL, ou une application Django standard — vos fichiers Compose existants fonctionneront sans modification. Les cas nécessitant une adaptation sont principalement ceux qui dépendent du socket Docker (- /var/run/docker.sock:/var/run/docker.sock, pattern courant dans Portainer, Watchtower ou Traefik). Dans ce cas, Podman expose son propre socket via $XDG_RUNTIME_DIR/podman/podman.sock et peut être configuré pour émuler le socket Docker — voir la documentation officielle sur podman system service.

Étape 7 — Migration depuis Docker : images, volumes, et configurations

La migration depuis Docker vers Podman est conçue pour être indolore dans la plupart des cas, mais quelques points méritent attention pour éviter les mauvaises surprises en production. Le principe fondamental est que Podman utilise le même format d'image OCI (Open Container Initiative) que Docker — toute image Docker Hub, GitHub Container Registry, ou registre privé est directement utilisable avec Podman sans conversion.

# Migrer les images Docker existantes vers Podman
# Option 1 : re-puller directement depuis le registre (recommandé)
podman pull docker.io/nginx:alpine
podman pull docker.io/postgres:16

# Option 2 : exporter depuis Docker et importer dans Podman
# (utile si l'image est locale sans tag sur un registre public)
docker save mon-app:latest | podman load

# Migrer les volumes Docker vers Podman
# Docker stocke ses volumes dans /var/lib/docker/volumes/
# Podman (rootless) stocke les siens dans ~/.local/share/containers/storage/volumes/
# Pour migrer un volume "db-data" :
podman volume create db-data
docker run --rm -v db-data:/source alpine tar -czf - /source \
  | podman run --rm -i -v db-data:/dest alpine tar -xzf - -C /dest --strip-components=1

# Vérifier la migration du volume
podman run --rm -v db-data:/data alpine ls /data

# Alias pratique pour une transition en douceur
# Ajouter dans ~/.bashrc ou ~/.bash_aliases :
alias docker=podman
alias docker-compose=podman-compose

Pour les configurations de déploiement comme les fichiers systemd générés avec l'ancienne commande docker generate systemd ou les scripts de démarrage utilisant dockerd, il faudra les réécrire avec Quadlet (Étape 5) — c'est l'occasion d'adopter une approche plus déclarative et maintenable. Les variables d'environnement passées via --env-file ou -e fonctionnent identiquement entre Docker et Podman. Les Dockerfile existants sont 100 % compatibles avec podman build — ou encore mieux avec buildah, l'outil de build dédié du même écosystème.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les développeurs et sysadmins en Afrique de l'Ouest, Podman rootless représente un avantage concret qui va bien au-delà de la simple mode technique. La réalité de l'hébergement dans notre région est celle de VPS mutualisés, souvent chez Hetzner (Helsinki ou Nuremberg, le plus accessible en rapport qualité-prix depuis le Sénégal, la Côte d'Ivoire ou le Mali), parfois chez des hébergeurs locaux comme DataCenter CI ou Orange Business. Sur ces machines, vous avez rarement un accès root complet, et les politiques de sécurité de l'hébergeur interdisent souvent l'installation de Docker en mode rootfull sur des VPS partagés.

Podman rootless s'installe et tourne entièrement dans votre espace utilisateur, sans nécessiter aucun privilège root permanent. Sur un Hetzner Cloud CX22 (2 vCPU, 4 Go RAM, 5,77 €/mois en 2026), vous pouvez déployer un stack complet — frontend, backend API, base de données — avec Podman rootless et Quadlet, sans jamais demander à votre hébergeur de modifier la configuration système. C'est un argument fort pour les freelances et les PME qui gèrent leur propre infrastructure.

L'alias alias docker=podman est particulièrement pertinent dans un contexte d'équipe : si vous formez des développeurs juniors à Dakar ou Abidjan qui ont appris Docker, ils continuent à utiliser leurs commandes habituelles sans friction. La transition est invisible pour eux, pendant que l'infrastructure bénéficie des garanties de sécurité de Podman. Cette approche pragmatique — adopter le meilleur outil sans imposer une courbe d'apprentissage — est caractéristique d'une bonne gestion technique dans des équipes à ressources limitées.

Du point de vue de la conformité OHADA et des audits de sécurité informatique pour les entreprises qui ont des obligations réglementaires (banques, assurances, opérateurs télécoms sous régulation ARCEP), l'absence de daemon root est un point positif documentable. Un rapport d'audit peut mentionner explicitement que l'infrastructure de conteneurs ne fait tourner aucun processus root persistant, réduisant la surface d'attaque systémique. C'est plus facile à défendre devant un auditeur qu'un Docker daemon tournant 24h/24 en root avec un socket Unix exposé. Pour les PME qui commencent à se structurer en vue de certifications ISO 27001 ou de conformité WAEMU/BCEAO, chaque réduction de surface d'attaque compte.

Concernant la bande passante, souvent limitée et coûteuse, Podman partage avec Docker les mêmes registres d'images (Docker Hub, GHCR, Quay.io) et bénéficie du même système de couches (layers) OCI. Une fois qu'une image de base comme alpine:3.20 est téléchargée, elle est réutilisée pour tous vos conteneurs. Avec Podman, les images sont stockées par utilisateur, ce qui peut sembler une duplication, mais en pratique sur un VPS mono-utilisateur dédié au déploiement, c'est non-significatif.

Tutoriels frères

• Buildah : construire des images OCI sans Docker ni daemon — tutoriel 2026 — le pendant build de Podman : créez des images OCI en rootless, sans Dockerfile si vous le souhaitez, avec un contrôle total couche par couche.
• Images distroless : conteneurs ultra-légers et sécurisés pour la production — réduisez la surface d'attaque de vos images en éliminant le shell et les utilitaires système, compatible Podman et Buildah.

Pour aller plus loin

• Retour au guide général : Containers sans Docker : Podman, Buildah, distroless (2026) — vue d'ensemble du cluster et liens vers tous les tutoriels.
• Documentation officielle Podman : docs.podman.io — référence complète, man pages, tutoriels officiels.
• Tutorial rootless officiel : github.com/containers/podman — rootless_tutorial.md
• Documentation Quadlet : podman-systemd.unit(5) — référence complète des directives Quadlet.
• Étape suivante recommandée : après maîtrise du mode rootless, explorez Buildah pour construire vos propres images de production optimisées.

FAQ

Q : Podman rootless est-il vraiment aussi sécurisé qu'on le dit, ou c'est du marketing ?

R : C'est une amélioration de sécurité réelle et documentée. En mode rootless, le processus conteneurisé ne peut jamais obtenir de privilèges supérieurs à votre utilisateur Linux courant, même en cas de faille de sécurité dans le runtime. Avec Docker rootfull, une évasion de conteneur donne un accès root complet à la machine hôte. La différence n'est pas théorique — des CVE Docker critiques (comme CVE-2019-5736 sur runc) auraient été non-exploitables en configuration rootless. La surface d'attaque est structurellement réduite.

Q : Puis-je utiliser Podman et Docker en parallèle sur la même machine ?

R : Oui, sans conflit. Podman rootless stocke ses données dans votre home (~/.local/share/containers/) et Docker dans /var/lib/docker/. Ils n'interfèrent pas. L'alias docker=podman est utilisateur-local, donc Docker reste disponible pour les outils système qui en ont besoin. En pratique, la cohabitation est courante pendant la phase de migration.

Q : Quadlet remplace-t-il définitivement podman generate systemd ?

R : Oui, podman generate systemd est officiellement déprécié depuis Podman 4.4 et ne recevra plus de nouvelles fonctionnalités — uniquement des corrections de bugs critiques jusqu'à sa suppression. Le projet Podman recommande explicitement Quadlet pour tous les nouveaux déploiements. Les fichiers .container Quadlet sont plus lisibles, maintenables et alignés sur l'approche déclarative qui facilite aussi la migration vers Kubernetes.

Q : podman-compose peut-il remplacer Docker Compose à 100 % en production ?

R : Pour les stacks courants (90 % des cas), oui. Les limitations connues en 2026 concernent Compose Watch (rechargement à chaud), certaines options de healthcheck avancées, et les profils Compose. Pour les stacks simples à moyennement complexes utilisés par les PME (WordPress, applications Node/Python/PHP + base de données + cache), la compatibilité est très bonne. Pour des stacks complexes avec des fonctionnalités Compose avancées, tester en staging avant de migrer en production.

Q : Comment exposer le port 80 en production avec Podman rootless ?

R : L'approche la plus propre est d'utiliser un reverse proxy (Nginx, Caddy, Traefik) installé en dehors des conteneurs Podman, qui écoute sur le port 80/443 avec les permissions adéquates et proxifie vers votre conteneur Podman sur un port > 1024. C'est aussi l'architecture recommandée pour gérer les certificats TLS (Let's Encrypt via Certbot ou Caddy automatique). Autre option : sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80 pour permettre aux utilisateurs non-root d'utiliser le port 80, à rendre permanent via /etc/sysctl.d/.

Q : Podman fonctionne-t-il sur les distributions légères courantes en Afrique de l'Ouest (Ubuntu minimal, Debian Lite) ?

R : Oui, parfaitement. Podman est disponible dans les dépôts officiels d'Ubuntu 24.04 et Debian 12. Sur Ubuntu 22.04 (encore très répandu sur les VPS anciens), le dépôt Kubic donne accès à Podman 5.x. La seule dépendance système notable est passt (fournissant la commande pasta) pour le réseau rootless — environ 500 Ko, installé automatiquement comme dépendance sur la plupart des distributions récentes. Sur une machine avec 1 Go de RAM, Podman rootless tourne très bien pour des charges légères à moyennes.