Comparaison des solutions de conteneurisation¶

Choisir le bon runtime de conteneurs selon le contexte projet : critères objectifs, forces et faiblesses de chaque solution.

Contexte de la décision¶

Ce tutoriel utilise Podman comme runtime de conteneurisation. Ce choix n'est pas anodin : il résulte d'une analyse comparative des principales solutions disponibles en 2025. Cette page documente cette analyse au format ADR afin de tracer la décision et ses motivations.

Grille de comparaison¶

Critère	Podman	Docker	containerd	CRI-O	LXC/LXD
Licence	Apache 2.0	Apache 2.0	Apache 2.0	Apache 2.0	LGPL 2.1 / Apache 2.0
Rootless natif		(depuis 20.10)	partiel
Daemonless		daemon dockerd	daemon containerd	daemon crio	daemon lxd
Compatibilité CRI Kubernetes	via CRI-O	via cri-dockerd
Support Compose	podman-compose	docker compose
Conformité OCI	natif				format propre
Intégration systemd	podman generate systemd	unit custom	unit custom	socket-activated
Empreinte ressources	Faible (pas de daemon)	Moyenne (daemon permanent)	Faible	Faible	Variable
Modèle de sécurité	SELinux, user namespaces, seccomp	seccomp, AppArmor	seccomp, AppArmor	SELinux, seccomp	AppArmor, seccomp
Maturité écosystème	Haute (Red Hat, RHEL 9+)	Très haute (standard de facto)	Haute (CNCF graduated)	Haute (CNCF graduated)	Moyenne

Analyse détaillée¶

Podman¶

Podman est un runtime OCI sans daemon qui exécute chaque conteneur comme un processus fils direct. Il supporte le mode rootless nativement depuis sa conception, ce qui élimine le vecteur d'attaque principal des runtimes à daemon (escalade de privileges via le socket).

Forces :

• Compatible CLI Docker (alias docker=podman)
• Génération de fichiers systemd intégrée
• Outils compagnons : Buildah (build), Skopeo (registre)
• Adopte par Red Hat comme runtime par défaut sur RHEL 9 et dérivés

Limites :

• Écosystème Compose moins mature que Docker Compose
• Certains outils tiers supposent la présence du socket Docker

Docker¶

Docker reste le standard de facto pour le développement local et les pipelines CI/CD. Son écosystème est le plus riche : Docker Desktop, Docker Hub, extensions, intégrations IDE.

Forces :

• Écosystème et communauté les plus larges
• Docker Compose V2 intégré en plugin natif
• Documentation abondante

Limites :

• Daemon dockerd tournant en root par défaut
• Docker Desktop soumis a licence commerciale (entreprises > 250 employés)
• Le shim CRI (cri-dockerd) est deprecated pour Kubernetes

containerd¶

containerd est un runtime de bas niveau extrait de Docker. Il sert de couche d'exécution sous Docker et comme runtime CRI pour Kubernetes.

Forces :

• Projet CNCF graduated, très stable
• Runtime CRI par défaut de la plupart des distributions Kubernetes managées
• API gRPC extensible via plugins (snapshotter, etc.)

Limites :

• Pas d'interface utilisateur ni de Compose
• Nécessite nerdctl pour une expérience CLI comparable a Docker
• Daemon permanent requis

CRI-O¶

CRI-O est un runtime dédié Kubernetes : il implémente uniquement l'interface CRI, rien de plus. Il est optimise pour les clusters de production.

Forces :

• Surface d'attaque minimale (pas de fonctionnalités superflues)
• Aligné sur les versions Kubernetes (versionning 1:1)
• Intégration SELinux poussée

Limites :

• Inutilisable en dehors de Kubernetes
• Pas de CLI interactive, pas de Compose
• Adoption limitée hors OpenShift / RHEL

LXC/LXD¶

LXC/LXD fournit des conteneurs système : des machines virtuelles légères qui exécutent un init complet (systemd) plutôt qu'un unique processus applicatif.

Forces :

• Idéal pour virtualiser un OS complet sans hyperviseur
• Gestion déclarative via profils LXD
• Snapshots et migration live

Limites :

• Pas conçu pour les conteneurs applicatifs (pas OCI)
• Images non compatibles Docker Hub / registres OCI
• Canonical a transféré LXD a Incus (fork communautaire)

Décision¶

Choix retenu : Podman

Motivation¶

Pour un déploiement serveur en production sur AlmaLinux 9, Podman est le choix le plus adapte :

1. Rootless natif — réduit la surface d'attaque sans configuration supplémentaire
2. Daemonless — pas de processus permanent a surveiller, chaque conteneur est un processus indépendant
3. Intégration systemd — génération automatique des units, activation socket, compatibilité lingering
4. Compatibilité Docker — migration transparente des docker-compose.yml existants
5. Support Red Hat — runtime par défaut sur RHEL 9 et dérivés (AlmaLinux, Rocky Linux)

Alternatives acceptables¶

Conséquences¶

• Les fichiers Compose utilisent la syntaxe Docker standard
• Les services systemd sont générés via podman generate systemd
• Les images proviennent de registres OCI (Docker Hub, Artifactory)
• L'équipe doit connaître les quelques différences Podman/Docker (réseau, volumes :Z)

Statut¶

Accepte — applique dans ce tutoriel.