Maîtriser Podman : conteneurs rootless, systemd et pods

Q: Podman utilise-t-il Buildah pour construire les images ?

Oui, podman build utilise Buildah en interne pour construire les images. Les deux outils partagent le même code de build. La différence est que Buildah offre un contrôle plus fin avec des commandes interactives (from, run, commit) tandis que podman build se concentre sur les Containerfiles.

Q: Comment résoudre les problèmes de permissions avec les volumes Podman ?

Les problèmes de permissions en rootless proviennent du mapping UID. Utilisez :U pour ajuster automatiquement les propriétaires. Pour SELinux, ajoutez :Z (privé) ou :z (partagé). En dernier recours, --userns=keep-id mappe votre UID vers l'UID 1000 du conteneur.

Q: Podman peut-il générer des manifests Kubernetes ?

Oui, podman generate kube crée des manifests Kubernetes (Pod, Deployment, Service) à partir de conteneurs ou pods existants. Inversement, podman play kube déploie des manifests Kubernetes localement. C'est idéal pour développer en local puis déployer sur Kubernetes.

Q: Comment limiter la mémoire et le CPU d'un conteneur Podman ?

Utilisez --memory pour limiter la RAM (ex: --memory 512m) et --cpus pour limiter les cœurs CPU (ex: --cpus 1.5). Ces options fonctionnent en rootless via cgroups v2. Vérifiez avec podman stats ou en inspectant /sys/fs/cgroup dans le conteneur.

Q: Comment Podman gère-t-il la résolution DNS entre conteneurs ?

Sur le réseau par défaut (podman), les conteneurs ne peuvent pas se résoudre par nom. Créez un réseau personnalisé avec podman network create pour activer la résolution DNS automatique. Les conteneurs sur ce réseau peuvent alors s'atteindre par leur nom ou alias.

Podman est un moteur de conteneurs sans démon obligatoire (daemonless), pensé pour une utilisation “Linux native” : rootless par défaut, intégration propre à systemd via Quadlet, et support des pods façon Kubernetes. Sur macOS/Windows, il s’appuie sur Podman Machine (VM).

Le modèle mental Podman

Retenir 3 piliers (et 1 bonus) :

Rootless : les conteneurs tournent avec les droits de ton utilisateur, via les user namespaces.
Daemonless : pas besoin d’un service central permanent pour gérer tes conteneurs au quotidien.
Systemd-first : avec Quadlet, un conteneur devient un service propre (restart, logs, dépendances). Bonus) Pods & play kube : regrouper des conteneurs “style Kubernetes” et lancer des manifests sans cluster.

Si tu veux le “pourquoi” et les détails d’architecture : Concepts

Démarrer en 5 minutes

Objectif : valider que Podman tourne, que tu sais exposer un port, lire des logs, monter un volume, puis nettoyer.

# Vérifier la version
podman version

# Lancer un conteneur nginx
podman run -d --name web -p 8080:80 docker.io/library/nginx:alpine

# Vérifier qu'il tourne
curl http://localhost:8080

# Voir les logs
podman logs web

# Tester un volume (SELinux: :Z)
podman run -d --name web2 -v ~/html:/usr/share/nginx/html:Z -p 8081:80 nginx:alpine

# Nettoyer
podman rm -f web web2

Podman vs Docker : choisir sans se mentir

L’objectif ici n’est pas de refaire une comparaison exhaustive : c’est de t’aider à décider vite, puis de t’envoyer vers les guides.

Comparaison architecture Docker vs Podman

Choisis Podman si…

Tu veux rootless par défaut (multi-utilisateurs, postes partagés, moindre risque).
Tu veux des services systemd propres (serveur, self-hosting, edge).
Tu veux rester proche de Kubernetes (pods, play kube, generate kube).
Tu veux éviter un daemon central obligatoire sur la machine.

Reste sur Docker si…

Ton quotidien dépend d’un Docker Compose complexe et d’intégrations “Docker-only”.
Tu es dans un contexte où l’écosystème “Docker Desktop + tooling” est imposé.

