🐳 Masterclass Podman — WordPress Rootless sur Fedora / RHEL / Rocky Linux

Durée estimée : 1 heure Niveau : Administrateur Linux intermédiaire Distribution cible : Fedora 39+ / RHEL 9 / Rocky Linux 9

Sommaire

Concepts fondamentaux
Prérequis et installation
Préparer les volumes persistants
Créer et démarrer le Pod WordPress
Vérification et accès à WordPress
Démarrage automatique avec systemd (Quadlet)
Comparaison avec podman-compose
Aide-mémoire des commandes

1. Concepts fondamentaux

1.1 Podman vs Docker — les différences clés

Podman est un moteur de conteneurs daemonless (sans démon central). Là où Docker exige un service dockerd tournant en root en permanence, Podman exécute chaque conteneur comme un processus enfant direct de l'utilisateur qui l'a lancé.

Docker :   shell → dockerd (root) → containerd → runc → conteneur
Podman :   shell → podman → conmon → runc → conteneur

Conséquences concrètes :

Pas de single point of failure (pas de daemon)
Chaque conteneur s'exécute avec les droits de l'utilisateur appelant
Intégration naturelle avec systemd via le modèle fork/exec
Compatible avec les images OCI (même format que Docker)

1.2 Conteneurs Rootless vs Rootfull — concepts et sécurité

Le mode Rootfull — comment ça marche et pourquoi c'est risqué

En mode rootfull, le processus Podman (ou le daemon Docker) s'exécute avec les privilèges root sur l'hôte. Le conteneur partage le même user namespace que l'hôte : l'UID 0 à l'intérieur du conteneur est l'UID 0 sur l'hôte.

MODE ROOTFULL
─────────────────────────────────────────────────────────
  Hôte                          Conteneur
  UID 0 (root)      ═══════►    UID 0 (root)
  UID 1000 (user)   ═══════►    UID 1000

  → Processus dans le conteneur = processus root sur l'hôte
  → Accès complet au système de fichiers hôte si mal configuré
  → Accès aux appels système kernel sans filtre supplémentaire
─────────────────────────────────────────────────────────

La conséquence directe : si un attaquant exploite une vulnérabilité dans le conteneur et parvient à en sortir (container escape), il obtient un shell root sur l'hôte. L'isolation repose entièrement sur la robustesse du runtime (runc, crun) et du kernel. Un seul maillon faible suffit à compromettre toute la machine.

C'est exactement le modèle de Docker dans sa configuration par défaut : le daemon dockerd tourne en root, et l'appartenance au groupe docker est techniquement équivalente à avoir sudo sans mot de passe.

Le mode Rootless — l'isolation par les user namespaces

Un conteneur rootless s'exécute dans un user namespace dédié. Le noyau Linux crée un espace d'identifiants isolé dans lequel l'UID 0 à l'intérieur du conteneur est mappé sur un UID non-privilégié sur l'hôte, selon une table de correspondance définie par /etc/subuid et /etc/subgid.

MODE ROOTLESS
─────────────────────────────────────────────────────────
  Hôte                          Conteneur
  UID 1001 (monuser)  ════►    UID 0 (root apparent)
  UID 101001          ════►    UID 1000
  UID 101002          ════►    UID 1001
  ...                          ...
  UID 166536          ════►    UID 65535

  → "root" dans le conteneur = utilisateur ordinaire sur l'hôte
  → Container escape → attaquant obtient UID 1001 sur l'hôte
  → Aucun accès root réel sur l'hôte
─────────────────────────────────────────────────────────

Le fichier /etc/subuid définit la plage d'UIDs subordonnés autorisée pour chaque utilisateur :

# Vérifier la configuration subuid/subgid
cat /etc/subuid
# monuser:100000:65536
# └─────┘ └─────┘ └───┘
# user   début   taille de la plage

cat /etc/subgid
# monuser:100000:65536

# Vérifier le mapping actif dans un conteneur qui tourne
podman unshare cat /proc/self/uid_map
#          0       1001          1   ← UID 0 conteneur = UID 1001 hôte
#          1     100000      65536   ← UID 1-65535 conteneur = UID 100000+ hôte

Tableau comparatif complet

Critère	Rootfull	Rootless
Processus Podman	S'exécute en root	S'exécute en utilisateur
UID 0 dans le conteneur	= root réel sur l'hôte	= UID non-privilégié sur l'hôte
Container escape	→ shell root hôte	→ shell utilisateur ordinaire
Accès aux ports < 1024	✅ Oui (root peut tout)	❌ Non (voir section limitations)
Accès aux devices `/dev`	✅ Plus facile	⚠️ Restreint
Linux Capabilities	Toutes disponibles	Sous-ensemble uniquement
Réseau	netavark (bridge natif)	pasta (default Podman 5+)
Surface d'attaque	Élevée	Réduite
Adapté production	Avec précautions	✅ Recommandé (RHEL, ANSSI)
Stockage images	`/var/lib/containers/`	`~/.local/share/containers/`

Les mécanismes de sécurité additionnels en rootless

Le user namespace n'est que la première couche. En mode rootless sur Fedora/RHEL, plusieurs mécanismes s'empilent :

