Containers sans Docker : Podman, Buildah, distroless (2026)
Meta-description : En 2026, Docker n’est plus un monopole : Podman daemonless rootless, Buildah build-only, Skopeo et les images distroless/Wolfi forment un écosystème complet et plus sécurisé. Guide exhaustif avec tutoriels pratiques, adaptation Afrique de l’Ouest et FAQ.
Introduction — L’écosystème containers en 2026
Pendant près d’une décennie, Docker a défini ce que signifie « faire tourner un container ». L’image mentale est devenue un réflexe : on installe Docker, on écrit un Dockerfile, on tape docker run. Cette hégémonie était compréhensible — Docker a popularisé les containers et forgé la majorité des conventions de l’industrie. Mais en 2026, cette équation n’est plus aussi évidente qu’elle le paraît.
Le paysage a profondément changé. Podman, développé par Red Hat et la communauté containers, a atteint la version 5.8.2 avec une maturité indiscutable. Buildah permet de construire des images OCI sans aucun daemon en arrière-plan. Skopeo manipule les registres d’images sans même avoir à télécharger un runtime complet. Et les images distroless, promues par Google Container Tools et désormais portées à un niveau supérieur par Chainguard avec sa distribution Wolfi, remettent en question la convention qui consiste à embarquer un système d’exploitation complet dans chaque image.
Ce guide général vous donne une vision exhaustive de cet écosystème. Il ne s’agit pas de « remplacer Docker à tout prix » — Docker reste un outil valide dans beaucoup de contextes. L’objectif est de comprendre pourquoi et quand les alternatives apportent un avantage concret, de maîtriser chaque outil dans ses forces propres, et de savoir les assembler en une chaîne de production de containers cohérente, sécurisée et efficace. Une attention particulière est portée au contexte ouest-africain, où les contraintes de bande passante, de serveurs partagés et de conformité réglementaire rendent certains de ces choix encore plus pertinents qu’ailleurs.
Pourquoi sortir de Docker en 2026 ?
La question mérite d’être posée honnêtement avant d’aller plus loin. Docker n’est pas mort et n’est pas fondamentalement mauvais. Mais plusieurs raisons objectives poussent les équipes techniques à diversifier leur outillage containers en 2026.
Le problème du daemon root persistant
Docker repose sur un daemon (dockerd) qui s’exécute en permanence avec les privilèges root. Ce daemon écoute sur un socket Unix (/var/run/docker.sock) accessible à quiconque appartient au groupe docker. Cela signifie concrètement qu’un utilisateur membre du groupe docker dispose d’un accès root effectif à la machine — il peut monter n’importe quel répertoire de l’hôte, modifier des fichiers système, lancer des processus privilégiés. Les équipes de sécurité Red Hat ont documenté que les containers Docker reçoivent par défaut 14 capacités kernel, contre 11 pour Podman en mode rootless. Ce n’est pas anodin dans un contexte où le principe du moindre privilège est au cœur de toute politique de sécurité sérieuse.
Un daemon root persistant est également un point de défaillance unique. Si ce processus plante, tous les containers tombent avec lui. Podman, par contraste, ne maintient pas de processus parent — chaque container est un processus indépendant forké directement depuis le shell de l’utilisateur, rattaché à son propre conmon (container monitor). Un container qui échoue n’affecte pas les autres.
Le modèle de licence de Docker Desktop
En 2022, Docker Inc. a modifié les conditions d’utilisation de Docker Desktop, le rendant payant pour les entreprises de plus de 250 employés ou générant plus de 10 millions de dollars de revenus annuels. Si Docker CLI et le daemon restent open source sous licence Apache 2.0, Docker Desktop — qui est l’interface principale sur macOS et Windows — est soumis à une licence commerciale. Pour les équipes qui travaillent sur ces systèmes, cette contrainte a accéléré l’évaluation d’alternatives comme Podman Desktop, qui est entièrement libre et gratuit.
La fragmentation de la chaîne de build
Dans Docker, le build d’image et le runtime des containers sont couplés dans un seul outil. C’est pratique pour démarrer rapidement, mais cela crée une dépendance lourde : pour construire une image en CI, il faut souvent un « Docker-in-Docker » ou monter le socket Docker, deux approches qui sont soit lentes, soit dangereuses du point de vue de la sécurité. Buildah, conçu spécifiquement pour le build d’images, s’exécute sans daemon, sans socket, avec les permissions de l’utilisateur courant. Dans un pipeline GitLab CI ou GitHub Actions sur un runner partagé, c’est une différence fondamentale.
La surface d’attaque des images standard
Une image Docker basée sur Debian ou Ubuntu embarque des centaines de packages que votre application n’utilisera jamais — des éditeurs de texte, des outils réseau, des compilateurs, des bibliothèques partagées. Chacun de ces packages est une surface d’attaque potentielle. Les audits de sécurité montrent régulièrement que des images populaires sur Docker Hub contiennent des dizaines de CVE critiques non patchées. Les images distroless poussent cette logique à l’extrême : elles contiennent uniquement l’application et ses dépendances directes de runtime, sans shell, sans gestionnaire de paquets, sans aucun utilitaire système. L’image gcr.io/distroless/static-debian12 pèse environ 2 MiB — à comparer avec les 124 MiB d’une image Debian standard.
La maturité de l’écosystème alternatif
En 2020, recommander Podman en production était courageux. En 2026, c’est mainstream. Red Hat Enterprise Linux 8 et 9 ont adopté Podman comme runtime de containers par défaut. Fedora, CentOS Stream, openSUSE et Arch Linux intègrent Podman nativement. Podman Desktop offre une parité quasi-complète avec Docker Desktop en termes d’interface graphique. La compatibilité avec l’API Docker est suffisante pour que la quasi-totalité des workflows existants fonctionnent sans modification avec alias docker=podman. Ce n’est plus un pari sur l’avenir — c’est un choix technique solide et bien supporté.
Les 4 outils fondamentaux
Podman — daemonless et rootless
Podman (POD MANager) est un moteur de containers open source maintenu par la communauté containers, avec Red Hat comme principal contributeur. La version stable actuelle est la 5.8.2 (avril 2026). Son architecture se distingue de Docker sur un point fondamental : il n’y a pas de daemon.
Quand vous tapez podman run nginx, aucun processus en arrière-plan n’est consulté. Podman appelle directement les syscalls Linux nécessaires (namespaces, cgroups, seccomp) via la bibliothèque libpod, fork un processus conmon pour surveiller le container, et retourne. Si vous fermez votre terminal, le container continue via conmon, mais Podman lui-même n’existe plus en mémoire. C’est le contraire exact du modèle Docker où dockerd est toujours là, root, à écouter.
Le mode rootless est la configuration par défaut de Podman depuis la version 3. Dans ce mode, Podman utilise les user namespaces Linux pour simuler les privilèges root à l’intérieur du container tout en restant un processus non-privilégié sur l’hôte. Le processus container pense être root (UID 0) à l’intérieur du namespace, mais depuis la perspective du kernel, il s’exécute avec l’UID de l’utilisateur courant. Si ce processus s’échappe du container, il ne peut pas toucher les fichiers root de l’hôte.
Podman est 100 % compatible avec le format d’images OCI (Open Container Initiative) et peut lire les images Docker Hub sans aucune conversion. La commande podman compose (via le plugin podman-compose) permet d’utiliser les fichiers docker-compose.yml existants. L’API REST que Podman expose est compatible avec l’API Docker, ce qui permet à des outils comme Portainer ou VS Code Dev Containers de fonctionner avec Podman comme backend.
Une fonctionnalité phare de Podman est son intégration avec systemd via Quadlet. Quadlet permet de définir des units systemd qui décrivent un container Podman avec une syntaxe dédiée (.container, .pod, .network). systemd gère alors le cycle de vie du container exactement comme il gère un service classique — démarrage automatique au boot, redémarrage en cas d’échec, logging via journald, intégration avec systemctl. Pour les déploiements sur VPS sans orchestrateur Kubernetes, c’est une alternative très élégante à Docker Compose avec ses limitations.
Podman supporte également les pods — groupes de containers partageant le même namespace réseau et IPC — qui reproduisent le concept de Pod Kubernetes. La commande podman generate kube peut exporter la description d’un pod Podman en YAML Kubernetes valide, facilitant la migration vers un cluster K8s le moment venu.
Buildah — build sans daemon
Buildah est un outil dédié à la construction d’images OCI, sans runtime de containers et sans daemon. La version 1.39.0 a été publiée en février 2025 sur buildah.io. Là où Podman est un runtime complet, Buildah est focalisé sur une seule mission : créer des images.
Buildah peut lire et exécuter un Dockerfile standard (buildah build -f Dockerfile .), mais il offre également une interface de scripting plus fine qui permet de construire une image couche par couche avec des commandes shell ordinaires. Cette approche scriptée évite les couches intermédiaires qui gonflent les images Docker classiques : avec Buildah, vous pouvez installer des outils de build, compiler votre application, puis les désinstaller dans le même bloc de commandes sans créer de couche intermédiaire volumineuse.
L’avantage clé de Buildah en CI/CD est qu’il ne nécessite ni socket Docker, ni privilèges root, ni montage de volume Docker-in-Docker. Sur un runner GitLab partagé ou un GitHub Actions runner, vous installez simplement le binaire Buildah et vous pouvez builder des images OCI en user mode. C’est un gain de sécurité substantiel : le runner n’a pas accès au daemon Docker de l’hôte, le blast radius d’une éventuelle compromission est réduit à l’espace utilisateur du job.
Buildah produit des images entièrement conformes à la spécification OCI Image Layout, ce qui garantit leur compatibilité avec n’importe quel runtime conforme : Podman, containerd, CRI-O, ou même Docker. Une image construite avec Buildah peut être poussée sur Docker Hub, GHCR, Quay.io ou tout registre OCI sans transformation.
Buildah s’intègre nativement avec Podman : les deux outils partagent le même store d’images locales (~/.local/share/containers/storage/). Une image construite avec Buildah est immédiatement disponible pour podman run sans aucune commande supplémentaire. Cette complémentarité fait que dans un workflow typique, Buildah gère le build et Podman gère le run — chaque outil faisant ce pour quoi il a été conçu.
Skopeo — gestion d’images sans runtime
Skopeo (du grec skopéo : observer de loin) est l’outil de la famille containers dédié à la manipulation des images et des registres. La version stable actuelle est la v1.22.1. Sa philosophie est radicalement différente des autres outils : Skopeo peut inspecter, copier, signer et supprimer des images de registres OCI sans jamais avoir besoin d’un runtime de containers sur la machine.
La commande skopeo inspect permet d’inspecter le manifeste et les métadonnées d’une image distante sans la télécharger : vous obtenez la liste des couches, les labels, la date de création, les variables d’environnement exposées et l’architecture cible — tout cela avec une simple requête HTTP sur le registre. C’est particulièrement utile dans un contexte de bande passante contrainte : vous vérifiez qu’une image est bien celle attendue avant de la télécharger.
La commande skopeo copy copie une image d’une source vers une destination sans passer par le store local. Vous pouvez copier directement d’un registre vers un autre (docker://source → docker://destination), d’un registre vers un répertoire local (docker://source → dir:/path), ou même entre formats différents (OCI layout, Docker archive). Pour les déploiements en environnement isolé (air-gapped), Skopeo est l’outil standard pour créer une bibliothèque locale d’images sans nécessiter Docker.
Skopeo supporte nativement la vérification de signatures via cosign et sigstore. Quand vous travaillez avec des images Chainguard — qui sont toutes signées par cosign avec des clés éphémères — Skopeo permet de vérifier ces signatures avant de copier l’image dans votre registre interne. C’est un maillon essentiel d’une chaîne de sécurité de la supply chain logicielle.
Dans le contexte d’un pipeline CI/CD structuré, Skopeo joue typiquement le rôle de « douanier des images » : il vérifie, copie et promeut les images entre registres (du registre de dev vers le registre de staging, puis vers la production) sans jamais avoir besoin de les exécuter. Cette séparation des rôles renforce la sécurité et simplifie les permissions nécessaires dans chaque environnement.
Distroless, Wolfi et Chainguard — images minimales
Le concept d’image distroless a été popularisé par Google Container Tools en 2017 et est maintenu activement sur github.com/GoogleContainerTools/distroless. L’idée est simple à énoncer mais radicale dans ses implications : une image de production ne devrait contenir que ce qui est strictement nécessaire pour faire tourner l’application — et rien d’autre.
Une image Debian standard fait 124 MiB. Elle contient bash, coreutils, apt, des bibliothèques partagées, des utilitaires réseau, un éditeur vi minimal. Tout cela est utile pour un environnement interactif, mais dans un container de production, c’est une surface d’attaque inutile. L’image gcr.io/distroless/static-debian12, la plus minimale des images distroless, fait environ 2 MiB. Elle contient uniquement les bibliothèques C de base et les certificats CA — rien de plus. L’image gcr.io/distroless/base-debian12 (qui inclut glibc pour les binaires compilés dynamiquement) fait environ 20 MiB.
L’absence de shell dans les images distroless est à la fois leur force et leur principal point de friction. Un attaquant qui parviendrait à exécuter du code arbitraire dans votre container distroless ne trouverait pas de /bin/sh pour lancer d’autres commandes. Pas de curl pour exfiltrer des données. Pas de gestionnaire de paquets pour installer des outils malveillants. Le container devient littéralement imperméable aux techniques d’exploitation classiques basées sur un shell interactif. En contrepartie, le debug en production est beaucoup plus complexe — il faut des outils de debug externes (comme les ephemeral debug containers de Kubernetes) plutôt que de se connecter directement au container.
Wolfi et Chainguard poussent ce concept encore plus loin. Wolfi est un nouveau Linux undistro (une distribution sans distribution au sens traditionnel) conçu spécifiquement pour les containers, développé par Chainguard et publié en open source. Contrairement aux images distroless de Google qui sont basées sur Debian, Wolfi est construit from scratch avec une philosophie container-native : chaque package est construit avec des provenance attestations SLSA Level 3, les images sont signées par cosign, et des SBOM (Software Bill of Materials) sont générées automatiquement pour chaque image.
Chainguard publie plus de 2 000 images basées sur Wolfi (edu.chainguard.dev), couvrant la quasi-totalité des runtimes et frameworks populaires : Python, Node.js, Go, Java, Nginx, PostgreSQL, Redis, etc. Ces images sont reconstruites nativement depuis les sources chaque nuit, ce qui signifie que les CVE sont patchés dans un délai de quelques heures après la publication du correctif upstream. Là où une image Docker Hub standard peut accumuler des dizaines de CVE critiques non patchés pendant des semaines, une image Chainguard vise le zéro CVE connu au moment de sa construction. En mai 2025, Chainguard a également introduit des images multi-couches pour mieux gérer les applications complexes tout en maintenant cette garantie de sécurité.
Le modèle économique de Chainguard est dual : les images de base (:latest) sont gratuites pour une utilisation personnelle et open source, tandis que les variantes taggées (:1.21, avec support étendu et SLA) sont commerciales. Pour une PME africaine qui déploie en production, les images gratuites couvrent la majorité des besoins — et représentent déjà un gain de sécurité considérable par rapport aux images Docker Hub standard.
Architecture rootless containers
Comprendre l’architecture rootless est fondamental pour exploiter correctement Podman et Buildah. Le rootless ne signifie pas « moins de fonctionnalités » — il signifie une isolation différente et plus fine, basée sur les primitives de sécurité Linux modernes.
La pierre angulaire des containers rootless est le mécanisme des user namespaces Linux, disponible depuis le kernel 3.8 et stabilisé dans les kernels 4.x. Un user namespace crée une mapping entre les UIDs vus à l’intérieur du container et les UIDs réels sur l’hôte. Typiquement, l’UID 0 (root) à l’intérieur du container est mappé vers votre UID utilisateur (par exemple 1000) sur l’hôte. Le processus container croit être root, mais le kernel sait qu’il est en réalité l’utilisateur 1000 — avec toutes les restrictions qui y sont associées.
Cette mapping est définie dans les fichiers /etc/subuid et /etc/subgid, qui assignent à chaque utilisateur une plage d’UIDs/GIDs « subordonnés » qu’il peut utiliser pour ses user namespaces. Une configuration typique ressemble à :
# /etc/subuid
diallo:100000:65536
# /etc/subgid
diallo:100000:65536Cela signifie que l’utilisateur diallo peut mapper les UIDs 100000 à 165535 de l’hôte vers les UIDs 0 à 65535 dans ses containers. Les processus qui s’exécutent avec l’UID 5000 dans un container s’exécutent en réalité avec l’UID 105000 sur l’hôte — un UID sans aucun droit particulier.
Pour le stockage des images et des couches, Podman en mode rootless utilise par défaut ~/.local/share/containers/storage/ dans le répertoire home de l’utilisateur. Pas besoin de partition séparée, pas de sudo pour inspecter ce qui est stocké. Le store est entièrement sous le contrôle de l’utilisateur. Le driver de stockage recommandé est overlay avec fuse-overlayfs pour les systèmes qui ne supportent pas l’overlay natif en user mode.
Pour le réseau, Podman rootless utilise par défaut slirp4netns (ou son successeur plus performant pasta depuis Podman 5), qui implémente une stack TCP/IP complète en espace utilisateur. Le container obtient une connectivité réseau complète sans aucun privilège kernel. La performance réseau est légèrement inférieure à celle du mode root (où Podman utilise Netavark avec des interfaces réseau kernel directes), mais l’écart est négligeable pour la quasi-totalité des workloads applicatifs.
Un point d’attention important : en mode rootless, les ports inférieurs à 1024 (les « ports privilégiés ») ne peuvent pas être bindés directement dans un container, car cela nécessite la capability CAP_NET_BIND_SERVICE. La solution standard est d’utiliser des ports supérieurs à 1024 dans le container (port 8080, 8443) et de gérer la redirection vers 80/443 au niveau du proxy inverse sur l’hôte. Si vous avez absolument besoin de binder un port privilégié, vous pouvez ajuster le paramètre kernel net.ipv4.ip_unprivileged_port_start à une valeur inférieure via sysctl.
L’intégration systemd avec Quadlet complète cette architecture en gérant le cycle de vie des containers sans daemon. Un fichier ~/.config/containers/systemd/mon-app.container suffit à décrire un container géré par systemd en user mode. Le service démarre automatiquement à la connexion de l’utilisateur (avec loginctl enable-linger) et redémarre en cas d’échec, exactement comme un service système classique, mais sans aucun privilège root.
Articles de la série DevOps avancé
Ce guide général est le hub du cluster devops-avance sur itskillscenter.io. Chaque tutoriel articles connexes approfondit un sous-sujet spécifique avec un guide pas-à-pas complet. Les tutoriels suivants sont planifiés et en cours de rédaction :
-
Tutoriel 1 — Migrer de Docker à Podman sur un VPS Ubuntu
Guide pas-à-pas pour remplacer Docker par Podman sur un serveur Ubuntu 24.04 LTS : installation, configuration rootless, migration des containers existants, adaptation des scripts de démarrage, Quadlet systemd. Idéal pour les sysadmins qui maintiennent des VPS Hetzner ou DigitalOcean. -
Tutoriel 2 — Construire des images distroless avec Buildah en CI/CD
Workflow complet de construction d’images distroless avec Buildah dans un pipeline GitLab CI ou GitHub Actions : configuration du runner sans Docker, multi-stage build, choix de la bonne image de base distroless/Wolfi, push sur un registre privé avec Skopeo, vérification de signature cosign.
D’autres tutoriels sont prévus dans ce cluster, notamment sur l’utilisation de Podman Desktop comme alternative à Docker Desktop, sur la gestion de registres OCI privés avec Skopeo, et sur l’intégration de Chainguard Images dans un pipeline de sécurité de la supply chain.
Adaptation au contexte ouest-africain
Les outils présentés dans ce guide général ne sont pas seulement intéressants en théorie — ils répondent à des problèmes concrets que rencontrent les développeurs et sysadmins d’Afrique de l’Ouest au quotidien. Voici pourquoi Podman, Buildah, Skopeo et les images distroless sont particulièrement pertinents dans ce contexte.
Sécurité accrue sur les VPS partagés Hetzner et OVH
La grande majorité des déploiements de PME africaines repose sur des VPS entrée de gamme chez Hetzner, OVH, DigitalOcean ou Contabo — des machines partagées avec un seul utilisateur root par défaut. Le profil de risque de ces environnements est différent d’un serveur bare metal dédié : le fournisseur peut accéder à la machine, les hyperviseurs sont partagés, et le niveau de durcissement par défaut est minimal.
Dans ce contexte, le mode rootless de Podman est une protection non négligeable. Si un container est compromis (une vulnérabilité dans une dépendance, une mauvaise configuration), le processus attaquant se retrouve avec les droits de l’utilisateur Unix courant — il ne peut pas écrire dans /etc, ne peut pas lire /root, ne peut pas modifier les règles iptables. Avec Docker en mode standard, une évasion de container donne accès root à la machine entière via le socket Docker. Cette différence n’est pas théorique : les attaques de cryptomineurs exploitant des sockets Docker exposés sont documentées par des dizaines de rapports de sécurité depuis 2019.
Pour une startup sénégalaise ou ivoirienne qui héberge ses données clients sur un VPS partagé, adopter Podman rootless n’est pas un luxe tech — c’est une mesure de sécurité minimale cohérente avec une politique de protection des données sérieuse.
Images distroless et économies de bande passante en 4G
La connectivité internet en Afrique de l’Ouest s’est considérablement améliorée ces dernières années, mais la bande passante reste un facteur à optimiser, notamment pour les développeurs qui travaillent sur des connexions 4G mobiles ou des connexions ADSL avec des débits asymétriques. Déployer des images Docker standard de 800 MiB ou 1 GiB sur un serveur distant consomme du temps et de l’argent — surtout quand ces déploiements sont fréquents dans un pipeline CI/CD actif.
Les images distroless changent radicalement cette équation. L’image de base gcr.io/distroless/static-debian12 (~2 MiB) ou gcr.io/distroless/base-debian12 (~20 MiB) est téléchargée en quelques secondes même sur une connexion 4G limitée. Une image applicative Python distroless typique (application + dépendances runtime) se situe entre 50 et 150 MiB selon les bibliothèques utilisées — contre 400 à 800 MiB pour son équivalent basé sur python:3.12-slim. Sur une journée de déploiements actifs avec 20 déploiements, cela peut représenter plusieurs gigaoctets d’économies.
Skopeo joue également un rôle important ici : sa capacité à inspecter une image distante sans la télécharger permet de vérifier rapidement qu’une image a bien été mise à jour avant de déclencher un pull complet. Dans un contexte de bande passante coûteuse, éviter les téléchargements inutiles est une optimisation concrète et immédiate.
Wolfi et la conformité pour les audits ARTCI et BCEAO
L’Autorité de Régulation des Télécommunications et des TIC de Côte d’Ivoire (ARTCI) et les régulations de la BCEAO pour les acteurs fintech imposent des exigences croissantes en matière de sécurité des systèmes d’information. Les audits de conformité demandent de plus en plus souvent une justification des choix techniques en matière de gestion des vulnérabilités logicielles.
Les images Chainguard basées sur Wolfi facilitent considérablement ces exercices de conformité. Chaque image publie automatiquement un SBOM complet (liste de tous les packages inclus avec leurs versions), une attestation de provenance SLSA Level 3 (qui prouve que l’image a bien été construite depuis les sources sans modification), et une signature cosign vérifiable. Lors d’un audit, vous pouvez démontrer précisément ce que contient chaque image en production, prouver qu’elle a été construite de manière reproductible, et montrer que le délai de patch des CVE connus est inférieur à 24 heures grâce aux rebuilds nocturnes. C’est un niveau de transparence et de traçabilité que les images Docker Hub standard ne peuvent tout simplement pas offrir.
Pour les équipes africaines qui cherchent à se certifier ISO 27001 ou à répondre aux exigences de la directive sur la cybersécurité de la CEDEAO, intégrer Wolfi/Chainguard dans la chaîne de build est un investissement qui simplifie directement les processus d’audit et réduit la surface de risque documentable.
Erreurs fréquentes à éviter
| Erreur | Cause | Solution |
|---|---|---|
| Container distroless impossible à débugger en prod | Absence de shell et d’outils (bash, curl, ps) dans l’image de production. Les équipes tentent un docker exec -it container bash et obtiennent une erreur. |
Utiliser les ephemeral debug containers de Kubernetes (kubectl debug) ou ajouter temporairement une variante :debug (disponible pour les images distroless de Google et Chainguard) qui inclut busybox uniquement pour le debug. |
| Ports privilégiés non bindables en rootless | Podman rootless ne peut pas binder les ports <1024 par défaut. Tentative de mapper le port 80 de l'hôte vers le port 80 du container échoue silencieusement ou avec une erreur de permission. | Utiliser des ports >1024 dans le container (ex: 8080) et gérer la redirection 80→8080 au niveau du proxy inverse (nginx, Caddy) sur l’hôte. Alternativement, ajuster sysctl net.ipv4.ip_unprivileged_port_start=80. |
| Volume mount avec mauvais propriétaire | En rootless, les UIDs à l’intérieur du container (ex: UID 1000 interne) ne correspondent pas aux UIDs de l’hôte à cause du mapping des user namespaces. Les fichiers créés dans un volume monté apparaissent avec un UID étrange sur l’hôte. | Utiliser podman unshare chown UID:GID /path/to/volume pour re-chown le répertoire dans le contexte du user namespace, ou utiliser l’option :Z pour les volumes SELinux. Consulter podman unshare pour explorer le namespace utilisateur actif. |
| Buildah qui échoue en CI avec « overlay not supported » | Sur certains runners CI qui sont eux-mêmes des containers (Docker-in-Docker), l’overlay filesystem en mode user n’est pas supporté car le kernel ne l’autorise pas dans un user namespace imbriqué. | Configurer Buildah pour utiliser le driver vfs (--storage-driver vfs) en CI, ou activer fuse-overlayfs si le runner supporte FUSE. Accepter la légère dégradation de performance du driver vfs en CI où la vitesse de build compte moins que la fiabilité. |
| Skopeo copy qui échoue sur des registres avec auth | Skopeo nécessite des credentials explicites pour les registres privés. Contrairement à Docker, il ne lit pas automatiquement ~/.docker/config.json dans tous les cas d’usage. |
Utiliser l’option --src-creds user:token et --dest-creds user:token, ou créer un fichier auth.json compatible OCI avec skopeo login et le référencer via la variable d’environnement REGISTRY_AUTH_FILE. |
| Image Wolfi/Chainguard avec dépendance manquante | Les images Chainguard sont très minimales par conception. Une application qui assume la présence de bibliothèques système communes (tzdata, ca-certificates, locale) peut échouer au démarrage car ces packages ne sont pas toujours présents dans la variante de base. | Utiliser un multi-stage build : étape de build sur une image complète, étape finale sur l’image Chainguard. Copier explicitement les fichiers de dépendances nécessaires (COPY --from=build /usr/share/zoneinfo /usr/share/zoneinfo). Consulter la liste des packages inclus dans chaque image via skopeo inspect avant de baser dessus. |
| Conteneurs Podman qui ne démarrent pas après reboot | Sans Quadlet ou configuration systemd explicite, les containers Podman rootless ne redémarrent pas automatiquement après un reboot. L’utilisateur suppose que le comportement est similaire à docker run --restart always. |
Configurer Quadlet avec une unit .container dans ~/.config/containers/systemd/ et activer loginctl enable-linger username pour que les services utilisateur démarrent au boot sans connexion interactive. Vérifier avec systemctl --user status mon-app.service. |
FAQ
Q : Podman est-il 100 % compatible avec Docker ?
La compatibilité est très élevée mais pas absolue. La commande alias docker=podman fonctionne pour la grande majorité des usages courants : run, build, pull, push, exec, logs, ps, etc. L’API REST de Podman est compatible avec l’API Docker, ce qui permet à des outils comme Portainer, Podman Desktop et VS Code Dev Containers de fonctionner. Les différences notables concernent les comportements réseau en mode rootless (pas de bridge partagé entre containers par défaut sans pod), la gestion des volumes (UIDs différents en rootless), et certaines options avancées de docker build non supportées par la couche de compatibilité. Pour un nouveau projet, Podman est un choix direct. Pour une migration d’un projet existant complexe avec Docker Compose et networking custom, un test de bout en bout est recommandé avant de basculer en production.
Q : Les images distroless sont-elles compatibles avec toutes les applications ?
Non, pas directement dans tous les cas. Les images distroless sont idéales pour les applications qui produisent un binaire statique (Go, Rust) ou qui fonctionnent avec un runtime bien défini (JVM, Node.js, Python). Les applications qui ont des dépendances implicites sur des outils système (scripts shell, commandes exec vers des binaires système, accès à /proc ou /sys de manière non standard) nécessiteront des ajustements. La technique standard est le multi-stage build : construire dans une image complète, puis copier uniquement les artefacts de production dans une image distroless. Le principal défi est le debug en production — il faut renoncer à exec bash et utiliser des outils de debug externes ou les variantes :debug qui incluent busybox.
Q : Quelle est la différence entre les images distroless de Google et les images Chainguard/Wolfi ?
Les deux approches partagent la philosophie de la minimalité, mais diffèrent dans leur implémentation. Les images distroless de Google (github.com/GoogleContainerTools/distroless) sont basées sur Debian et construites avec Bazel — elles sont très matures, très testées, et gratuites sans restriction. Chainguard/Wolfi part de zéro avec une distribution Linux conçue spécifiquement pour les containers, avec des garanties de provenance SLSA L3, des rebuilds nocturnes garantissant un délai de patch CVE minimal, des SBOMs natifs et des signatures cosign. Les images Chainguard offrent davantage de garanties de sécurité de la supply chain et sont disponibles en variantes taggées avec support commercial. Pour un usage open source ou personnel, les deux sont excellents ; pour une conformité stricte avec audit, Chainguard offre une traçabilité supérieure.
Q : Peut-on utiliser Podman sans root sur un hébergeur mutualisé ou un VPS d’entrée de gamme ?
Sur un VPS (KVM ou XEN), oui — le kernel Linux complet est disponible avec les user namespaces activés, ce qui est la condition minimale pour Podman rootless. Sur un hébergement mutualisé classique (cPanel, Plesk), non — vous n’avez pas accès à un vrai shell système avec les droits suffisants. Vérifiez que votre VPS tourne sur Ubuntu 22.04/24.04 LTS ou Debian 12 (les distributions modernes activent les user namespaces par défaut), que /proc/sys/kernel/unprivileged_userns_clone retourne 1 (sur Ubuntu), et que les entrées /etc/subuid et /etc/subgid existent pour votre utilisateur. Sur les VPS Hetzner Cloud avec Ubuntu 24.04, Podman rootless fonctionne sans configuration supplémentaire après installation.
Q : Buildah peut-il remplacer complètement Docker pour le build dans un pipeline CI/CD ?
Oui, c’est précisément son cas d’usage principal. Buildah construit des images OCI conformes depuis un Dockerfile ou Containerfile standard, sans daemon et sans privilèges root. Les images résultantes sont poussées sur n’importe quel registre OCI (Docker Hub, GHCR, Quay.io, GitLab Container Registry) via buildah push ou skopeo copy. La configuration d’un runner GitLab ou GitHub Actions avec Buildah ne nécessite pas de monter le socket Docker de l’hôte et ne requiert pas de runner Docker-in-Docker (DinD). C’est plus sûr, plus simple à configurer, et souvent plus rapide car les layers sont mis en cache dans le store local du runner. La principale limitation est que Buildah est disponible principalement sur Linux — sur des runners macOS ou Windows, vous devrez utiliser une VM Linux ou rester sur Docker Desktop.
Q : Skopeo peut-il gérer des registres privés auto-hébergés (Harbor, Gitea) ?
Oui, Skopeo supporte n’importe quel registre compatible avec la spécification OCI Distribution (anciennement Docker Registry API v2), ce qui inclut Harbor, Gitea Container Registry, Quay.io auto-hébergé, Nexus et Artifactory. L’authentification est gérée via skopeo login registry.exemple.com (qui stocke le token dans un fichier auth.json) ou en passant les credentials directement avec les flags --src-creds et --dest-creds. Skopeo gère également les registres avec des certificats TLS auto-signés via le flag --tls-verify=false ou en ajoutant le certificat CA dans /etc/containers/certs.d/registry.exemple.com/. Pour les déploiements avec un registre privé Harbor sur un VPS africain (pour éviter les frais de bande passante liés aux téléchargements répétés depuis Docker Hub), Skopeo est l’outil idéal pour synchroniser les images entre Docker Hub et votre registre interne.
Q : Ces outils fonctionnent-ils sur ARM64 (Raspberry Pi, serveurs Ampere) ?
Oui. Podman, Buildah et Skopeo sont disponibles en binaires natifs ARM64 pour les distributions Linux principales. Les images distroless de Google et les images Chainguard publient des manifests multi-architectures (multi-arch) qui incluent AMD64 et ARM64 — skopeo inspect vous montrera les architectures disponibles pour n’importe quelle image. Sur des serveurs Ampere Altra (comme ceux disponibles chez Hetzner en CAX series ou OVH) qui offrent un excellent rapport performance/prix pour les workloads serveur, toute la stack Podman+Buildah+distroless fonctionne nativement sans émulation. C’est une configuration de plus en plus adoptée par les équipes qui cherchent à réduire leur facture cloud tout en conservant des performances élevées.
Pour aller plus loin
Ressources officielles
- podman.io — site officiel Podman, documentation, guides de démarrage rapide, Podman Desktop
- buildah.io — site officiel Buildah, notes de version, tutoriels de build avancé
- github.com/containers/skopeo — code source Skopeo, documentation complète des commandes
- github.com/GoogleContainerTools/distroless — images distroless de Google, liste complète des images disponibles, politique de support
- edu.chainguard.dev — catalogue des images Chainguard/Wolfi, documentation sur le zéro CVE, guides SLSA et SBOM
- docs.podman.io — documentation technique complète de Podman, référence des commandes
Articles de la série à lire ensuite
- Tutoriel : Migrer de Docker à Podman sur un VPS Ubuntu — guide pas-à-pas pour la migration en production (à venir sur itskillscenter.io)
- Tutoriel : Construire des images distroless avec Buildah en CI/CD — pipeline GitLab/GitHub Actions complet sans Docker (à venir sur itskillscenter.io)
Formations ITSkillsCenter associées
ITSkillsCenter propose des formations DevOps pratiques couvrant la conteneurisation avancée, le déploiement sur VPS avec Podman et Quadlet, et la sécurisation de la chaîne de build. Ces formations sont conçues spécifiquement pour le contexte technique et budgétaire de l’Afrique de l’Ouest. Consultez le catalogue de formations sur itskillscenter.io.
Par où commencer ?
Si vous débutez avec cet écosystème, voici la progression recommandée : commencez par installer Podman sur votre machine de développement et vérifiez que vos workflows Docker habituels fonctionnent avec l’alias podman. Ensuite, explorez Buildah pour comprendre la construction d’images sans daemon — testez un build simple de votre application. Ajoutez Skopeo pour gérer vos images de registre à registre. Enfin, convertissez votre image de production vers une base distroless ou Chainguard pour réduire sa surface d’attaque. Ce chemin progressif vous permet d’adopter chaque outil à votre rythme sans rupture brutale dans vos workflows existants.