Les containers engines : Podman, l'alternative à Docker

17 février 2021

Nous avons vu dans  le premier article de cette série  ce qu’est un conteneur applicatif et les différentes catégories d’outils qui permettent de manipuler ces conteneurs. Aujourd’hui nous allons nous intéresser à Docker Engine et ses alternatives dans la catégorie des container engines.

Un container engine est une véritable boîte à outils qui permet de faire de nombreuses actions avec les conteneurs : construire une image (build), lancer un conteneur (run), télécharger une image depuis un registre d’images comme  Docker Hub  ou  Quay.io  (pull), et bien d’autres. C’est l’outil idéal pour son poste de travail.

Dans cet article nous commencerons par nous intéresser à Docker Engine et les composants qui le constituent. Nous verrons ensuite son principal concurrent dans cette catégorie, Podman. Il existe également  PouchContainer  d’Alibaba Group, mais celui-ci ne semble pas très actif et la communauté pas très anglophone.



Les rouages de Docker Engine


On ne présente plus Docker Engine, il est la référence incontournable sur le domaine des conteneurs. En revanche, on connaît moins les briques qui le constituent.

Docker Engine est constitué de deux composants majeurs distincts :

  • Le serveur, le daemon dockerd
  • Le CLI docker.

Les deux communiquent entre eux via une API REST. Le daemon se charge de toutes les opérations concrètes, que se soit sur les images, les conteneurs, les volumes et le réseau.

Depuis  Docker Engine 1.11 (2016) , le daemon dockerd n’est plus monolithique, il utilise le daemon  containerd  et le runtime OCI  runc . Et depuis  la release 18.09 , Docker peut utiliser  BuildKit  pour construire les images. Il y a d’autres composants comme  SwarmKit , mais nous n’en parlerons pas ici, ce sont des fonctionnalités propres à Docker qui n’ont pas forcément d’alternatives directes.

Containerd a la même architecture client-serveur que Docker Engine avec un daemon, containerd, qui peut être contrôlé depuis un CLI, ctr, ou le plus souvent via son API  GRPC . Containerd est un  runtime de haut niveau , en tant que tel il ne permet pas de toutes les fonctionnalités de Docker Engine et le CLI n’a pas pour but d’être utilisé en production non plus. Il faut voir Containerd comme un composant sur lequel bâtir d’autres produits.  Ce tableau  donne une idée de ce que Containerd permet de faire directement et de ce que l’on peut faire en se servant de Containerd comme brique de base. Vous pouvez voir ci-dessous les briques qui le composent et l’écosystème autour. 

Source :  containerd.io

Runc est le runtime OCI par défaut de containerd, et donc par extension de Docker Engine. Nous consacrerons un article complet sur les runtime OCI.

BuildKit est une nouvelle implémentation qui remplace le builder original de Docker pour de meilleures performances et quelques fonctionnalités supplémentaires. Il n’est pas activé par défaut pour le moment. Nous avons d’ailleurs consacré un article complet sur les  builders d’image  !

On peut voir que Docker Engine n’est plus le monolithe qu’il était, ça lui permet de pouvoir faire évoluer indépendamment chaque brique. Et nous allons voir que certaines de ces briques sont utilisées par d’autres outils.

Passons maintenant la main à Podman, le nouveau venu au gros potentiel.

Podman, l’alternative rootless et daemonless


Podman est une implémentation daemonless et rootless de container engine créé par Red Hat. Podman est basé sur les standards de l’OCI et son CLI est compatible avec celui de docker, au point où son adoption est aussi simple que d’exécuter : alias docker=podman.

Le fait qu’il puisse fonctionner en mode rootless et qu’il soit daemonless le rend plus sécurisé par nature comparé à Docker Engine. Il est également plus facile de l’installer sur un poste de travail sans droits d’administration.

Podman n’est pas non plus un monolithe, en interne il utilise  Buildah  pour construire les conteneurs, et  crun  comme runtime OCI par défaut. Il s’agit d’un runtime similaire à runc, mais il est plus performant ( d’après Red Hat ), car écrit en C plutôt que Go.

Certaines fonctionnalités de Docker Engine, comme le  mode Swarm , ne sont pas disponibles dans podman.

Il n’est pas non plus possible d’utiliser  Docker compose  avec podman. Il existe bien  podman compose , mais je déconseille son utilisation en production. Il est préférable de se tourner vers des solutions comme  K3s  ou simplement des services Systemd simples pour déployer de petites applications.

En revanche Podman apporte d’autres fonctionnalités intéressantes comme :

L’adoption de Podman peut permettre une transition plus facile vers Kubernetes, notamment grâce aux pods et à la génération des manifests Kubernetes. Évidemment la génération de manifestes permet de mettre le pied à l’étrier mais ne dispense pas le développeur de connaissances sur l’écriture de ces manifestes.

Il est prévu que Podman et CRI-O  partagent la même codebase  (libpod) pour les fonctions similaires. Ainsi le même code permettrait de faire tourner des conteneurs à la fois sur un poste de travail et dans un cluster Kubernetes.

Voici un blog post de Red Hat qui introduit Podman et Buildah pour aller plus loin :  Podman and Buildah for Docker users . Et un tutoriel pour débuter avec Podman :  Transitioning from Docker to Podman .

Conclusion


Comme nous avons pu le voir, Docker Engine n’est pas le seul container engine sur le marché.

