Dans les deux premiers épisodes de cette série d’articles sur les conteneurs, nous avons fait un petit tour  des conteneurs applicatifs en général , puis des  container eng ines avec Docker et Podman .

Les containers engines sont très bien pour le poste de travail : ils permettent de tout faire avec un seul outil. En revanche dans d’autre cas, mettons dans une étape d’un pipeline de CI/CD, nous ne voulons rien faire d’autre que construire une image de conteneur avant de la pousser dans un registre d’image. Et pour cet usage, de nombreux outils autre que Docker ont fait leur apparition. Nous allons donc parler des builders.

Nous commencerons par Docker, l’incontournable et son nouveau composant en charge de la construction de conteneurs : BuildKit. Nous regarderons ensuite quelques alternatives plus légères et plus appropriées dans un contexte de CI/CD : Kaniko, umoci, Buildah et img. Enfin nous jetterons un coup d’œil sur des plugins d’outils de build plus généraux avec Jib (Maven/Gradle) et Bazel.

Docker permet de construire des images de conteneur à l’aide de la commande  docker build , et depuis la release 18.09, il est possible d’utiliser  BuildKit  à cet effet.

BuildKit est un outil à part entière qui peut être utilisé seul (avec le CLI  buildctl  et le daemon  buildkitd ) mais qui est également  embarqué dans Docker  lui-même. Pour l’activer, rien de plus simple, il suffit de lancer son build avec la variable d’environnement  DOCKER_BUILDKIT=1 . Ne soyez pas surpris, par défaut les logs sont un peu différents du docker build “legacy”.

BuildKit apporte quelques fonctionnalités supplémentaires :

BuildKit peut aussi être utilisé avec les commandes   docker buildx , même si ces commandes sont encore considérées comme expérimentales.  Buildx  permet d’utiliser toutes les fonctionnalités de BuildKit, comme la possibilité créer des instances de builders séparées pour éviter le partage d’une seule et même instance pour tous les builds.

Maintenant que nous avons vu ce que permet de faire docker, intéressons nous aux alternatives, et pour commencer, Kaniko.

Kaniko  est un outil open source développé par Google pour construire des images à partir de Dockerfile et depuis un conteneur, sans avoir accès à un daemon Docker. Par conséquent, il permet de construire une image depuis un conteneur dans un cluster Kubernetes par exemple.

L’utilisation est plutôt simple puisque tout se passe dans le conteneur avec l’image officielle  gcr.io/kaniko-project/executor  et en une étape qui rassemble les étapes habituelles de pull, build et push.

Par défaut, Kaniko permet de construire une image depuis un dossier local, donc un dossier dans le conteneur ou un volume monté dans le conteneur. Mais il est aussi possible de construire une image depuis un blob storage (AWS S3, Azure Blob Storage, GCS Bucket) ou un dépôt git directement.

Il est aussi possible de  configurer du cache  pour accélérer les pipelines de CI/CD.

Cet outil est très facile à mettre en place dans un environnement de CI/CD comme  Gitlab CI  ou  Github Actions .

umoci  est l’implémentation de référence de l’ OCI image , il est conçu pour être minimal afin de pouvoir plus facilement s’intégrer dans un système plus gros. Par conséquent, il n’est pas forcément très “user-friendly” et manque des fonctionnalités des autres builder comme le push et pull vers une registry par exemple. Il permet également de construire des images en mode  rootless .

Il est mentionné ici à titre indicatif et puisqu’il s’agit de l’implémentation de référence. C’est aussi un bon moyen de comprendre les arcanes de la construction d’image sans avoir à lire le code source d’un autre builder.

Buildah  est le cousin de  Podman , container engine dont nous avons parlé dans  l’épisode précédent . Comme Podman, il n’a pas besoin de daemon et peut fonctionner en mode rootless. C’est un outil développé par Red Hat qui permet, entre autres, de construire des images OCI de  façon classique à partir d’un manifeste Dockerfile , via la commande  buildah bud .

Mais la fonctionnalité la plus intéressante est de créer une image à partir d’un filesystem. Grosso modo il permet de créer une image à partir d’un dossier. Ce qui est très pratique pour créer des image from scratch, c’est-à-dire que contrairement à la majorité des images de nos jours, on peut créer une image distroless qui ne contient que le strict minimum, donc pas forcément d’outils systèmes comme un shell ou un package manager (e.g.  yum  ou  apt ), puisque que l’on peut utiliser le package manager de la machine hôte pour installer des packages dans le dossier qui servira comme base de la future image. Voici un exemple utilisant dnf pour installer bash dans un conteneur “nu”, tiré de la  documentation de buildah  :

# Crée le conteneur nu, “from scratch”, avec juste quelque métadonnées

$> newcontainer=$(buildah from scratch)

# Monte le conteneur dans un dossier

$> scratchmnt=$(buildah mount $newcontainer)

# Installe bash et coreutils dans le conteneur

$> dnf install --installroot $scratchmnt --releasever 33 bash coreutils --setopt install_weak_deps=false -y

# Démonte le conteneur

$> buildah unmount $newcontainer

# Commit le conteneur pour pour créer l’image fedora-basheco

$> buildah commit $newcontainer fedora-bashecho

umoci permet de créer des images OCI de la même façon mais l’expérience utilisateur n’est pas la même puisque buildah va abstraire tout ce qu’il peut pour rendre l’expérience la plus fluide possible, quand umoci se contentera du minimum.

L’intérêt de buildah par rapport à Kaniko dans un système de CI/CD est limité pour le cas d’usage classique à partir d’un Dockerfile. En revanche, buildah est un outil clairement intéressant pour la création d’image “from scratch”.

img  est un builder daemonless et rootless qui utilise une partie de BuildKit en interne, sans pour autant dépendre du daemon  buildkitd .

Comme BuildKit, il permet d’effectuer des étapes de builds en parallèle pour les multi-stage builds. Les options du CLI  img  sont similaires à celles du CLI  docker  pour les actions de build, pull et push. Du point de vue de l’utilisateur, l’expérience est donc tout à fait similaire à celle de Docker.

img est donc un bon candidat pour remplacer facilement docker dans un système de CI/CD déjà en place afin de bénéficier du mode rootless par exemple.

Jib  et  Bazel  sont des cas particuliers de builders : se sont des plugins d’outils de build plus généraux. En effet, Jib est un plugin pour  Maven  et  Gradle , quand  Bazel  est un outil de build plus général qui dispose de son propre plugin pour construire des images Docker et OCI.

Ces deux outils permettent de construire des images OCI et Docker rootless et daemonless. Le gros point fort étant l’intégration avec l’outil de build dont ils sont le plugin. Il est donc très facile pour un utilisateur de Maven de construire une image Docker avec Jib.

Le deuxième avantage c’est l’utilisation d’images  distroless  par défaut, c’est-à-dire des images qui ne contiennent que le strict minimum : pas de shell ou de package manager.

Ces deux outils sont à privilégier pour les utilisateurs de Maven et Bazel. Ils permettent de construire des images très facilement et de façon complètement intégré au processus de build habituel.

Dans certains contextes, comme dans un environnement de CI/CD, un outil léger et dédié à la construction d’images Docker ou OCI est plus approprié que Docker ou Podman.

Nous avons vu que Docker et BuildKit permettent quelques améliorations par rapport à la construction de conteneur par défaut de Docker, notamment la construction en parallèle de multi-stage images, mais ils nécessitent des daemons.

umoci est intéressant pour comprendre la mécanique de construction d’une image, mais est un peu trop minimaliste pour être utilisé en mode standalone.

Kaniko permet de facilement construire une image de conteneur depuis un conteneur sans privilèges et daemonless.

img permet de construire des images avec la même syntaxe que le CLI Docker et en étant aussi efficace que BuildKit sans pour autant nécessiter de daemon et sans privilèges.

Enfin Jib (Maven/Gradle) et Bazel permettent d’intégrer la construction d’image dans un outils de build plus généraliste, et ainsi obtenir une intégration tout en douceur dans un système existant.

Nous avons vu que dans la catégorie des builders, Docker n’est clairement plus hégémonique non plus. Dans le prochain article nous ferons un tour d’horizon des runtime OCI.

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 container engines : Podman, l’alternative à Docker mais aussi celui s ur   comment adopter une approche Kubernetes First  !