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 :

Le concept de pod emprunté à Kubernetes. Il s’agit d’un groupe de conteneurs qui permet un partage de ressources entre ceux-ci.
La génération de fichiers unit systemd à partir de pods et conteneurs existants.
La génération de manifestes Kubernetes à partir de pods ou de conteneurs existants.
L’auto-update de conteneurs, même lorsque ceux-ci sont gérés par Systemd.

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 !

< Post plus ancien

Post plus récent >

Ressources Agaetis

ORY 4 : L’entrepôt d'Amazon le plus robotisé de France

par Florian Ruynat • 15 mai 2024

Introduction : Florian Ruynat, Architecte Cloud, a récemment réalisé une visite captivante de l'entrepôt ORY4, l'un des complexes les plus automatisés d'Amazon en France. Au cœur de cette installation logistique de 152 000 m², où 3 000 employés orchestrent l'approvisionnement et la préparation des commandes, la technologie de pointe est omniprésente. Cette visite a permis d'explorer les possibilités d'intégration de l'IT moderne dans les usines de quatrième génération via le cloud, avec une attention particulière portée à la gestion proactive des pannes, la surveillance des conditions opérationnelles comme la température, ainsi que la gestion des stocks.

Sora : Transformer les Textes en Scènes Vidéo Réalistes et Imaginatives

par David Walter • 16 février 2024

OpenAI, a récemment dévoilé SORA, un outil de génération de vidéo. SORA monte encore une marche, offrant des capacités de génération de vidéos réalistes. Cet article explore les caractéristiques clés de SORA, son impact potentiel sur diverses industries, les points de réflexions et l'impact pour l'avenir de la création de contenu. Qu'est-ce que SORA ? SORA est une interface avancée conçue par OpenAI qui permet de générer des séquences vidéo à partir de descriptions textuelles simples. Utilisant des techniques de pointe en matière d'intelligence artificielle et d'apprentissage profond, SORA est capable de comprendre des commandes complexes et de les traduire en contenus visuels impressionnants. Une qualité de génération inégalée La capacité de SORA à générer des vidéos époustouflantes souligne un tournant dans le domaine de la production vidéo, où la qualité et la créativité ne sont plus entravées par des contraintes techniques ou financières. Cette avancée s'inscrit dans un contexte plus large où l'IA transforme profondément les industries créatives, offrant des outils puissants pour la transcription, le doublage, la création d'avatars générés par IA, et même la suppression de fonds vidéo, rendant ces processus plus accessibles et flexibles. Des outils comme Descript et Adobe Premiere Pro intègrent des fonctionnalités AI pour améliorer le processus d'édition vidéo, depuis la rotation des yeux jusqu'à la génération de transcriptions et sous-titres. De même, la comparaison entre DALL-E 3 et Midjourney montre comment l'IA peut capturer des détails et des ambiances spécifiques dans les images, un principe également applicable à la vidéo. La révolution du streaming vidéo illustre comment l'adaptation numérique bouleverse les modèles économiques traditionnels, offrant une perspective sur la manière dont les technologies génératives pourraient remodeler le paysage médiatique. L'impact de ces technologies dépasse la simple création de contenu ; elles remodèlent également notre compréhension de la créativité et ouvrent de nouvelles voies pour l'expression artistique et la communication. Avec des outils comme SORA, la barrière entre l'idée et sa réalisation se réduit, permettant à un plus grand nombre de personnes de donner vie à leurs visions créatives sans les contraintes traditionnelles de la production vidéo. Cet élan vers une qualité de génération inégalée par l'IA soulève des questions importantes sur l'avenir du contenu créatif et la manière dont nous valorisons l'interaction entre l'humain et la technologie dans le processus créatif. Alors que nous explorons ces nouvelles frontières, il est crucial de rester attentifs aux implications éthiques et aux défis que ces technologies posent, tout en reconnaissant leur potentiel pour enrichir notre monde visuel et narratif.