1. SELinux (Mandatory Access Control) Chaque conteneur reçoit automatiquement un label SELinux container_t. Même si un processus sort du conteneur, les règles SELinux limitent ce qu'il peut faire sur l'hôte. Les volumes montés avec :Z reçoivent un label privé svirt_sandbox_file_t.

On peut le démontrer en live avec un conteneur éphémère :

# Lancer un conteneur éphémère en arrière-plan
podman run -d --rm --name test-selinux docker.io/library/alpine sleep 60

# Inspecter son label SELinux
podman inspect test-selinux --format '{{.ProcessLabel}}'
# system_u:system_r:container_t:s0:c234,c789

# Voir le label depuis le processus lui-même côté hôte
cat /proc/$(podman inspect test-selinux --format '{{.State.Pid}}')/attr/current
# system_u:system_r:container_t:s0:c234,c789

# Comparer avec le processus shell courant sur l'hôte
cat /proc/self/attr/current
# unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

# Nettoyer
podman stop test-selinux

Ce que ça montre :

container_t — type SELinux dédié aux conteneurs, distinct de tous les types système
s0:c234,c789 — deux catégories MCS (Multi-Category Security) générées aléatoirement à chaque démarrage. Deux conteneurs n'ont jamais les mêmes catégories, ce qui les empêche d'accéder mutuellement à leurs fichiers même s'ils tournent sous le même UID
La comparaison avec unconfined_t sur l'hôte rend la différence immédiatement visible : même si un attaquant sort du conteneur, SELinux refuse toute action hors du domaine container_t avant même que les permissions Unix entrent en jeu

2. Seccomp (Secure Computing Mode) Podman applique par défaut un profil seccomp qui filtre les appels système dangereux (ex. ptrace, mount, reboot). Un conteneur rootless ne peut pas appeler ces syscalls même s'il croit être root.

3. Linux Capabilities En rootless, les capabilities disponibles dans le conteneur sont un sous-ensemble très restreint. CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE sont notamment absentes par défaut.

# Vérifier les capabilities effectives dans un conteneur rootless
podman run --rm docker.io/library/alpine cat /proc/self/status | grep Cap
# CapEff: 00000000800405fb   ← sous-ensemble limité

Le réseau en rootless — pasta et ses implications

En mode rootless, un utilisateur non-privilégié ne peut pas créer d'interfaces réseau réelles sur l'hôte. Podman utilise donc un backend réseau en espace utilisateur.

Depuis Podman 5.0 (et RHEL 9.5), le backend par défaut est pasta (Pack A Subtle Tap Abstraction), successeur de slirp4netns. Pasta crée un namespace réseau isolé et fait transiter le trafic sans toucher aux interfaces réseau de l'hôte.

RÉSEAU ROOTLESS (pasta)
─────────────────────────────────────────────────
  Hôte (eth0: 192.168.1.10)
      │
      │  pasta (espace utilisateur)
      │  ├── copie l'adresse IP de l'hôte dans le namespace
      │  └── redirige le trafic sans NAT
      │
  Namespace réseau du conteneur
      └── interface réseau virtuelle (même IP que l'hôte)
─────────────────────────────────────────────────
RÉSEAU ROOTFULL (netavark)
─────────────────────────────────────────────────
  Hôte (eth0: 192.168.1.10)
      │
      │  netavark (bridge kernel)
      │
  Interface bridge podman0 (10.88.0.1/16)
      └── veth → conteneur (10.88.0.2)
─────────────────────────────────────────────────

Limitation clé : les ports privilégiés (< 1024)

Le noyau Linux interdit aux processus sans CAP_NET_BIND_SERVICE d'écouter sur les ports inférieurs à 1024 (ports dits "privilégiés" : 80, 443, 22...). En rootless, cette restriction s'applique.

C'est pour cette raison que nous utilisons le port 8088 dans ce tutoriel : aucune configuration supplémentaire n'est nécessaire.

# Vérifier le seuil des ports non-privilégiés sur votre système
cat /proc/sys/net/ipv4/ip_unprivileged_port_start
# 1024  (valeur par défaut)

# Si vous avez besoin d'exposer le port 443 en rootless (ex. avec un reverse proxy),
# il est possible d'abaisser ce seuil (modification system-wide, impacte tous les utilisateurs) :
# /etc/sysctl.d/99-podman-rootless.conf
# net.ipv4.ip_unprivileged_port_start=443
# sudo sysctl --system

# Solution recommandée en production : utiliser un reverse proxy (Nginx, Traefik, Caddy)
# en amont qui écoute sur 80/443 et proxy vers votre port non-privilégié.

Pourquoi rootless est la recommandation officielle Red Hat / ANSSI

Le mode rootless est un principe universel de sécurité, applicable à toute mise en production quel que soit le runtime. Red Hat le recommande pour tous les déploiements Podman sur RHEL 9. Cette approche s'aligne avec les principes de défense en profondeur préconisés par l'ANSSI dans ses guides de sécurisation des conteneurs :

Principe du moindre privilège : aucun processus conteneur ne détient de privilèges root réels sur l'hôte
Réduction de la surface d'attaque : un container escape ne compromet que le compte utilisateur, pas la machine
Isolation multi-couches : user namespaces + SELinux + seccomp + capabilities réduites
Auditabilité : les processus conteneurs apparaissent avec l'UID de l'utilisateur dans les logs système (journalctl, ps, auditd), ce qui facilite la traçabilité

Règle à appliquer pour toute mise en production : rootless par défaut, rootfull uniquement si une contrainte technique l'impose — et dans ce cas, documentée et justifiée.

Docker rootless — possible, mais non activé par défaut

Docker supporte lui aussi le mode rootless depuis la version 20.10 (décembre 2020). Le mécanisme est identique : le daemon dockerd et les conteneurs s'exécutent dans un user namespace, l'UID 0 du conteneur est mappé sur un UID non-privilégié de l'hôte via /etc/subuid.

# Activation du mode rootless Docker (à faire manuellement, non activé par défaut)
dockerd-rootless-setuptool.sh install

# Démarrage du daemon rootless via systemd utilisateur
systemctl --user enable --now docker.service
sudo loginctl enable-linger $USER

# Vérification
docker info | grep rootless
# rootless: true

Cependant, Docker rootless présente des différences structurelles importantes avec Podman rootless :

Critère	Podman rootless	Docker rootless
Activé par défaut	✅ Oui	❌ Non, opt-in manuel
Daemon persistent	❌ Aucun daemon	✅ `dockerd` en mode user
Single point of failure	❌ Aucun	⚠️ Le daemon user peut planter
Socket exposé	Aucun par défaut	`$XDG_RUNTIME_DIR/docker.sock`
Docker Swarm	N/A	❌ Non supporté en rootless
Intégration systemd	✅ Native (Quadlet)	⚠️ Manuelle
SELinux	✅ Natif RHEL/Fedora	⚠️ Non supporté sur RHEL

Le point critique : en Docker rootfull (configuration par défaut de la majorité des déploiements), le socket /var/run/docker.sock expose une surface d'attaque root permanente. Avoir accès à ce socket — que ce soit via un conteneur mal configuré ou un utilisateur du groupe docker — équivaut à disposer d'un accès root total sur la machine hôte, sans mot de passe sudo.

# Démonstration du risque Docker rootfull :
# Un conteneur avec accès au socket peut monter le système de fichiers hôte en root
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
  docker sh -c "docker run --rm -v /:/host alpine chroot /host id"
# uid=0(root) gid=0(root) — root sur l'hôte, depuis un conteneur

⚠️ Cette commande est fournie à titre pédagogique uniquement pour illustrer le risque. Ne jamais monter le socket Docker dans un conteneur en production.

1.3 Les Pods Podman

Un Pod Podman s'inspire directement des Pods Kubernetes. C'est un groupe de conteneurs qui partagent :

Le même namespace réseau (ils se voient via localhost)
Le même espace IPC (Inter-Process Communication)
Optionnellement le même espace PID

Chaque pod contient automatiquement un conteneur infra (aussi appelé pause container). Ce conteneur léger existe uniquement pour maintenir les namespaces actifs pendant toute la durée de vie du pod. Les autres conteneurs rejoignent ces namespaces partagés.

┌─────────────────────── POD wp-blog ───────────────────────┐
│  ┌──────────────┐   ┌──────────────┐   ┌──────────────┐  │
│  │ infra        │   │ mariadb      │   │ wordpress    │  │
│  │ (pause)      │   │              │   │              │  │
│  └──────────────┘   └──────────────┘   └──────────────┘  │
│         │                  │                  │           │
│         └──────── réseau partagé (localhost) ─┘           │
│                    port 8088 exposé vers l'hôte            │
└───────────────────────────────────────────────────────────┘

L'avantage : WordPress parle à MariaDB via 127.0.0.1 au lieu d'un nom de réseau. Pas besoin de réseau inter-conteneurs complexe.

1.4 Volumes nommés vs bind mounts

Deux approches pour la persistance :

Critère	Volume nommé (`podman volume`)	Bind mount (`-v /chemin/hôte:/chemin/ctr`)
Gestion	Podman gère le répertoire	Vous gérez le répertoire
Localisation	`~/.local/share/containers/storage/volumes/`	Où vous voulez
Droits rootless	Podman ajuste automatiquement	À configurer manuellement
SELinux	Géré automatiquement	Nécessite `:Z` ou `:z`
Backup	`podman volume export`	`tar` classique

Dans ce tutoriel, nous utilisons des volumes nommés : Podman gère lui-même les droits dans le user namespace, ce qui évite les problèmes de permissions en mode rootless.

1.5 L'option `--rm` et la philosophie des conteneurs éphémères

L'option --rm supprime automatiquement le conteneur lorsqu'il s'arrête. Cela s'applique ici au niveau de la commande podman run, mais attention : avec des pods, on préférera la recréation propre via systemd.

Pour les pods, l'équivalent est podman pod rm après podman pod stop.

2. Prérequis et installation

2.1 Vérifier Podman

Sur Fedora/RHEL 9/Rocky 9, Podman est disponible dans les dépôts officiels via le méta-paquet container-tools.

# Installer les outils conteneurs
sudo dnf install -y podman podman-compose buildah skopeo

# Vérifier la version (>= 4.4 requis pour Quadlet)
podman --version
# Exemple : podman version 4.9.4

# Vérifier que cgroups v2 est actif (requis pour rootless)
cat /sys/fs/cgroup/cgroup.controllers
# Doit afficher : cpuset cpu io memory hugetlb pids rdma misc

2.2 Vérifier la configuration rootless

# Vérifier les subuid/subgid (doit exister pour votre utilisateur)
grep $USER /etc/subuid /etc/subgid

# Si absent, configurer :
sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 $USER

# Vérifier l'état de Podman en mode utilisateur
podman info --format '{{.Host.Security}}'
# rootless: true doit apparaître

2.3 Créer les volumes nommés

Pourquoi créer les volumes manuellement ? Podman crée automatiquement un volume nommé au premier podman run qui le référence — podman volume create n'est pas obligatoire. On le fait ici explicitement pour rendre l'intention visible, pouvoir inspecter le chemin physique et le label SELinux avant tout lancement, et détecter une faute de frappe tôt plutôt que de laisser Podman créer silencieusement un volume avec le mauvais nom. En environnement automatisé ou avec Quadlet, laisser Podman créer les volumes à la volée est tout à fait acceptable.

# Créer les deux volumes qui persisteront les données
podman volume create wp_data
podman volume create mysql_data

# Vérifier leur création et localisation
podman volume ls
podman volume inspect wp_data
# Affiche le chemin réel : ~/.local/share/containers/storage/volumes/wp_data/_data/

3. Préparer les volumes persistants

3.1 Pourquoi deux volumes séparés ?

mysql_data : contient les fichiers de base de données MySQL (/var/lib/mysql). Persiste toutes les données du site même si les conteneurs sont supprimés.
wp_data : contient les fichiers WordPress (/var/www/html), y compris les thèmes, plugins et uploads.

3.2 Vérifier l'accessibilité SELinux

Sur Fedora/RHEL, SELinux est actif par défaut. Les volumes nommés Podman reçoivent automatiquement le contexte container_file_t. Vous pouvez le vérifier :

# Inspecter le chemin physique du volume
MYSQL_VOL_PATH=$(podman volume inspect mysql_data --format '{{.Mountpoint}}')
ls -laZ "$MYSQL_VOL_PATH"
# Doit afficher : system_u:object_r:container_file_t:s0

Avec les volumes nommés, aucune manipulation semanage manuelle n'est nécessaire — Podman s'en charge.

4. Créer et démarrer le Pod WordPress

Nous allons procéder en trois étapes :

Créer le pod avec la configuration réseau
Lancer MariaDB dans le pod
Lancer WordPress dans le pod

4.1 Créer le pod

podman pod create \
  --name wp-blog \
  --publish 8088:80

Explication des options :

--name wp-blog : nomme le pod pour y faire référence facilement
--publish 8088:80 : expose le port 80 du pod sur le port 8088 de l'hôte (port non-standard pour éviter les conflits). Important : les mappings de ports se définissent au niveau du pod, pas des conteneurs.

# Vérifier la création du pod
podman pod ps
# POD ID       NAME      STATUS   CREATED   INFRA ID      # OF CONTAINERS
# abc123...    wp-blog   Created  1s ago    def456...     1

Le pod contient déjà 1 conteneur : le conteneur infra (pause).

4.2 Lancer le conteneur MariaDB

podman run -d \
  --pod wp-blog \
  --name wp-mysql \
  --rm \
  -e MYSQL_ROOT_PASSWORD=R00tS3cur3Pass! \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=wpuser \
  -e MYSQL_PASSWORD=WpS3cur3Pass! \
  -v mysql_data:/var/lib/mysql \
  docker.io/library/mariadb:11

Explication des options :

--pod wp-blog : attache ce conteneur au pod (il rejoint le namespace réseau partagé)
--rm : le conteneur sera supprimé automatiquement à l'arrêt
-e : variables d'environnement passées au conteneur (configuration MariaDB)
-v mysql_data:/var/lib/mysql : monte le volume nommé sur le répertoire des données MySQL
docker.io/library/mariadb:11 : image officielle MariaDB, version fixée (évite les surprises en production)

⚠️ Sécurité : Dans un contexte de production, utilisez podman secret pour gérer les mots de passe. Ici on simplifie pour la pédagogie.

# Attendre que MariaDB soit prêt (environ 30 secondes)
podman logs -f wp-mysql
# Chercher : "ready for connections" dans les logs
# Ctrl+C pour quitter les logs

4.3 Lancer le conteneur WordPress

podman run -d \
  --pod wp-blog \
  --name wp-app \
  --rm \
  -e WORDPRESS_DB_HOST=127.0.0.1:3306 \
  -e WORDPRESS_DB_USER=wpuser \
  -e WORDPRESS_DB_PASSWORD=WpS3cur3Pass! \
  -e WORDPRESS_DB_NAME=wordpress \
  -v wp_data:/var/www/html \
  docker.io/library/wordpress:latest

Point clé — WORDPRESS_DB_HOST="127.0.0.1:3306" : puisque WordPress et MariaDB partagent le même namespace réseau dans le pod, MariaDB est accessible sur 127.0.0.1 (localhost du pod). C'est une différence fondamentale avec Docker Compose où les services communiquent via leur nom de service sur un réseau virtuel dédié.

5. Vérification et accès à WordPress

5.1 Vérifier l'état du pod et des conteneurs

# Vue d'ensemble du pod
podman pod ps
# POD ID       NAME      STATUS    CREATED   INFRA ID      # OF CONTAINERS
# abc123...    wp-blog   Running   2m ago    def456...     3

# Détail des conteneurs dans le pod
podman ps --pod
# CONTAINER ID  IMAGE                           COMMAND               STATUS         NAMES          POD ID
# xxx...        localhost/podman-pause:latest                         Up 2 min       wp-blog-infra  abc123
# yyy...        docker.io/library/mariadb:11     mariadbd                Up 90 sec      wp-mysql       abc123
# zzz...        docker.io/library/wordpress...  apache2-foreground    Up 60 sec      wp-app         abc123

# Consulter les logs d'un conteneur spécifique
podman logs wp-mysql
podman logs wp-app

5.2 Accéder à WordPress

Ouvrir un navigateur et accéder à :

http://localhost:8088

Ou depuis une machine distante :

http://<IP_DU_SERVEUR>:8088

Si vous êtes derrière un pare-feu (firewalld sur RHEL/Fedora) :
sudo firewall-cmd --add-port=8088/tcp --permanent
sudo firewall-cmd --reload

L'installeur WordPress doit apparaître. Renseignez :

Titre du site
Nom d'utilisateur administrateur
Mot de passe admin
Email

5.3 Tester la persistance des données

# Stopper le pod (les conteneurs avec --rm sont supprimés automatiquement)
podman pod rm -f wp-blog

# Vérifier que les conteneurs ont été supprimés (--rm)
podman ps -a
# wp-mysql et wp-app ne doivent plus apparaître
# Le conteneur infra du pod lui existe toujours

# Vérifier que les volumes sont toujours là
podman volume ls
# local   mysql_data   ← données préservées
# local   wp_data      ← fichiers WordPress préservés

L'effet de --rm expliqué

--rm demande à Podman de supprimer le conteneur dès qu'il s'arrête. Ce qui est supprimé : le conteneur lui-même (son système de fichiers en couches, ses métadonnées, son ID). Ce qui n'est pas supprimé : les volumes nommés — ils ont un cycle de vie indépendant des conteneurs qui les utilisent.

C'est la distinction fondamentale entre deux couches :

Couche conteneur  → éphémère  → supprimée avec --rm
Couche volume     → persistante → survit à l'arrêt et à la suppression du conteneur

Recréer les conteneurs est rapide car les images sont déjà présentes localement — Podman ne les re-télécharge pas. Seul le conteneur (la couche d'exécution) est recréé, les données dans les volumes sont intactes.

podman pod rm -f  wp-blog 
# Recréer le conteneur MariaDB — démarrage quasi-instantané (image en cache)

podman pod create \
  --name wp-blog \
  --publish 8088:80

podman run -d \
  --pod wp-blog \
  --name wp-mysql \
  --rm \
  -e MYSQL_ROOT_PASSWORD=R00tS3cur3Pass! \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=wpuser \
  -e MYSQL_PASSWORD=WpS3cur3Pass! \
  -v mysql_data:/var/lib/mysql \
  docker.io/library/mariadb:11

# MariaDB démarre plus vite au second lancement :
# les fichiers de base de données existent déjà dans le volume,
# il n'y a pas d'initialisation à faire — juste un démarrage normal
podman logs -f wp-mysql
# Chercher : "ready for connections" — apparaît bien plus vite qu'au premier lancement

# Recréer le conteneur WordPress
podman run -d \
  --pod wp-blog \
  --name wp-app \
  --rm \
  -e WORDPRESS_DB_HOST=127.0.0.1:3306 \
  -e WORDPRESS_DB_USER=wpuser \
  -e WORDPRESS_DB_PASSWORD=WpS3cur3Pass! \
  -e WORDPRESS_DB_NAME=wordpress \
  -v wp_data:/var/www/html \
  docker.io/library/wordpress:latest

# Vérifier que les deux conteneurs sont de nouveau actifs
podman ps --pod

Accéder à http://localhost:8088 — WordPress s'affiche directement avec le site déjà configuré, sans passer par l'installeur. La preuve que les données ont survécu.

Note sur --rm et les pods : --rm signifie que le conteneur est effacé à l'arrêt. Les volumes eux ne sont pas supprimés. C'est la distinction essentielle entre la couche conteneur (éphémère) et la couche données (persistante). C'est pourquoi dans la section suivante, nous passerons à Quadlet qui gère le cycle de vie complet de manière déclarative.

5.4 Nettoyage manuel (si nécessaire)

# Arrêter et supprimer le pod et tous ses conteneurs
podman pod rm -f wp-blog

# Supprimer les volumes si on veut repartir de zéro (DESTRUCTIF)
podman volume rm mysql_data wp_data

6. Démarrage automatique avec systemd (Quadlet)

6.1 Pourquoi Quadlet plutôt que `podman generate systemd` ?

podman generate systemd est déprécié depuis Podman 4.4. La documentation officielle recommande d'utiliser Quadlet pour toute gestion de conteneurs sous systemd.

Quadlet est un générateur systemd intégré à Podman depuis la version 4.4. Il lit des fichiers déclaratifs (.container, .pod, .volume, .network) placés dans ~/.config/containers/systemd/ et génère automatiquement des units systemd au démarrage du système, via le mécanisme des systemd generators.

Fichiers Quadlet           systemd generator          Units systemd
~/.config/containers/  →  /usr/libexec/podman/  →   services gérables
systemd/*.container        quadlet                    par systemctl

Les avantages par rapport à generate systemd :

Déclaratif : on décrit l'état souhaité, pas les commandes
Pas de dérive : modifier le fichier Quadlet et faire daemon-reload suffit
Evolutions automatiques : quand Podman ajoute des fonctionnalités, les units générées en profitent sans regénération manuelle
Géré par Red Hat comme approche officielle dans RHEL 9+

6.2 User Lingering — permettre le démarrage sans session

Par défaut, systemd détruit la session utilisateur (et tous ses services) quand l'utilisateur se déconnecte. Le user lingering demande à systemd de maintenir la session utilisateur active même sans connexion ouverte, et de la démarrer automatiquement au boot.

# Activer le lingering pour votre utilisateur (commande à exécuter en tant que root)
sudo loginctl enable-linger $USER

# Vérifier
loginctl show-user $USER | grep Linger
# Linger=yes

Sans cette étape, vos conteneurs s'arrêteraient à la déconnexion SSH.

6.3 Structure des fichiers Quadlet

Nous allons créer 4 fichiers Quadlet :

~/.config/containers/systemd/
├── wp-blog.pod          # Définition du pod
├── wp-volumes.volume    # Volume mysql_data (optionnel, déclaratif)
├── wp-mysql.container   # Conteneur MySQL
└── wp-app.container     # Conteneur WordPress

6.4 Créer le répertoire Quadlet

mkdir -p ~/.config/containers/systemd

Pour aller plus loin : l'outil podlet génère automatiquement des fichiers Quadlet depuis une commande podman run ou un docker-compose.yml. Utile une fois les concepts maîtrisés — à explorer après la masterclass. Documentation et sources : https://github.com/containers/podlet

Par exemple, la commande MariaDB vue en section 4.2 peut être convertie en fichier Quadlet en une seule ligne — il suffit de préfixer podlet devant podman :

# Installation via cargo (Rust requis)
cargo install podlet

# create the directory
mkdir ~/.config/containers/systemd/

# Générer le fichier wp-mysql.container depuis la commande podman run
~/.cargo/bin/podlet --unit-directory podman run -d \                                                                                                                                                                                                                              1 ↵
  --pod wp-blog \
  --name wp-mysql \
  -e MYSQL_ROOT_PASSWORD=R00tS3cur3Pass! \
  -e MYSQL_DATABASE=wordpress \
  -e MYSQL_USER=wpuser \
  -e MYSQL_PASSWORD=WpS3cur3Pass! \
  -v mysql_data:/var/lib/mysql \
  docker.io/library/mariadb:11


# Résultat écrit automatiquement dans :
# ~/.config/containers/systemd/wp-mysql.container
# Le fichier généré est à relire et compléter (After=, Requires=, etc.)
# avant de l'activer avec systemctl --user daemon-reload

6.5 Fichier `wp-blog.pod`

Ce fichier déclare le pod et son exposition réseau.

cat > ~/.config/containers/systemd/wp-blog.pod << 'EOF'
[Unit]
Description=Pod WordPress Blog

[Pod]
PodName=wp-blog
PublishPort=8088:80

[Install]
WantedBy=default.target
EOF

Explication des sections :

[Unit] : section systemd standard (description, dépendances)
[Pod] : section spécifique Quadlet pour la configuration du pod
PublishPort : équivalent du --publish de podman pod create
[Install] avec WantedBy=default.target : active le service au boot. Pour les conteneurs rootless, on utilise default.target et non multi-user.target (qui ne fonctionne pas en mode user).

6.6 Fichier `wp-mysql.container`

cat > ~/.config/containers/systemd/wp-mysql.container << 'EOF'
[Unit]
Description=MariaDB pour WordPress
After=wp-blog-pod.service
Requires=wp-blog-pod.service

[Container]
Image=docker.io/library/mariadb:11
ContainerName=wp-mysql
Pod=wp-blog.pod

Environment=MYSQL_ROOT_PASSWORD=R00tS3cur3Pass!
Environment=MYSQL_DATABASE=wordpress
Environment=MYSQL_USER=wpuser
Environment=MYSQL_PASSWORD=WpS3cur3Pass!

Volume=mysql_data:/var/lib/mysql

[Service]
Restart=always
TimeoutStartSec=120

[Install]
WantedBy=default.target
EOF

Explication :

After=wp-blog-pod.service / Requires=wp-blog-pod.service : MariaDB ne démarre qu'après que le pod infra soit actif. Quadlet génère un service wp-blog-pod.service pour le pod.
Pod=wp-blog.pod : lie ce conteneur au pod déclaré dans wp-blog.pod
TimeoutStartSec=120 : MariaDB peut mettre du temps à s'initialiser (écriture des fichiers DB au premier lancement), on lui donne 2 minutes

6.7 Fichier `wp-app.container`

cat > ~/.config/containers/systemd/wp-app.container << 'EOF'
[Unit]
Description=WordPress Application
After=wp-mysql.service
Requires=wp-mysql.service

[Container]
Image=docker.io/library/wordpress:latest
ContainerName=wp-app
Pod=wp-blog.pod

Environment=WORDPRESS_DB_HOST=127.0.0.1:3306
Environment=WORDPRESS_DB_USER=wpuser
Environment=WORDPRESS_DB_PASSWORD=WpS3cur3Pass!
Environment=WORDPRESS_DB_NAME=wordpress

Volume=wp_data:/var/www/html

AutoUpdate=registry

[Service]
Restart=always
TimeoutStartSec=120

[Install]
WantedBy=default.target
EOF

Point notable — AutoUpdate=registry : Podman peut vérifier automatiquement si une nouvelle image est disponible dans le registry. Avec podman auto-update, il mettra à jour les conteneurs ayant ce label. C'est une fonctionnalité unique à Podman, sans équivalent natif dans Docker (qui nécessite des outils tiers comme Watchtower).

6.8 Activer et démarrer les services

# Recharger systemd pour qu'il lise les nouveaux fichiers Quadlet
systemctl --user daemon-reload

# Vérifier que les units ont bien été générés
systemctl --user list-unit-files | grep wp
# wp-blog-pod.service    generated
# wp-mysql.service       generated
# wp-app.service         generated

# Démarrer le pod (les conteneurs démarrent en cascade)
systemctl --user start wp-blog-pod.service

# Vérifier le statut
systemctl --user status wp-blog-pod.service
systemctl --user status wp-mysql.service
systemctl --user status wp-app.service

# Consulter les logs
journalctl --user -u wp-mysql.service -f
journalctl --user -u wp-app.service -f

6.9 Accéder à WordPress avec Quadlet

http://localhost:8088

Le service démarrera automatiquement à chaque boot de la machine, sans aucune connexion nécessaire (grâce au lingering).

6.10 Vérifier le démarrage automatique

# Simuler un reboot (sans redémarrer réellement)
systemctl --user stop wp-app.service wp-mysql.service wp-blog-pod.service

# Attendre quelques secondes, puis vérifier
sleep 5
systemctl --user status wp-blog-pod.service
# Si WantedBy=default.target est bien configuré, il devrait redémarrer

# Pour confirmer le comportement au vrai boot
sudo reboot
# Après redémarrage, se reconnecter et vérifier
systemctl --user status wp-blog-pod.service

7. Comparaison avec podman-compose

7.1 Qu'est-ce que podman-compose ?

podman-compose est une implémentation Python de Docker Compose utilisant Podman comme backend. Il lit les fichiers docker-compose.yml standards et les exécute avec Podman, offrant une compatibilité quasi-totale sans modifier les fichiers Compose.

# Installation (Fedora/RHEL)
sudo dnf install -y podman-compose
# Ou via pip
pip3 install --user podman-compose

7.2 Le fichier docker-compose.yml officiel de podman-compose

Le dépôt officiel containers/podman-compose sur GitHub inclut un exemple WordPress : https://github.com/containers/podman-compose/blob/main/examples/wordpress/docker-compose.yaml

Voici un fichier docker-compose.yml adapté de cet exemple, avec MariaDB et le port 8088.

Plutôt que de coller le contenu à la main dans nano, on le crée directement avec un heredoc — cela évite tout problème de guillemets ou d'indentation au copier-coller :

cat > ~/wordpress-compose/docker-compose.yml << 'EOF'
version: "3.8"

services:
  db:
    image: docker.io/library/mariadb:11
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: R00tS3cur3Pass!
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: WpS3cur3Pass!
    volumes:
      - mysql_data:/var/lib/mysql

  wordpress:
    image: docker.io/library/wordpress:latest
    restart: always
    depends_on:
      - db
    ports:
      - "8088:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: WpS3cur3Pass!
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp_data:/var/www/html

volumes:
  mysql_data:
  wp_data:
EOF

# Vérifier le résultat avant de lancer
cat ~/wordpress-compose/docker-compose.yml

Différence notable avec le pod : dans Docker Compose / podman-compose, les services communiquent via leur nom de service (db:3306) sur un réseau virtuel dédié créé automatiquement. Dans le pod Podman, ils utilisaient 127.0.0.1 car ils partagent le même namespace réseau.

podman-compose et les pods : podman-compose crée automatiquement un pod en coulisse, nommé d'après le répertoire de travail. Tu peux le constater avec podman pod ps après un podman-compose up. Ce pod est géré de façon transparente — tu ne le définis pas, tu ne le configures pas. C'est pourquoi la communication inter-conteneurs passe par le nom de service (db:3306) sur un réseau virtuel dédié, et non par 127.0.0.1 comme dans un pod Podman natif où les conteneurs partagent le même namespace réseau. En résumé : podman-compose utilise les pods comme mécanisme interne, mais t'en abstrait complètement.

7.3 Démarrer WordPress avec podman-compose

# Créer le répertoire de travail et générer le fichier (fait en section 7.2)
mkdir -p ~/wordpress-compose
cd ~/wordpress-compose

# Lancer les conteneurs en arrière-plan
podman-compose up -d

# Vérifier les conteneurs
podman ps

# Accéder à WordPress
# http://localhost:8088

# Stopper et supprimer les conteneurs
podman-compose down

# Supprimer également les volumes (DESTRUCTIF)
podman-compose down --volumes

7.4 Démarrer podman-compose au boot avec systemd

Voici comment créer un service systemd pour lancer podman-compose au démarrage :

# Créer le fichier de service utilisateur
mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/wordpress-compose.service << 'EOF'
[Unit]
Description=WordPress via podman-compose
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=%h/wordpress-compose
ExecStart=/usr/bin/podman-compose up -d
ExecStop=/usr/bin/podman-compose down
Restart=on-failure

[Install]
WantedBy=default.target
EOF

# Activer le service
systemctl --user daemon-reload
systemctl --user enable --now wordpress-compose.service

# Vérifier
systemctl --user status wordpress-compose.service

Explication des directives clés :

Type=oneshot : la commande se termine rapidement (lance les conteneurs en arrière-plan avec -d), ce qui est normal
RemainAfterExit=yes : le service reste "actif" même après la fin de ExecStart, ce qui est correct pour un service de type oneshot
WorkingDirectory=%h/wordpress-compose : %h est le spécificateur systemd pour le répertoire home de l'utilisateur

7.5 Tableau comparatif — Pod Podman vs podman-compose vs Quadlet

Critère	Pod + CLI Podman	podman-compose	Quadlet (recommandé)
Fichier de config	Commandes shell	`docker-compose.yml`	Fichiers `.container`/`.pod`
Compatibilité Docker	Non	✅ Oui	Non
Intégration systemd	Manuelle	Via unit custom	✅ Native
Migration Docker	Réécriture	✅ Transparente	Réécriture
Recommandé par Red Hat	✅ Pédagogique	Dépend du projet	✅ Production
Auto-update images	Manuel	Manuel	✅ `AutoUpdate=registry`
Gestion des secrets	Variables env	Variables env	✅ `podman secret`
Statut Red Hat	Stable	Communauté	✅ Officiel RHEL 9+

7.6 Conclusion — Quand utiliser quoi ?

Utilisez le Pod Podman + Quadlet quand :

Vous déployez en production sur un serveur Linux (RHEL, Rocky, Fedora Server)
Vous voulez une intégration systemd native et des auto-updates
Vous partez d'un nouveau projet (pas de Compose existant)

Utilisez podman-compose quand :

Vous migrez un projet existant depuis Docker sans modifier les fichiers Compose
Vous travaillez en environnement de développement
L'équipe est habituée à la syntaxe Docker Compose

8. Aide-mémoire des commandes

Gestion du pod

# Créer
podman pod create --name wp-blog --publish 8088:80

# Démarrer / Arrêter
podman pod start wp-blog
podman pod stop wp-blog

# Supprimer (arrête et supprime tous les conteneurs du pod)
podman pod rm -f wp-blog

# Lister les pods
podman pod ps

# Inspecter un pod
podman pod inspect wp-blog

Gestion des conteneurs

# Lister les conteneurs (avec leur pod)
podman ps --pod

# Logs d'un conteneur
podman logs -f wp-mysql
podman logs -f wp-app

# Exécuter une commande dans un conteneur
podman exec -it wp-mysql mariadb -u wpuser -p wordpress

# Statistiques en temps réel
podman stats

Gestion des volumes

# Lister les volumes
podman volume ls

# Inspecter
podman volume inspect mysql_data

# Exporter un volume (backup)
podman volume export mysql_data -o mysql_backup.tar

# Importer un volume (restauration)
podman volume import mysql_data mysql_backup.tar

# Supprimer les volumes orphelins
podman volume prune

Gestion systemd (Quadlet)

# Recharger après modification des fichiers Quadlet
systemctl --user daemon-reload

# Démarrer / Arrêter / Redémarrer
systemctl --user start wp-blog-pod.service
systemctl --user stop wp-blog-pod.service
systemctl --user restart wp-app.service

# Statut et logs
systemctl --user status wp-app.service
journalctl --user -u wp-app.service -f

# Activer le lingering
sudo loginctl enable-linger $USER
loginctl show-user $USER | grep Linger

podman-compose

# Démarrer
podman-compose up -d

# Arrêter
podman-compose down

# Voir les logs
podman-compose logs -f

# Voir le statut
podman-compose ps

# Auto-update des images
podman auto-update

Podman rootless — Fix session systemd user (Fedora 43)

Prérequis

Vérifier les subuid/subgid :

grep <user> /etc/subuid /etc/subgid

Si absent :

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 <user>

1. Activer le linger

sudo loginctl enable-linger <user>
ls /var/lib/systemd/linger/

2. Créer le répertoire runtime

sudo mkdir -p /run/user/<uid>
sudo chown <user>:<user> /run/user/<uid>
sudo chmod 700 /run/user/<uid>

3. Patcher le service systemd user

sudo systemctl edit user@<uid>.service

[Service]
Environment=XDG_RUNTIME_DIR=/run/user/<uid>

4. export also for shell

cat >> ~/.bashrc << 'EOF'
export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u)/bus
EOF
source ~/.bashrc

5. Démarrer et activer

sudo systemctl daemon-reload
sudo systemctl start user@<uid>.service
sudo systemctl enable user@<uid>.service
sudo systemctl status user@<uid>.service

Références officielles

Documentation Podman : https://docs.podman.io

Quadlet (podman-systemd.unit) : https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

podman-compose : https://github.com/containers/podman-compose

ANSSI — Recommandations de sécurité relatives au déploiement de conteneurs Docker : https://www.ssi.gouv.fr/guide/recommandations-de-securite-relatives-au-deploiement-de-conteneurs-docker/

stephdl/podman_wordpress.md