Podman : Guide complet pour gérer vos conteneurs sans démon

Qu’est-ce que Podman ? Notions de base sur les conteneurs

Définition et concepts fondamentaux

• POD manager : acronyme de l’outil open source
• libpod : bibliothèque de gestion de l’écosystème
• Red Hat : développeur principal avec la communauté
• Daemonless : aucun processus root en arrière-plan
• SLE Micro : outil par défaut pour les conteneurs
• Virtualisation légère : exécution sur un hôte unique

Podman est un moteur de conteneurs open source développé par Red Hat et la communauté. Son nom vient de POD manager : il gère l’écosystème de conteneurs via la bibliothèque libpod. Contrairement aux solutions traditionnelles, il fonctionne sans démon : aucune processus root ne tourne en arrière-plan sur votre système.

Les conteneurs représentent une méthode de virtualisation légère sur un hôte unique. Ils encapsulent une application avec ses dépendances, sans le poids d’une machine virtuelle complète. Sur certaines distributions comme SLE Micro, Podman est l’outil par défaut pour gérer ces environnements.

Comprendre la différence entre conteneur, image et pod

Une image est un modèle figé : elle contient le code, les bibliothèques et la configuration nécessaires. Un conteneur est une instance exécutable créée à partir de cette image. Les conteneurs sont éphémères : on les crée, les arrête et les supprime au besoin.

Un pod va plus loin : il regroupe plusieurs conteneurs qui partagent les namespaces réseau, PID et IPC. Les conteneurs d’un même pod communiquent entre eux via localhost. Chaque pod inclut un conteneur INFRA basé sur l’image k8s.gcr.io/pause:3.2, et la publication des ports se déclare une seule fois au niveau du pod. C’est un modèle « mini-Kubernetes » sans déployer de cluster, à l’image des pods et services orchestrés par Kubernetes. Cette approche, couplée aux commandes proches de Docker et à la capacité de générer des manifests Kubernetes, explique pourquoi la version 6.0.0 sortie le 24 juin 2026 a rejoint la CNCF, comme le fait Helm pour empaqueter des applications via des charts.

Podman vs Docker : Architecture et différences clés

La différence fondamentale entre Docker et Podman tient à leur architecture. Docker repose sur un démon centralisé qui tourne en permanence avec les droits root, gère les conteneurs et expose un socket système. Podman, lui, est daemonless : chaque commande lance directement le processus conteneur via conmon, sans service intermédiaire. En pratique, si un processus Podman plante, les autres conteneurs continuent de fonctionner normalement.

Cette architecture a une conséquence directe sur la sécurité. Docker nécessite un démon root qui devient un point de défaillance unique ; Podman élimine ce risque en exécutant les conteneurs en mode rootless. Le mode rootless de Docker n’existe qu’à titre expérimental depuis la version 20.10, alors que pour Podman, c’est une fonctionnalité de base, intégrée depuis sa conception.

Un autre point de divergence majeur concerne la construction d’images. Docker intègre ce processus dans son démon, tandis que Podman délègue cette tâche à des binaires distincts comme Buildah et Skopeo. Cette séparation des responsabilités renforce la sécurité et la modularité de l’écosystème Podman. Côté compatibilité, la migration est facilitée : les Dockerfiles fonctionnent tels quels en tant que Containerfiles, et les images du Docker Hub sont utilisables sans modification. Le principal obstacle à la migration reste Docker Compose, que Podman délègue à podman-compose ou à la commande podman compose, selon votre installation.

Commandes essentielles pour gérer les conteneurs et les pods

Cette modularité, qui sépare les outils selon leur fonction, rappelle la manière dont la technique RAG associe un modèle de génération à un système de récupération pour produire des réponses contextuelles.

Cette séparation des responsabilités renforce la sécurité et la modularité de l’écosystème, une philosophie que l’on retrouve dans l’empaquetage d’applications Kubernetes via des charts Helm, où chaque composant est défini et géré de manière déclarative.

Gestion des conteneurs : cycle de vie complet

La maîtrise de Podman passe par une poignée de commandes qui couvrent l’intégralité du cycle de vie d’un conteneur. Le point d’entrée est podman run, qui crée puis exécute une instance à partir d’une image. Une fois votre conteneur lancé, podman ps liste les conteneurs actifs ; ajoutez l’option , all pour voir également ceux qui sont arrêtés. Pour suspendre l’exécution, podman stop arrête proprement le processus en utilisant son nom ou son ID. Un conteneur stoppé peut être relancé avec podman start. Enfin, lorsqu’un conteneur ne sert plus, podman rm le supprime ; l’option -f force la suppression, même si le conteneur tourne encore.

• podman run : crée et exécute une instance d’image
• podman ps : liste les conteneurs en cours d’exécution
• podman ps, all : liste tous les conteneurs créés
• podman stop : arrête un conteneur par nom ou ID
• podman start : démarre un conteneur arrêté
• podman rm : supprime un conteneur, option -f pour forcer