Docker Engine est bien installé et a défriché le terrain pour les alternatives maintenant stables. Son découpage en composants comme containerd et runc permet aussi à d’autres produits de voir le jour.

Podman est un concurrent sérieux puisqu’il permet de lancer des conteneurs rootless et daemonless, tout en gardant une compatibilité avec le CLI docker pour une migration toute en douceur.

En attendant le prochain épisode, n’hésitez pas à aller consulter nos précédents articles sur Docker, les conteneurs et l’Open Container Initiative (OCI), les builders d’images OCI : 6 alternatives à Docker mais aussi celui sur comment adopter une approche Kubernetes First !

Ressources Agaetis

par David Walter 28 août 2025
Le contexte du projet Un grand groupe du secteur de l’énergie en France cherchait à exploiter les données massives issues des compteurs Linky. L’ambition : concevoir une plateforme dédiée au développement et au déploiement de micro-applications , tout en s’appuyant sur une infrastructure technique avancée et une méthodologie agile pour soutenir cette transformation. L’objectifs L’objectif principal était de créer un environnement robuste et évolutif permettant : d’analyser efficacement les données des points de mesure du réseau, de faciliter le développement rapide de micro-services, et de renforcer l’agilité des équipes grâce à des pratiques modernes de CI/CD. Durée de missions Plusieurs mois d’intervention , mobilisant les expertises Agaetis en infrastructure, automatisation et méthodes agiles pour cadrer, déployer et stabiliser la plateforme. Mise en oeuvre Pour atteindre ces objectifs, Agaetis a mis en place une approche complète : Installation et configuration d’infrastructure : mise en place d’un cluster Kafka/Mesos/Hadoop pour le traitement massif des données. Automatisation et scalabilité : développement de rôles Ansible pour permettre l’auto-scaling du cluster Mesos/Marathon/Zookeeper , assurant une gestion simplifiée par les équipes d’exploitation. Conseil en méthodologies agiles : alignement de la conception et du développement des micro-services avec les meilleures pratiques agiles. CI/CD intégrée : mise en œuvre de pipelines d’intégration, de livraison et de déploiement continus avec Jenkins et GitLab . Résultat obtenu La solution déployée a permis : la mise en place d’une plateforme analytique robuste pour interpréter efficacement les données Linky, une infrastructure flexible et évolutive , garantissant une gestion optimale des ressources, une accélération du développement grâce à l’adoption de méthodologies agiles, une amélioration significative des processus CI/CD , renforçant la productivité et la qualité des livrables. Facteurs clés de succès Expertise technique des équipes Agaetis sur les environnements distribués complexes. Automatisation et scalabilité intégrées dès la conception, facilitant l’exploitation à long terme. Adoption des méthodologies agiles , renforçant la collaboration et la rapidité d’exécution. Partenariat de confiance avec le client, assurant une solution sur mesure et durable. Et vous ? Vous vous interrogez sur : la valorisation de vos données métiers, la mise en place d’une infrastructure évolutive pour vos applications, ou l’intégration de méthodologies modernes pour accélérer vos projets IT ? 👉 Contactez nos experts pour découvrir comment Agaetis peut transformer vos défis en leviers d’innovation.
par David Walter 28 août 2025
Le contexte du projet Platform Garden , une startup internationale, souhaitait exploiter ses données pour créer de la valeur et renforcer sa stratégie d’innovation. L’enjeu majeur était d’exploiter la data visualization et d’identifier comment les données existantes et futures pouvaient ouvrir de nouvelles opportunités de croissance . L’objectifs Les ambitions principales de Platform Garden étaient de : analyser et enrichir un gisement de données sur les plantes et arbustes, valoriser ces données en développant de nouveaux services et fonctionnalités, et intégrer efficacement ces données dans les systèmes existants tout en optimisant les coûts technologiques et financiers. Durée de missions Mission en plusieurs phases , de l’idéation jusqu’au développement de nouvelles fonctionnalités, en accompagnement continu avec les équipes de Platform Garden. Mise en oeuvre Agaetis a déployé une approche progressive et collaborative : Phase d’idéation et cadrage des besoins : animation d’ateliers pour qualifier et prioriser les attentes de Platform Garden. Recherche et analyse des sources de données : exploration des données existantes et évaluation de leur pertinence pour l’intégration dans l’écosystème de la startup. Développement de nouvelles fonctionnalités : conception de services innovants, tels que des algorithmes prédictifs, afin d’exploiter pleinement la valeur des données collectées. Résultat obtenu La mission a permis : Enrichissement du gisement de données : une base de données plus complète, ouvrant la voie à de nouvelles découvertes et usages. Création de valeur et nouveaux services : développement de fonctionnalités inédites comme Jardi’Alerte ou le futur Végéscore , offrant un avantage compétitif. Innovation continue : mise en place d’un processus évolutif, garantissant une adaptation constante aux technologies et aux besoins du marché. Facteurs clés de succès Approche agile et progressive d’Agaetis. Ateliers collaboratifs favorisant l’alignement des besoins et des priorités. Expertise data et innovation appliquée à un domaine spécifique et émergent. Capacité à transformer la donnée en services concrets , différenciants pour les clients finaux. Et vous ? Vous vous interrogez sur : la valorisation de vos données pour créer de nouveaux services, l’intégration de fonctionnalités prédictives dans vos produits, ou la mise en place d’une stratégie d’innovation data adaptée à votre secteur ? 👉 Contactez nos experts pour transformer vos données en leviers de croissance et d’innovation.
Show More