Dans les temps anciens des conteneurs (c’est vraiment plus comme il y a 4 ans) Docker était le seul acteur de jeu l’univers des containers. Aujourd’hui Docker n’est plus seul, c’est juste un moteur à conteneurs dans le paysage.
Docker permet de construire, exécuter, recupérer, pousser ou inspecter des images de conteneurs, et pour chacune de ces tâches il y a d’autres alternatives, qui font un souvent meilleur travail que Docker. Alors, explorons le paysage et (juste peut-être) désinstaller et oublier Docker définitivement …
Alors pourquoi arrêter, sans mauvaise surprise
Why Not Use Docker, Though?
Si vous êtes un utilisateur de docker depuis longtemps, je pense qu’il vous faudra un peu de persuasion pour que vous envisagiez de passer a quelques choses de différents outils. Alors, voilà :
First of all, Docker is a monolithic tool. It’s a tool that tries to do everything, which generally is not the best approach. Most of the time it’s better to choose a specialized tool that does just one thing, but does it really well.
If you are scared of switching to different set of tools, because you would have to learn to work with different CLI, different API or in general different concepts, then that won’t be a problem. Choosing any of the tools shown in this article can be completely seamless as they all (including Docker) adhere to same specification under OCI, which is short for Open Container Initiative. This initiative contains specifications for container runtime, container distribution and container images, which covers all the features needed for working with containers.
Thanks to the OCI you can choose a set of tools that best suit your needs and at the same time you can still enjoy using the same APIs and same CLI commands as with Docker.
So, if you’re open to trying out new tools, then let’s compare the advantages, disadvantages and features of Docker and it’s competitors to see whether it actually makes sense to even consider ditching Docker for some new shiny tool.
Cependant, Pourquoi ne pas utiliser Docker ?
l y a plusieurs raisons pour ne pas utiliser Docker. Tout d’abord, il peut être surdimensionné pour certains cas d’utilisation simples et peut être difficile à gérer pour les utilisateurs qui ne sont pas familiers avec la technologie. De plus, Docker nécessite l’exécution d’un démon qui fonctionne en tant que super-utilisateur, ce qui peut présenter des risques de sécurité. Enfin, certaines entreprises peuvent être préoccupées par l’utilisation de technologies propriétaires comme Docker.
Cependant, noter que Docker reste une technologie de conteneurisation bien établie, et que de nombreuses entreprises l’utilisent dans leurs environnements de développement et de production. Il est important de peser les avantages et les inconvénients de Docker et d’autres technologies de conteneurisation pour déterminer celle qui convient le mieux à vos besoins spécifiques.
Voici quelques arguments pour vous faire envisager de changer :
Tout d’abord, Docker est un outil monolithique. C’est un outil qui essaie de tout faire, ce qui n’est généralement pas la meilleure approche. Souvent, il est préférable de choisir un outil spécialisé qui fait une chose, et la fait vraiment bien.
Tout va bien se passer, si vous êtes confortable à l’idée de passer à un ensemble d’outils différents, de devoir apprendre à travailler avec différents CLI, d’utiliser des jeux API différents et de manipuler des concepts différents, alors ce ne sera pas un problème.
Le choix de l’un des outils présentés dans cet article peut être complètement transparent car tous adhèrent (y compris Docker) aux mêmes spécifications OCI ( Open Container Initiative). Cette initiative porte les spécifications relatives au temps d’exécution des conteneurs, la distribution de conteneurs et les images de conteneurs, elle couvre toutes les fonctionnalités nécessaires pour travailler avec les conteneurs. Grâce au OCI, choisir un ensemble d’outils adaptés à vos besoins et profiter de l’utilisation des mêmes API et des mêmes commandes CLI qu’avec Docker.
Si vous êtes ouvert à essayer de nouveaux outils, comparons les avantages, les inconvénients et les caractéristiques de Docker et de ses concurrents. Voyons s’il est réellement logique d’envisager d’abandonner Docker pour un nouvel outil.
Container Engines
Pour comparer Docker avec d’autres outils, nous devons considéré ses deux composantes. La première à considérer est les « container engines ». Un container engine est un outil qui fournit une interface utilisateur pour travailler avec des images et des conteneurs, de sorte que vous n’ayez pas à manipuler des éléments tels que les règles SECCOMP ou les politiques SELinux. Son travail consiste également à récupérer des images à partir de référentiels distants et à les étendre sur votre disque. Il semble également exécuter les conteneurs, mais en réalité, son travail est de créer une manifestation de conteneur et un répertoire avec des couches d’image. Il les passe ensuite à un « container runtime » comme runc ou crun (que nous aborderons un peu plus tard).
Il existe de nombreux « container engines » disponibles, mais le concurrent le plus important de Docker est Podman, développé par Red Hat. Contrairement à Docker, Podman n’a pas besoin d’un démon pour fonctionner et n’a pas besoin de privilèges root, ce qui a été une préoccupation de longue date avec Docker. Basé sur le nom, Podman peut non seulement exécuter des conteneurs, mais également des « pods ». Dans le cas où vous n’êtes pas familier avec le concept de « pods », un « pod » est l’unité de calcul la plus petite pour Kubernetes. Il se compose d’un ou plusieurs conteneurs – le principal et les « sidecars » – qui effectuent des tâches de support. Cela facilite la migration ultérieure des charges de travail des utilisateurs de Podman vers Kubernetes. Ainsi, pour une démonstration simple, voici comment vous exécuteriez deux conteneurs dans un seul « pod »:
Enfin, Podman fournit exactement les mêmes commandes CLI que Docker, vous pouvez donc simplement faire « alias docker=podman » et prétendre que rien n’a changé.
Il existe d’autres « container engines » en dehors de Docker et Podman, mais je considérerais tous ceux-ci comme des technologies mortes ou non adaptées pour le développement et l’utilisation locale. Mais pour avoir une image complète, mentionnons au moins ce qui existe :
LXD — XD est un gestionnaire de conteneurs (démon) pour LXC (Linux Containers). Cet outil offre la possibilité d’exécuter des conteneurs système qui fournissent un environnement de conteneur plus similaire aux machines virtuelles. Il occupe un espace très limité et n’a pas beaucoup d’utilisateurs, donc à moins que vous n’ayez un cas d’utilisation très spécifique, vous êtes probablement mieux loti en utilisant Docker ou Podman.
CRI-O — Lorsque vous recherchez sur Google ce qu’est cri-o, vous pouvez le trouver décrit comme un moteur de conteneur. En réalité, il s’agit d’un environnement d’exécution de conteneurs. En plus du fait qu’il ne s’agit pas vraiment d’un moteur, il n’est pas non plus adapté à une utilisation « normale ». Et par là, je veux dire qu’il a été spécifiquement conçu pour être utilisé comme runtime Kubernetes (CRI) et non pour une utilisation finale par l’utilisateur.
rkt — « rkt (« rocket ») est un moteur de conteneur développé par CoreOS. Ce projet est mentionné ici uniquement pour la complétude, car le projet a pris fin et son développement a été interrompu – et par conséquent, il ne doit pas être utilisé. »
Container Engine
Si l’on compare Docker à d’autre outil, il faut faire les comparaisons par composants.
Le premiert à considérer est le container engine. C’est l’outil qui fournit une interface utilisateur pour gérer les images et les conteneurs afin que vous n’ayez pas à vous préoccuper des choses comme les règles SECCOMP ou les politiques SELinux.
Son travail consiste également à extraire des images de référentiels distants et à les déployer sur votre disque. Il semble aussi faire tourner les conteneurs, en réalité son travail est de créer le manifeste du conteneur et l’annuaire des layers d’image. Il les passe ensuite au moteur d’exécution des conteneurs comme runc ou crun (dont nous parlerons un peu plus tard). Il existe quelques moteurs à conteneurs disponibles, mais le concurrent le plus important de Docker est Podman, développé par Red Hat.
Contrairement à Docker, Podman n’a pas besoin de démon pour fonctionner et n’a pas besoin de privilèges root qui a été une préoccupation de longue date avec Docker. Si on s’en tient à son nom, Podman peut non seulement exécuter des conteneurs, mais aussi des pods (gousses). Dans le cas improbable où vous n’êtes pas familier avec le concept de pods, le pod est la plus petite unité d’excécution pour Kubernetes. Il se compose d’un ou plusieurs conteneurs — le principal et ses sidecars — qui effectuent des tâches annexes. Il est ainsi plus facile pour les utilisateurs de Podman de déplyer vers Kubernetes. Voici une simple démonstration, vous exécuterez 2 conteneurs dans un seul pod:
~ $ podman pod create --name mypod
~ $ podman pod list
podman pod list
POD ID NAME STATUS CREATED # OF CONTAINERS INFRA ID
0c582eede30e mypod Created 17 seconds ago 1 498a9e745d93
~ $ podman run -d --pod mypod nginx # First container
[freebox@Centos ~]$ podman run -d --pod mypod nginx
Trying to pull registry.fedoraproject.org/nginx…
manifest unknown: manifest unknown
Trying to pull registry.access.redhat.com/nginx…
unsupported: This repo requires terms acceptance and is only available on registry.redhat.io
Trying to pull registry.centos.org/nginx…
manifest unknown: manifest unknown
Trying to pull docker.io/library/nginx…
Getting image source signatures
Copying blob af0ff4098771 done
Copying blob a7d674b8e32d done
Copying blob 29ade854e0dc done
Copying blob 0276acf2fece done
Copying blob bccda9008775 done
Copying config d0f910f78b done
Writing manifest to image destination
Storing signatures
9637423c658600ba2c834ff3c1a2c4446f398c9701c92cbc82b924d75f3b76ae
~ $ podman run -d --pod mypod nginx # Second container
~ $ podman ps -a --pod
podman ps -a --pod
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME
96e7dc1c48d8 docker.io/library/nginx:latest nginx -g daemon o… 13 seconds ago Exited (1) 9 seconds ago strange_wilson 0c582eede30e mypod
9637423c6586 docker.io/library/nginx:latest nginx -g daemon o… 3 minutes ago Up 3 minutes ago silly_hypatia 0c582eede30e mypod
498a9e745d93 k8s.gcr.io/pause:3.2 5 minutes ago Up 3 minutes ago 0c582eede30e-infra 0c582eede30e mypod
[freebox@Centos ~]$ Enfin, Podman fournit exactement les mêmes commandes CLI que Docker afin que vous puissiez simplement faire alias docker=podman et prétendre que rien n’a changé.
Il y a d’autres moteurs à conteneurs en plus de Docker et Podman, tous des technologie sans issue et non une option appropriée pour le développement local et l’utilisation. Mais pour avoir une vue complète, mentionnons au moins :
LXD — LXD est gestionnaire de conteneurs (daemon) pour LXC (Linux Containers). Cet outil offre la possibilité d’exécuter des conteneurs système qui fournissent un environnement de conteneur qui est plus similaire aux VMs. Il se trouve dans une petite niche et n’a pas beaucoup d’utilisateurs, donc à moins que vous ayez cas d’utilisation très spécifique, alors c’est probablement mieux d’utiliser Docker ou Podman.
CRI-O — Lorsque vous googelez cri-o, il est décrit comme moteur conteneur. C’est vraiment le moteur d’exécution de conteneur. Il n’est pas adapté à une utilisation « normale ». en effet il a été spécifiquement construit pour être utilisé comme moteur d’exécution Kubernetes (CRI) et non pas pour une utilisation par l’utilisateur final.
Minikube: Utilise CRI-O comme runtime de container
kubeadm: Checkout this kubeadm guide to setup kubeadm to use CRI-O
Kubic: Configured to use CRI-O out of the box in both its kubeadm and microOS system roles
Construire des Images
Avec les moteurs de conteneurs, il n’y avait vraiment qu’une seule alternative à Docker. En revanche, en ce qui concerne la construction d’images, nous avons beaucoup plus d’options parmi lesquelles choisir.
Tout d’abord, permettez-moi de vous présenter Buildah. Buildah est un autre outil développé par Red Hat et il s’intègre très bien avec Podman. Si vous avez déjà installé Podman, vous avez peut-être même remarqué la sous-commande « podman build », qui n’est en fait que Buildah déguisé, car son binaire est inclus dans Podman.
En ce qui concerne ses fonctionnalités, il suit le même chemin que Podman : il est sans démon et sans racine, et produit des images conformes à OCI, il est donc garanti que vos images s’exécuteront de la même manière que celles construites avec Docker. Il est également capable de construire des images à partir de Dockerfile ou (nommé plus approprié) Containerfile, qui est la même chose avec un nom différent. En plus de cela, Buildah offre un contrôle plus fin sur les couches d’image, vous permettant de commettre de nombreux changements dans une seule couche. Une différence inattendue mais (à mon avis) agréable par rapport à Docker est que les images construites par Buildah sont spécifiques à l’utilisateur, de sorte que vous ne pourrez lister que les images que vous avez construites vous-même.
Maintenant, étant donné que Buildah. est déjà inclus dans l’interface en ligne de commande de Podman, vous pourriez vous demander pourquoi utiliser la CLI séparée « buildah » ? Eh bien, la CLI « buildah » est un ensemble de commandes supérieur à celui inclus dans « podman build », vous pourriez donc ne jamais avoir besoin d’utiliser la CLI « buildah », mais en l’utilisant, vous pourriez également découvrir quelques fonctionnalités supplémentaires utiles (pour plus de détails sur les différences entre « podman build » et « buildah », voir l’article suivant)
Construction d’Images
Pour les conteneurs engine, il n’y a en fait vraiment qu’une seule alternative à Docker.
Quand il s’agit de construire des images il existe plus d’options.
Tout d’abord, présentons Buildah. Buildah qui est un autre outil développé par Red Hat et il évidement compléte bien Podman.
Si vous avez déjà installé Podman, vous avez peut-être même remarqué que podman dispose de sous commande de construction d’image qui ne sont que des commandes Buildah déguisé, que son binaire est inclus dans Podman.
Quant à ses fonctionnalités, il suit les mêmes principes que Podman — il est sans démon et sans racine et produit des images conformes au OCI, il est donc garanti que vos images s’exécuteront de la même manière que ceux construits avec Docker.
Il est également capable de construire des images de Dockerfile ou (plus convenablement nommé) Containerfile qui est la même chose avec un nom différent. En dehors de cela, Buildah offre également un contrôle plus fin sur les couches d’image, il vous permettra de faire de nombreux changements en une seule couche.
Une différence inattendue et agréable de Docker est que les images construites par Buildah sont spécifiques à l’utilisateur, de sorte que vous serez en mesure d’énumérer uniquement les images que vous avez construit vous-même.
Maintenant, considérant que Buildah est déjà inclus dans Podman CLI, vous pourriez vous demander pourquoi même utiliser le CLI buildah séparé ?
En fait, le Client buildah CLI est superset de commandes incluses dans la construction podman, de sorte que vous pourriez ne pas avoir besoin de jamais toucher le CLI buildah, mais en l’utilisant, vous pouvez découvrir quelques fonctionnalités supplémentaires utiles.
Alors maintenant, voici une petite demo :
Grâce au script suivant, vous verrez comment construire une image simple en utilisant « buildah bud », où « bud » signifie « construire en utilisant Dockerfile », mais vous pouvez également utiliser une approche plus scriptée en utilisant les commandes « from », « run » et « copy » de Buildah, qui sont des commandes équivalentes aux commandes du Dockerfile (FROM image, RUN…, COPY…).
Ensuite, il y a Kaniko de Google. Kaniko crée également des images de conteneurs à partir d’un Dockerfile, et comme Buildah, il ne nécessite pas de démon. La principale différence avec Buildah est que Kaniko est plus axé sur la création d’images dans Kubernetes.
Kaniko est conçu pour être exécuté en tant qu’image, en utilisant gcr.io/kaniko-project/executor, ce qui est logique pour Kubernetes, mais n’est pas très pratique pour les constructions locales et un peu contre-productif, car vous devrez utiliser Docker pour exécuter l’image Kaniko afin de créer vos images. Cela étant dit, si vous cherchez un outil pour créer des images dans votre cluster Kubernetes (par exemple, dans un pipeline CI/CD), alors Kaniko pourrait être une bonne option, étant donné qu’il est sans démon et (peut-être) plus sécurisé.
D’après mon expérience personnelle, j’ai utilisé à la fois Kaniko et Buildah pour créer des images dans des clusters Kubernetes/OpenShift, et je pense que les deux fonctionneront parfaitement bien. Cependant, avec Kaniko, j’ai constaté des plantages et des échecs aléatoires lors de la publication des images dans le registre.
Le troisième concurrent ici est buildkit, que l’on pourrait également appeler la construction de Docker de nouvelle génération. Il fait partie du projet Moby (tout comme Docker) et peut être activé avec Docker en tant que fonctionnalité expérimentale en utilisant DOCKER_BUILDKIT=1 docker build …. Mais qu’apportera-t-il exactement ? Il introduit une série d’améliorations et de fonctionnalités intéressantes, notamment des étapes de construction parallèles, le saut des étapes inutilisées, de meilleures constructions incrémentales et des constructions sans privilège. En revanche, il nécessite toujours un démon pour fonctionner (buildkitd). Ainsi, si vous ne voulez pas abandonner Docker, mais que vous souhaitez bénéficier de nouvelles fonctionnalités et améliorations intéressantes, alors l’utilisation de buildkit pourrait être la solution.
Comme dans la section précédente, nous avons également quelques « mentions honorables » qui remplissent des cas d’utilisation très spécifiques et qui ne seraient pas mon premier choix.
- Source-To-Image (S2I) est une boîte à outils pour la construction d’images directement à partir du code source, sans avoir besoin de Dockerfile. Cet outil fonctionne bien pour des scénarios et des flux de travail simples et prévisibles, mais il devient rapidement ennuyeux et maladroit si vous avez besoin de trop de personnalisations ou si votre projet n’a pas la mise en page attendue. Vous pourriez envisager d’utiliser S2I si vous n’êtes pas très à l’aise avec Docker, ou si vous construisez vos images sur un cluster OpenShift, car les constructions avec S2I sont une fonctionnalité intégrée.
- Jib est un autre outil de Google, spécifiquement conçu pour la création d’images Java. Il comprend des plugins Maven et Gradle , qui facilitent la création d’images sans avoir à manipuler des Dockerfiles.
- Enfin, Bazel, est un autre outil de Google. Celui-ci n’est pas destiné uniquement à la création d’images de conteneurs, mais sert plutôt de système de construction complet. Si vous ne voulez construire qu’une image, plonger dans Bazel pourrait être un peu trop complexe, mais cela peut être une excellente expérience d’apprentissage. La section « rules_docker » est un bon point de départ pour vous.
Container Runtime
Le Dockerfile est la façon la plus courante de créer un conteneur, mais il est également possible d’utiliser une approche plus scriptée en utilisant les commandes from, run et copy de Buildah, qui sont équivalentes aux commandes du Dockerfile (FROM image, RUN…, COPY…).
Ensuite, il y a Kaniko de Google. Kaniko crée également des images de conteneurs à partir d’un Dockerfile, et comme Buildah, il ne nécessite pas de démon. La principale différence avec Buildah est que Kaniko est plus axé sur la création d’images dans Kubernetes.
Kaniko est conçu pour être exécuté en tant qu’image, en utilisant gcr.io/kaniko-project/executor, ce qui est logique pour Kubernetes, mais n’est pas très pratique pour les constructions locales et un peu contre-productif, car vous devrez utiliser Docker pour exécuter l’image Kaniko afin de créer vos images. Cela étant dit, si vous cherchez un outil pour créer des images dans votre cluster Kubernetes (par exemple, dans un pipeline CI/CD), alors Kaniko pourrait être une bonne option, étant donné qu’il est sans démon et (peut-être) plus sécurisé.
D’après mon expérience personnelle, j’ai utilisé à la fois Kaniko et Buildah pour créer des images dans des clusters Kubernetes/OpenShift, et je pense que les deux fonctionneront parfaitement bien. Cependant, avec Kaniko, j’ai constaté des plantages et des échecs aléatoires lors de la publication des images dans le registre.
Le troisième concurrent ici est buildkit, que l’on pourrait également appeler la construction de Docker de nouvelle génération. Il fait partie du projet Moby (tout comme Docker) et peut être activé avec Docker en tant que fonctionnalité expérimentale en utilisant DOCKER_BUILDKIT=1 docker build …. Mais qu’apportera-t-il exactement ? Il introduit une série d’améliorations et de fonctionnalités intéressantes, notamment des étapes de construction parallèles, le saut des étapes inutilisées, de meilleures constructions incrémentales et des constructions sans privilège. En revanche, il nécessite toujours un démon pour fonctionner (buildkitd). Ainsi, si vous ne voulez pas abandonner Docker, mais que vous souhaitez bénéficier de nouvelles fonctionnalités et améliorations intéressantes, alors l’utilisation de buildkit pourrait être la solution.
Dans la section précédente, nous avons également quelques « mentions honorables » qui remplissent des cas d’utilisation très spécifiques et qui ne seraient pas mon premier choix :
Source-To-Image (S2I) est une boîte à outils permettant de créer des images directement à partir du code source sans utiliser de Dockerfile. Cet outil fonctionne bien pour les scénarios et les flux de travail simples et prévisibles, mais devient rapidement ennuyeux et maladroit si vous avez besoin de trop de personnalisation ou si votre projet n’a pas la disposition attendue. Vous pouvez envisager d’utiliser S2I si vous n’êtes pas très sûr de Docker, ou si vous créez vos images sur un cluster OpenShift, car les constructions avec S2I sont une fonction