Création et gestion des pods

Là où Podman excelle, c’est dans la gestion des pods, un groupe de conteneurs partageant les mêmes namespaces réseau, PID et IPC. Cela leur permet de communiquer entre eux via localhost, comme s’ils étaient sur la même machine. La commande podman pod create initialise un pod et génère un ID unique. Chaque pod inclut toujours un conteneur INFRA (image k8s.gcr.io/pause:3.2) qui maintient les namespaces ouverts. La publication des ports se déclare une seule fois sur le pod, et non sur chaque conteneur individuel. Cette approche offre un modèle mental de « mini-Kubernetes » sans nécessiter le déploiement d’un cluster complet.

Pour illustrer, lancez un pod avec podman pod create --name mon-pod -p 8080:80, puis ajoutez-y un conteneur avec podman run --pod mon-pod nginx. Les conteneurs du pod sont alors accessibles depuis l’extérieur via le port publié au niveau du pod, et entre eux via localhost. Cette structure facilite grandement le déploiement d’applications multi-conteneurs interconnectées, tout en conservant une isolation réseau claire.

Mode rootless : Sécurité et conteneurs sans privilèges

Le mode rootless est l’atout sécurité majeur de Podman. Vos conteneurs s’exécutent avec vos droits utilisateur, sans jamais requérir les privilèges root. Grâce aux user namespaces, les UID/GID non privilégiés sont mappés vers une plage dédiée, par exemple 100000-165535 pour un utilisateur standard. Concrètement, un processus « root » à l’intérieur du conteneur possède l’UID 100000 sur l’hôte, un compte non privilégié impossible à confondre avec le vrai root.

Cette isolation protège votre système : un attaquant parvenant à s’échapper du conteneur reste un utilisateur sans droits. Gardez toutefois en tête que les ports inférieurs à 1024 restent bloqués en rootless, sauf configuration sysctl spécifique. Vous pouvez également brider vos ressources, avec une limite mémoire de 512m ou 1.5 cœurs CPU via --memory et --cpus, renforçant encore l’isolation de vos workloads.

Architecture de Podman : Un moteur sans démon

Contrairement à Docker, qui repose sur un démon centralisé toujours actif, Podman fonctionne sans démon. Chaque commande lancée crée directement un processus conteneur via conmon, sans service intermédiaire ni socket root exposé sur l’hôte. Cette architecture élimine un point de défaillance unique : si un processus podman plante, les autres conteneurs continuent de fonctionner normalement.

Cette conception renforce la sécurité en évitant tout processus privilégié en arrière-plan. Podman ne construit pas non plus d’images : cette fonctionnalité est déléguée à des binaires distincts, Buildah 1.44 et Skopeo 1.23, tous deux exigés par Podman 6.0.0, sorti le 24 juin 2026. L’écosystème reste modulaire et lean, chaque outil ayant une responsabilité unique et complémentaire.

Installation, intégration systemd et migration depuis Docker

Installation de Podman et premiers pas

• SLE Micro Podman inclus par défaut dans la distribution
• Installation sudo transactional-update pkg install podman* puis redémarrage
• Podman Machine VM Linux pour macOS et Windows (QEMU/HyperKit/WSL2)
• Version stable référence 5.8.5, publiée le 8 juillet 2026
• Podman 6.0.0 sortie le 24 juin 2026, dépôt rejoint CNCF

L’installation de Podman dépend de votre système. Sur SLE Micro, l’outil est présent nativement, ce qui simplifie grandement la prise en main. Pour les autres distributions Linux, le gestionnaire de paquets habituel suffit. Sur macOS et Windows, l’utilisation de Podman Machine est indispensable : les conteneurs Linux nécessitent un noyau Linux, fourni par une machine virtuelle sous le capot.

La version de référence reste Podman 5.8.5, stable et éprouvée. La sortie de Podman 6.0.0 a introduit des exigences techniques notables : Buildah 1.44, Skopeo 1.23 et Netavark/Aardvark 2.0 sont désormais requis pour un fonctionnement optimal.

Intégration systemd avec Quadlet et migration Docker

Pour exécuter vos conteneurs comme des services système, Quadlet est l’approche recommandée. Placez un fichier .container dans ~/.config/containers/systemd/ ou /etc/containers/systemd/, puis rechargez systemd : le service est généré automatiquement. Vous bénéficiez alors de journalctl pour les logs, redémarrage automatique et gestion des dépendances. L’ancien outil podman generate systemd est désormais déprécié.

Côté migration, la compatibilité est remarquable : un simple alias docker=podman permet de réutiliser la majorité des commandes. Vos Dockerfiles fonctionnent tels quels, les images du Docker Hub restent exploitables, et podman-compose ou podman compose prennent le relais de Docker Compose. Pour générer des manifests Kubernetes à partir de vos conteneurs, podman generate kube s’avère particulièrement utile.