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 !