Si tu veux un guide dédié “migrer sans douleur” : crée/ajoute une page Migration Docker → Podman et pointe-la ici.

Pilier 1 — Rootless en pratique

Le mode rootless est le gros avantage de Podman, mais il a des implications “terrain”.

Ce qui se passe réellement

Podman utilise les user namespaces pour mapper les identités du conteneur vers des UIDs/GIDs non privilégiés sur l’hôte :

Hôte                              Conteneur
─────────────────────────────────────────────
UID 1000 (vous)                   UID 0 (root)
UID 100000-165535 (subuid)        UID 1-65535

Les 3 frictions les plus courantes (et les bons réflexes)

Friction	Symptôme	Réflexe
Ports bas	`bind: permission denied` sur 80/443	utiliser ≥1024 ou sysctl
Volumes	fichiers “root:root” / `permission denied`	`--userns=keep-id` ou options volume
Réseau	DNS/perf surprenants	réseau dédié + backend rootless adapté

Pilier 2 — Réseau : pasta, netavark et DNS

En pratique, c’est souvent le réseau rootless qui “surprend”. L’idée : tu veux un réseau où les conteneurs se résolvent par nom et où la perf n’est pas catastrophique.

Exemple : DNS entre conteneurs (rootless)

# Créer un réseau applicatif (résolution par nom)
podman network create app-network

# Exemple simple : un conteneur "db" et un client
podman run -d --network app-network --name db postgres:16
podman run --rm --network app-network alpine ping -c 1 db

Pilier 3 — Systemd : Quadlet (recommandé)

Si tu veux du “prod-like” sur un serveur Linux, Quadlet est le point d’inflexion : un conteneur devient un service (journalctl, restart, dépendances).

Quadlet est la voie recommandée par l’écosystème Podman, et podman generate systemd est marqué comme déprécié (toujours utilisable, mais plus la direction). ([GitHub][1])

Exemple minimal : `nginx.container`

[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80
Volume=/data/nginx:/usr/share/nginx/html:ro,Z

[Service]
Restart=always

[Install]
WantedBy=default.target

Activation (rootless) :

mkdir -p ~/.config/containers/systemd
# placer nginx.container dans ce dossier

systemctl --user daemon-reload
systemctl --user start nginx
systemctl --user enable nginx
journalctl --user -u nginx -f

Bonus — Pods et intégration Kubernetes (sans cluster)

Quand tu as besoin d’un “mini-Kubernetes mental model” sans déployer un cluster, les pods Podman sont parfaits.

Pod : web + base de données

podman pod create --name webapp -p 8080:80

podman run -d --pod webapp --name db \
  -e POSTGRES_PASSWORD=secret postgres:16-alpine

podman run -d --pod webapp --name app \
  -e DATABASE_URL=postgres://postgres:secret@localhost:5432 \
  mon-app:latest

`podman play kube` : exécuter un manifest sans cluster

podman play kube deployment.yaml
podman play kube deployment.yaml --down

`podman generate kube` : exporter vers Kubernetes

podman generate kube webapp > webapp.yaml

macOS / Windows : Podman Machine

Sur macOS et Windows, les conteneurs Linux nécessitent une VM, car ils dépendent du kernel Linux.

podman machine init
podman machine start
podman run -d -p 8080:80 nginx
podman machine ssh

Parcours recommandé (simple)

Choisis ton point d’entrée, puis avance module par module :

Module	Objectif
Installation	être opérationnel (Linux/macOS/Windows)
Commandes de base	run/ps/exec/logs/images/nettoyage
Run avancé	rootless, namespaces, sécurité, options utiles
Volumes	persistance + permissions
Réseaux	DNS, ports, isolation, multi-tier
Build	Containerfile, multi-stage, optimisation

Autour de Podman

Buildah Construire des images sans daemon, workflows avancés.

Skopeo Copier/inspecter des images entre registries.

Conteneurisation Fondamentaux des conteneurs Linux et de l’écosystème OCI.

Évolutions à connaître (pour éviter les surprises)

Prochaines étapes (3 choix max)

Installation Linux, macOS, Windows + Podman Machine.

Commandes de base Le socle : run, ps, exec, logs, images.

Quadlet & systemd Passer au niveau “serveur” proprement.

FAQ — Questions fréquentes

Qu'est-ce que l'architecture daemonless de Podman ?

Podman fonctionne sans démon central contrairement à Docker. Chaque commande podman crée directement un processus conteneur via conmon, sans passer par un service intermédiaire. Si un processus Podman plante, les autres conteneurs continuent de fonctionner indépendamment.

Podman fonctionne sans démon central (daemonless), contrairement à Docker qui nécessite le service dockerd.

Comparaison architecturale

Docker :         Client → dockerd (root) → containerd → runc → conteneur

Podman :         Client → conmon (user) → runc → conteneur

Avantages du daemonless

Aspect	Docker (daemon)	Podman (daemonless)
Point de défaillance	dockerd = SPOF	Pas de SPOF
Redémarrage service	Tue tous les conteneurs	Conteneurs indépendants
Surface d'attaque	Daemon root exposé	Pas de daemon
Ressources	Daemon permanent	Processus à la demande

En pratique

# Pas de service à démarrer
podman run -d nginx  # Crée directement le processus

# Chaque conteneur est un processus indépendant
ps aux | grep conmon
# user  1234  conmon --cid abc123...
# user  5678  conmon --cid def456...

→ Concepts Podman

Comment fonctionne le mode rootless de Podman ?

Le mode rootless permet d'exécuter des conteneurs sans privilèges root grâce aux user namespaces Linux. L'utilisateur régulier obtient une plage d'UIDs mappés (ex: 100000-165535) où il peut créer des conteneurs. Le root dans le conteneur correspond à un UID non privilégié sur l'hôte.

Le mode rootless de Podman permet d'exécuter des conteneurs sans aucun privilège root grâce aux user namespaces Linux.

Principe de fonctionnement

┌─────────────────────────────────────────────────────────┐
│                       HÔTE                              │
│  Utilisateur bob (UID 1000)                             │
│  └── Plage subuid : 100000-165535                       │
│                                                         │
│  ┌─────────────────────────────────────────────────┐   │
│  │              CONTENEUR                           │   │
│  │  root (UID 0) → mappé sur UID 100000 (hôte)     │   │
│  │  user (UID 1000) → mappé sur UID 101000 (hôte)  │   │
│  └─────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

Configuration

# Vérifier les plages subuid/subgid
cat /etc/subuid
# bob:100000:65536

# Initialiser le user namespace
podman system migrate

# Lancer un conteneur rootless
podman run -d nginx

Sécurité

Scénario	Impact rootless
Évasion du conteneur	Attaquant = UID 100000 (non privilégié)
Accès au socket	Pas de socket root exposé
Montage /etc/passwd	Impossible sans droits

→ Installation rootless

Quelle est la différence entre un pod Podman et un conteneur ?

Un conteneur Podman exécute un processus isolé. Un pod Podman regroupe plusieurs conteneurs qui partagent le même namespace réseau (localhost), le même namespace IPC et les mêmes volumes. Les conteneurs d'un pod communiquent entre eux sans configuration réseau supplémentaire.

Un conteneur exécute un processus isolé. Un pod regroupe plusieurs conteneurs qui partagent des ressources.

Ce que partagent les conteneurs d'un pod

Ressource	Partagée ?	Implication
Namespace réseau	✅ Oui	Tous les conteneurs utilisent localhost
Namespace IPC	✅ Oui	Mémoire partagée possible
Namespace UTS	✅ Oui	Même hostname
Volumes	⚙️ Configurable	Partage de données
Namespace PID	❌ Non	Processus isolés

Exemple pratique

# Créer un pod avec un port exposé
podman pod create --name webapp -p 8080:80

# Ajouter une BDD (accessible via localhost dans le pod)
podman run -d --pod webapp \
  --name db \
  -e POSTGRES_PASSWORD=secret \
  postgres:16-alpine

# Ajouter l'app (accède à la BDD via localhost:5432)
podman run -d --pod webapp \
  --name app \
  -e DATABASE_HOST=localhost \
  mon-app:latest

Analogie Kubernetes

Le concept de pod Podman est identique à celui de Kubernetes, ce qui facilite la migration.

# Générer un manifest Kubernetes depuis un pod Podman
podman generate kube webapp > webapp.yaml

→ Concepts pods

Comment migrer de Docker vers Podman ?

La migration est simple : installez Podman, créez un alias docker=podman, et vos commandes fonctionnent. Les Dockerfiles deviennent des Containerfiles (supportés tels quels). Pour docker-compose, utilisez podman-compose ou podman compose. Les images Docker Hub fonctionnent sans modification.

La migration de Docker vers Podman est conçue pour être transparente grâce à la compatibilité CLI.

Étape 1 : Installer Podman

# Ubuntu/Debian
sudo apt install podman

# Fedora
sudo dnf install podman

Étape 2 : Créer l'alias

# Dans ~/.bashrc ou ~/.zshrc
alias docker=podman

Étape 3 : Migrer les commandes

Docker	Podman	Notes
`docker run`	`podman run`	✅ Identique
`docker build`	`podman build`	✅ Identique
`docker-compose`	`podman-compose`	Installer via pip
`Dockerfile`	`Containerfile`	Les deux acceptés

Étape 4 : Docker Compose

# Option 1 : podman-compose
pip install podman-compose
podman-compose up -d

# Option 2 : podman compose (4.x+)
podman compose up -d

Ce qui fonctionne directement

✅ Images Docker Hub
✅ Dockerfile/Containerfile
✅ Volumes et réseaux
✅ Variables d'environnement

Différences mineures

Registres multiples par défaut (pas seulement Docker Hub)
Socket différent (/run/podman/podman.sock)
Mode rootless par défaut

→ Installation Podman

Comment exposer un port avec Podman en mode rootless ?

En mode rootless, les ports inférieurs à 1024 nécessitent une configuration spéciale. Utilisez un port supérieur (ex: 8080) ou configurez net.ipv4.ip_unprivileged_port_start=80 dans sysctl. Sinon, utilisez slirp4netns avec port_handler=rootlesskit pour un mapping transparent.

En mode rootless, l'exposition de ports a quelques particularités liées aux privilèges.

Ports ≥ 1024 (fonctionnent directement)

# Aucune configuration spéciale
podman run -d -p 8080:80 nginx
curl http://localhost:8080

Ports < 1024 (nécessitent configuration)

# Par défaut, erreur :
podman run -d -p 80:80 nginx
# Error: rootlessport cannot expose privileged port 80

Solution 1 : Modifier sysctl

# Autoriser les ports à partir de 80
sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80
# Rendre permanent
echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/podman-ports.conf

Solution 2 : Utiliser rootlesskit

# Dans ~/.config/containers/containers.conf
[network]
rootless_networking = "pasta"

Tableau récapitulatif

Port	Mode rootless	Solution
≥ 1024	✅ Direct	`-p 8080:80`
< 1024	⚠️ Bloqué	sysctl ou rootlesskit
443 (HTTPS)	⚠️ Bloqué	sysctl ou reverse proxy

→ Réseaux Podman

Podman utilise-t-il Buildah pour construire les images ?

Oui, podman build utilise Buildah en interne pour construire les images. Les deux outils partagent le même code de build. La différence est que Buildah offre un contrôle plus fin avec des commandes interactives (from, run, commit) tandis que podman build se concentre sur les Containerfiles.

Oui, podman build utilise Buildah en interne pour la construction d'images.

Architecture de build

podman build ─────┐
                  ▼
              Buildah (bibliothèque)
                  │
                  ▼
              Image OCI

Différences d'usage

Outil	Usage	Commande type
podman build	Build via Containerfile	`podman build -t app .`
buildah	Build interactif ou scripté	`buildah from`, `buildah run`, `buildah commit`

Exemple Buildah interactif

# Créer un conteneur de travail
ctr=$(buildah from alpine:3.21)

# Exécuter des commandes
buildah run $ctr apk add --no-cache curl jq

# Configurer l'image
buildah config --entrypoint '["curl"]' $ctr

# Committer l'image
buildah commit $ctr mon-curl:1.0

Quand utiliser Buildah directement ?

Scripts de build complexes sans Dockerfile
Modification d'images existantes
Pipelines CI/CD avec contrôle fin
Images minimales construites instruction par instruction

→ Guide Buildah

Comment résoudre les problèmes de permissions avec les volumes Podman ?

Les problèmes de permissions en rootless proviennent du mapping UID. Utilisez :U pour ajuster automatiquement les propriétaires. Pour SELinux, ajoutez :Z (privé) ou :z (partagé). En dernier recours, --userns=keep-id mappe votre UID vers l'UID 1000 du conteneur.

Les problèmes de permissions avec les volumes Podman sont souvent liés au mapping UID en mode rootless ou à SELinux.

Diagnostic

# Vérifier les permissions
podman run --rm -v ~/data:/data alpine ls -la /data
# Permission denied → problème d'UID ou SELinux

Solution 1 : Option :U (ajustement UID)

# :U ajuste automatiquement le propriétaire pour le mapping rootless
podman run -v ~/data:/data:U mon-app

Solution 2 : SELinux avec :Z ou :z

# :Z = label privé (un seul conteneur)
podman run -v ~/data:/data:Z mon-app

# :z = label partagé (plusieurs conteneurs)
podman run -v ~/shared:/shared:z mon-app

Solution 3 : keep-id

# Votre UID (1000) devient l'UID 1000 dans le conteneur
podman run --userns=keep-id -v ~/data:/data mon-app

Tableau des options

Option	Problème résolu	Effet
`:U`	UID rootless	Chown récursif
`:Z`	SELinux	Label privé
`:z`	SELinux partagé	Label partagé
`--userns=keep-id`	Mapping UID	Conserve votre UID
`:ro`	Sécurité	Lecture seule

→ Volumes Podman

Podman peut-il générer des manifests Kubernetes ?

Oui, podman generate kube crée des manifests Kubernetes (Pod, Deployment, Service) à partir de conteneurs ou pods existants. Inversement, podman play kube déploie des manifests Kubernetes localement. C'est idéal pour développer en local puis déployer sur Kubernetes.

Oui, Podman peut générer et exécuter des manifests Kubernetes nativement.

Générer un manifest depuis un conteneur/pod

# Depuis un conteneur unique
podman run -d --name web -p 8080:80 nginx
podman generate kube web > web-pod.yaml

# Depuis un pod complet
podman pod create --name webapp -p 8080:80
podman run -d --pod webapp --name db postgres:16
podman run -d --pod webapp --name app mon-app
podman generate kube webapp > webapp.yaml

Exemple de manifest généré

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: db
    image: postgres:16
  - name: app
    image: mon-app:latest

Exécuter un manifest Kubernetes localement

# Déployer un manifest existant
podman play kube webapp.yaml

# Avec un ConfigMap
podman play kube webapp.yaml --configmap config.yaml

# Arrêter et supprimer
podman play kube webapp.yaml --down

Workflow dev → prod

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Dev local  │ ──▶ │   generate  │ ──▶ │ Kubernetes  │
│  (podman)   │     │    kube     │     │   (prod)    │
└─────────────┘     └─────────────┘     └─────────────┘

→ Concepts pods

Comment limiter la mémoire et le CPU d'un conteneur Podman ?

Utilisez --memory pour limiter la RAM (ex: --memory 512m) et --cpus pour limiter les cœurs CPU (ex: --cpus 1.5). Ces options fonctionnent en rootless via cgroups v2. Vérifiez avec podman stats ou en inspectant /sys/fs/cgroup dans le conteneur.

Podman utilise les cgroups pour limiter les ressources des conteneurs.

Limiter la mémoire

# Limite à 512 Mo de RAM
podman run -d --memory 512m nginx

# Limite RAM + swap
podman run -d --memory 512m --memory-swap 1g nginx

Limiter le CPU

# Limite à 1.5 cœurs CPU
podman run -d --cpus 1.5 nginx

# Limite en millicores (comme Kubernetes)
podman run -d --cpus 0.5 nginx  # 500m

# Limiter à certains cœurs spécifiques
podman run -d --cpuset-cpus 0,1 nginx

Limiter les processus

# Maximum 100 processus
podman run -d --pids-limit 100 nginx

Vérifier les limites

# Statistiques en temps réel
podman stats

# Inspecter les limites configurées
podman inspect nginx --format '{{.HostConfig.Memory}}'

Tableau récapitulatif

Option	Effet	Exemple
`--memory`	Limite RAM	`--memory 256m`
`--memory-swap`	Limite RAM+swap	`--memory-swap 512m`
`--cpus`	Limite cœurs	`--cpus 2`
`--cpuset-cpus`	Cœurs spécifiques	`--cpuset-cpus 0,2`
`--pids-limit`	Limite processus	`--pids-limit 50`

→ Run avancé

Comment Podman gère-t-il la résolution DNS entre conteneurs ?

Sur le réseau par défaut (podman), les conteneurs ne peuvent pas se résoudre par nom. Créez un réseau personnalisé avec podman network create pour activer la résolution DNS automatique. Les conteneurs sur ce réseau peuvent alors s'atteindre par leur nom ou alias.

La résolution DNS entre conteneurs dépend du type de réseau utilisé.

Réseau par défaut : pas de DNS

# Le réseau 'podman' par défaut n'a pas de DNS
podman run -d --name db postgres:16
podman run --rm alpine ping db
# ping: bad address 'db' ← Échec !

Réseau personnalisé : DNS activé

# Créer un réseau avec DNS intégré
podman network create mon-reseau

# Lancer les conteneurs sur ce réseau
podman run -d --network mon-reseau --name db postgres:16
podman run --rm --network mon-reseau alpine ping db
# PING db (10.89.0.2): 56 data bytes ← Succès !

Alias DNS

# Ajouter des alias pour un conteneur
podman run -d --network mon-reseau \
  --name postgres \
  --network-alias db \
  --network-alias database \
  postgres:16

# Accessible via 'postgres', 'db' ou 'database'

Tableau récapitulatif

Réseau	DNS	Isolation
`podman` (défaut)	❌ Non	Minimale
Personnalisé	✅ Oui	Par réseau
`host`	Hôte	Aucune
`none`	❌ Non	Totale

→ Réseaux Podman

Comment lancer un conteneur au démarrage avec Quadlet ?

Quadlet remplace podman generate systemd (déprécié). Créez un fichier .container dans ~/.config/containers/systemd/ (rootless) ou /etc/containers/systemd/ (rootful). Au prochain daemon-reload, systemd génère automatiquement le service correspondant.

Quadlet est la méthode recommandée pour exécuter des conteneurs comme services systemd. Elle remplace podman generate systemd qui est déprécié.

Créer un fichier Quadlet

# Rootless : ~/.config/containers/systemd/
# Rootful : /etc/containers/systemd/
mkdir -p ~/.config/containers/systemd

Exemple minimal : nginx.container

[Container]
Image=docker.io/library/nginx:alpine
PublishPort=8080:80
Volume=/data/nginx:/usr/share/nginx/html:ro,Z

[Service]
Restart=always

[Install]
WantedBy=default.target

Activer le service

# Recharger systemd pour détecter le fichier
systemctl --user daemon-reload

# Démarrer le conteneur
systemctl --user start nginx.service

# Activer au boot
systemctl --user enable nginx.service

Avantages de Quadlet

Aspect	generate systemd	Quadlet
Maintenance	Régénérer si config change	Fichier déclaratif
Statut	Déprécié	Recommandé
Logs	`podman logs`	`journalctl`
Restart	Configurable	Natif systemd

→ Documentation Quadlet

Pourquoi Podman Machine utilise-t-il une VM sur macOS et Windows ?

Les conteneurs Linux nécessitent un kernel Linux pour s'exécuter. Sur macOS et Windows, Podman Machine crée une VM légère (QEMU/HyperKit/WSL2) qui fournit ce kernel. Les commandes podman sont transparentes car elles communiquent automatiquement avec la VM.

Les conteneurs Linux reposent sur des fonctionnalités du kernel Linux (namespaces, cgroups, etc.). macOS et Windows n'ont pas ce kernel nativement.

Architecture Podman Machine

macOS/Windows                    VM Podman Machine
┌─────────────────┐             ┌─────────────────┐
│  podman CLI     │ ◄─────────▶ │  Kernel Linux   │
│  (commandes)    │   socket    │  + Podman       │
│                 │             │  + Conteneurs   │
└─────────────────┘             └─────────────────┘

Commandes de base

# Initialiser la VM (télécharge l'image Fedora CoreOS)
podman machine init

# Démarrer la VM
podman machine start

# Vérifier le statut
podman machine list

# Se connecter à la VM
podman machine ssh

Options de virtualisation

Plateforme	Backend par défaut	Alternative
macOS Intel	QEMU	HyperKit
macOS Apple Silicon	QEMU (arm64)	-
Windows	WSL 2	Hyper-V

Forwarding de ports

Les ports exposés par les conteneurs sont automatiquement accessibles sur localhost grâce au forwarding intégré.→ Installation Podman

Podman vs Docker en production : lequel choisir ?

Choisissez Podman si vous voulez du rootless natif, une intégration systemd/Quadlet, ou une compatibilité Kubernetes (pods). Restez sur Docker si votre équipe maîtrise l'écosystème Docker Compose et que rootless n'est pas prioritaire. Les deux sont matures pour la production.

Les deux outils sont matures pour la production. Le choix dépend de vos priorités.

Arbre de décision

Critère	→ Podman	→ Docker
Sécurité rootless	✅ Natif	⚠️ Expérimental
Intégration systemd	✅ Quadlet	❌ Workarounds
Pods Kubernetes	✅ Natif	❌ Non supporté
Docker Compose	⚠️ Compat partielle	✅ Natif
Écosystème existant	⚠️ Migration	✅ Déjà en place
Support enterprise	Red Hat	Docker Inc

Recommandations

Choisir Podman si :

Environnement RHEL/Fedora/CentOS
Sécurité rootless requise
Services systemd (self-hosting)
Préparation vers Kubernetes

Rester sur Docker si :

Équipe formée Docker Compose
Intégrations tierces Docker-only
Pas de contrainte rootless

En pratique

Beaucoup d'équipes utilisent les deux : Docker Desktop pour le dev, Podman pour la prod sur serveurs Linux.→ Comparaison Docker

Pourquoi mes ports ou mon DNS ne marchent pas en rootless ?

En rootless, le réseau passe par slirp4netns ou pasta au lieu du bridge kernel. Cela cause des limitations : ports < 1024 bloqués, DNS entre conteneurs désactivé par défaut, et performances réseau réduites. Créez un réseau personnalisé et configurez sysctl pour les ports privilégiés.

Le mode rootless utilise un réseau "userspace" (slirp4netns ou pasta) au lieu du bridge kernel, ce qui cause certaines limitations.

Problème 1 : Ports < 1024

# Erreur typique
podman run -p 80:80 nginx
# Error: rootlessport cannot expose privileged port 80

Solution :

sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80

Problème 2 : DNS entre conteneurs

# Le réseau par défaut n'a pas de DNS
podman run --rm alpine ping other-container
# ping: bad address 'other-container'

Solution : créer un réseau personnalisé

podman network create mon-reseau
podman run -d --network mon-reseau --name db postgres
podman run --rm --network mon-reseau alpine ping db  # ✅ fonctionne

Problème 3 : Performance réseau

slirp4netns est plus lent que le bridge kernel.Solution : utiliser pasta (Podman 4.x+)

# ~/.config/containers/containers.conf
[network]
default_rootless_network_cmd = "pasta"

Tableau des backends réseau rootless

Backend	Perf	DNS	Disponibilité
slirp4netns	Lente	❌	Partout
pasta	Rapide	✅	Podman 4.4+

→ Réseaux Podman

À quoi sert podman play kube ?

podman play kube déploie des manifests Kubernetes (Pod, Deployment, ConfigMap) directement sur Podman sans cluster Kubernetes. C'est idéal pour tester localement des manifests avant de les déployer en production, ou pour exécuter des workloads Kubernetes sur une machine standalone.

podman play kube permet de déployer des manifests Kubernetes localement sans avoir besoin d'un cluster.

Cas d'usage

Test local avant déploiement en prod
Machines edge sans Kubernetes
CI/CD pour valider les manifests
Développement avec les mêmes fichiers que la prod

Exemple pratique

# webapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: web
    image: nginx:alpine
    ports:
    - containerPort: 80
      hostPort: 8080

# Déployer le manifest
podman play kube webapp.yaml

# Vérifier
podman pod ps
podman ps
curl http://localhost:8080

# Arrêter et supprimer
podman play kube webapp.yaml --down

Ressources Kubernetes supportées

Ressource	Support
Pod	✅ Complet
Deployment	✅ Complet
ConfigMap	✅ Complet
Secret	✅ Complet
Service	⚠️ Partiel
PersistentVolume	⚠️ Limité

→ Concepts pods

Maîtriser Podman : conteneurs rootless, systemd et pods

Le modèle mental Podman

Démarrer en 5 minutes

Podman vs Docker : choisir sans se mentir

Choisis Podman si…

Reste sur Docker si…

Pilier 1 — Rootless en pratique

Ce qui se passe réellement

Les 3 frictions les plus courantes (et les bons réflexes)

Pilier 2 — Réseau : pasta, netavark et DNS

Exemple : DNS entre conteneurs (rootless)

Pilier 3 — Systemd : Quadlet (recommandé)

Exemple minimal : nginx.container

Bonus — Pods et intégration Kubernetes (sans cluster)

Pod : web + base de données

podman play kube : exécuter un manifest sans cluster

podman generate kube : exporter vers Kubernetes

macOS / Windows : Podman Machine

Parcours recommandé (simple)

Autour de Podman

Évolutions à connaître (pour éviter les surprises)

Prochaines étapes (3 choix max)

FAQ — Questions fréquentes

Comparaison architecturale

Avantages du daemonless

En pratique

Principe de fonctionnement

Configuration

Sécurité

Ce que partagent les conteneurs d'un pod

Exemple pratique

Analogie Kubernetes

Étape 1 : Installer Podman

Étape 2 : Créer l'alias

Étape 3 : Migrer les commandes

Étape 4 : Docker Compose

Ce qui fonctionne directement

Différences mineures

Ports ≥ 1024 (fonctionnent directement)

Ports < 1024 (nécessitent configuration)

Tableau récapitulatif

Architecture de build

Différences d'usage

Exemple Buildah interactif

Quand utiliser Buildah directement ?

Diagnostic

Solution 1 : Option :U (ajustement UID)

Solution 2 : SELinux avec :Z ou :z

Solution 3 : keep-id

Tableau des options

Générer un manifest depuis un conteneur/pod

Exemple de manifest généré

Exécuter un manifest Kubernetes localement

Workflow dev → prod

Limiter la mémoire

Limiter le CPU

Limiter les processus

Vérifier les limites

Tableau récapitulatif

Réseau par défaut : pas de DNS

Réseau personnalisé : DNS activé

Alias DNS

Tableau récapitulatif

Créer un fichier Quadlet

Exemple minimal : nginx.container

Activer le service

Avantages de Quadlet

Architecture Podman Machine

Commandes de base

Options de virtualisation

Forwarding de ports

Arbre de décision

Recommandations

En pratique

Problème 1 : Ports < 1024

Problème 2 : DNS entre conteneurs

Problème 3 : Performance réseau

Tableau des backends réseau rootless

Cas d'usage

Exemple pratique

Exemple minimal : `nginx.container`

`podman play kube` : exécuter un manifest sans cluster

`podman generate kube` : exporter vers Kubernetes