Podman, LXC et Kubernetes : les alternatives à Docker

Docker n'est pas le seul outil de conteneurs : Podman fait tourner les mêmes images sans démon et sans root, LXC fournit des conteneurs système qui se comportent comme de petites machines, et Kubernetes orchestre des conteneurs sur plusieurs serveurs. Ce chapitre présente chacun, avec ses commandes de base et ses cas d'usage, pour que tu saches choisir et justifier ton choix.

Le standard OCI : les images sont interchangeables

Les formats d'image et d'exécution sont normalisés par l'OCI (Open Container Initiative). Une image construite par docker build se lance avec Podman, avec Kubernetes, avec containerd, ou en conteneur d'application sur Proxmox VE 9. Changer d'outil ne demande donc pas de reconstruire les images ; seules les commandes et la façon de les gérer changent.

Podman : sans démon et sans root

Podman, développé par Red Hat, reprend presque toutes les commandes de Docker, avec deux différences de conception :

• pas de démon : chaque commande podman lance le conteneur directement, comme un processus enfant ; il n'y a pas de service root permanent, ni de socket qui donne les pleins pouvoirs ;
• sans root par défaut : un utilisateur ordinaire lance ses conteneurs dans son propre espace de noms utilisateur, comme le mode rootless de Docker, mais sans rien configurer.

Sur Debian 13, Podman (version 5.4) s'installe depuis les dépôts de la distribution :

sudo apt install podman
podman run --rm docker.io/library/alpine:3.24 cat /etc/os-release

Les commandes sont les mêmes : podman ps, podman logs, podman exec, podman build, podman volume, podman network. Le paquet podman-docker ajoute même une commande docker qui appelle Podman.

Les pods. Podman sait regrouper plusieurs conteneurs dans un pod qui partage le même réseau (ils se joignent par localhost), comme Kubernetes :

podman pod create --name gestion -p 8080:8080
podman run -d --pod gestion --name front ghcr.io/sorbier/sorbier-frais-front:2.4.0

Compose. La commande podman compose lit un compose.yaml en s'appuyant sur un outil Compose installé à côté (docker-compose ou podman-compose). Podman peut aussi exposer une API compatible avec celle de Docker (systemctl --user enable --now podman.socket), que les outils prévus pour Docker utilisent sans le savoir.

Quadlet : des conteneurs gérés par systemd. Sans démon, qui relance les conteneurs au démarrage du serveur ? systemd. Avec Quadlet, on décrit un conteneur dans un petit fichier, et systemd en fait un service :

# ~/.config/containers/systemd/wiki.container
[Unit]
Description=Wiki interne

[Container]
Image=docker.io/library/nginx:1.30-alpine
PublishPort=127.0.0.1:8081:80
Volume=wiki-pages:/usr/share/nginx/html

[Service]
Restart=always

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user start wiki.service
systemctl --user status wiki.service

Le conteneur se gère alors comme n'importe quel service : journalctl --user -u wiki, démarrage automatique, dépendances. Pour qu'il démarre sans session ouverte, active loginctl enable-linger pour l'utilisateur, comme pour Docker rootless.

Podman ou Docker : le comparatif

Lequel choisir ? Pour une application de plusieurs services décrite dans un compose.yaml, déployée par une équipe qui connaît Docker, Docker Engine reste le plus simple : tout est intégré et documenté. Podman se justifie quand la sécurité prime (pas de démon root ni de socket à protéger), sur les distributions Red Hat où il est l'outil fourni, ou pour des services isolés gérés par systemd. Au BTS, savoir argumenter ce choix compte plus que l'outil retenu.

podman-compose ou docker compose ? podman-compose est une réécriture en Python de Compose, disponible dans les dépôts de Debian (sudo apt install podman-compose) : il lance les services directement avec Podman et suffit pour un fichier simple, mais il ne prend pas en charge toute la spécification Compose. Pour un fichier riche (conditions depends_on, profils, secrets…), la solution la plus fidèle consiste à activer l'API compatible de Podman (systemctl --user enable --now podman.socket) et à y brancher le vrai Compose de Docker, en indiquant le socket dans DOCKER_HOST (unix://$XDG_RUNTIME_DIR/podman/podman.sock). Dans les deux cas, podman compose choisit lui-même l'outil installé.

LXC et Incus : des conteneurs système

Docker et Podman font tourner des conteneurs d'application : un processus principal, une application. LXC fait tourner des conteneurs système : un système Linux complet, avec son init (systemd), ses services, ses comptes, qu'on administre comme une petite VM, mais qui partage le noyau de l'hôte. Ce sont les CT de Proxmox VE. Incus, issu de LXD, ajoute une gestion confortable des conteneurs système et des VM, en ligne de commande et par une API.

Kubernetes et Docker Swarm : orchestrer plusieurs serveurs

Docker et Compose gèrent les conteneurs d'un seul hôte. Quand une application doit tourner sur plusieurs serveurs, survivre à la panne de l'un d'eux, s'étendre automatiquement selon la charge et se mettre à jour sans coupure, il faut un orchestrateur :

Pour une PME comme Sorbier, avec quelques applications internes, Compose sur une VM bien sauvegardée suffit largement ; la disponibilité vient de Proxmox (redémarrage de la VM sur un autre nœud). Kubernetes apporte beaucoup, mais demande des compétences et une exploitation à la hauteur : c'est un projet en soi.

Choisir

Exercices