Les containers engines : Podman, l'alternative à Docker

févr. 17, 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 16 févr., 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.
Airflow PostgreSQL MongoDB
par Ikram Zouaoui 07 févr., 2024
Integration de technologies pour optimiser les flux de travail : L'article met en lumière une approche combinée utilisant Airflow, PostgreSQL, et MongoDB pour améliorer l'efficacité des flux de travail liés aux données.
Show More
Share by: