Les builders d'images OCI, 6 alternatives à Docker

mars 01, 2021

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 et BuildKit

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 :

  • La parallélisation des builds multi-stage,  cet article  décrit assez bien cette fonctionnalité.
  • L’intégration des Docker secrets dans l’étape de build ( docs )

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

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

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

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

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

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.


Conclusion

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  !


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: