Réduire le Build Time Docker à 5 min

Vous souhaitez maitriser tous les secrets des images et des builds ? Notre formation Docker vous permettra de devenir complètement opérationnel sur l’outil et automatiser le déploiement de vos conteneurs applicatifs

L’équipe Ambient IT

BuildKit VS Buildx

Pour commencer, il faut nous poser la question : quelle différence entre Buildkit et Buildx ?

Beaucoup d’utilisateurs de Docker considèrent que ce sont 2 termes désignent la même chose, mais cela n’est absolument pas le cas.

Buildkit

Expliqué simplement, Buildkit est un backend amélioré pour la construction d’images Docker. Il est conçu à la base pour remplacer l’ancien constructeur docker.

Le rôle principal de BuildKit est de prendre en charge les scénarios de construction et d’en améliorer les performances. Il est capable de détecter et de sauter des étapes de construction inutiles, transférer des fichiers modifiés de manière incrémentale ou même de gérer des constructions en parallèle.

Buildkit est également un compagnon de choix pour la gestion du stockage en limitant les exécutions inutiles.

Pour résumer, il faut voir Buildkit comme une infrastructure améliorant les performances et les capacités au-delà de l’ancien constructeur de Docker.

BuildX

BuildX est quant à lui un plugin CLI permettant d’étendre les capacités de Docker en utilisant les outils fournis par Buildkit. Les deux outils sont donc intrinsèquement liés, mais la différence est bien réelle.

Buildx permet de créer des images pour plusieurs plateformes simultanément, de réaliser des constructions en plusieurs étapes dans un seul fichier. Buildx permet donc une expérience utilisateur similaire à celle de Docker Build, mais en y ajoutant les fonctionnalités offertes par BuildKit.

Buildx est donc un ajout extrêmement intéressant à Buildkit, car il offre un retour à une interface plus familière ainsi que des fonctionnalités supplémentaires telles que les constructions multiplateformes et les environnements de construction isolés.

Réduire le Build Time

Maintenant que nous avons vu la différence (et le lien) entre Buildkit et Buildx, nous pouvons maintenant voir quelques techniques nous permettant de réduire le build time.

Remote Cache

Mettre ses images Docker dans un registre cache distant est l’une des méthodes les plus efficaces pour réduire son build time. Cela est particulièrement vrai dans les pipelines CI/CD et les environnements distribués.

Le cache « registry » peut être vu comme une extension du cache « inline« . Il est entièrement séparé de l’image, ce qui le rend bien plus flexible. Avec cette méthode, vous pouvez séparer le cache et les artefacts de l’image résultante, de mettre en cache efficacement les constructions en plusieurs étapes en mode max, et de travailler avec différents exportateurs. À noter qu’il vous faut un pilote différent du pilote Docker par défaut.

Pour configurer le cache, vous pouvez utiliser ceci :

docker buildx build --push -t <registry>/<image> \
  --cache-to type=registry,ref=<registry>/<cache-image>[,parameters...] \
  --cache-from type=registry,ref=<registry>/<cache-image> .

Cette commande pousse l’image en cache et la déplace dans le registre spécifié. À partir de là, vous pourrez mettre en œuvre les mode de mises en cache « inline » et registre.

Le mode « inline » met en cache les couches résultantes, mais toujours en mode « min« . Cela limite donc les couches exportées et mises en cache.

Le mode registre offre une plus grande précision en mettant en cache toutes les couches intermédiaires en « max« . Ce mode vous permet de créer deux images : une pour la mise en cache et une autre pour l’image résultante utilisée pour le déploiement.

La commande pour le mode registre devrait ressembler à peu près à ça :

--cache-from=type=registry,ref=$IMAGE_NAME-build-cache \
--cache-to=type=registry,ref=$IMAGE_NAME-build-cache,mode=max

Pour une gestion plus facile de vos images, je vous recommande chaudement de privilégier ce mode.

Attention tout de même, cette méthode peut causer des problèmes avec certains services cloud qui peuvent ne pas supporter le format de métadonnées utilisé par Buildx.

Commandes Copy et ADD

Docker a récemment introduit une nouvelle syntaxe pour les dockerfiles : syntax=docker/dockerfile:1.4. Elle apporte de nombreuses options de liens supplémentaires pour les commandes COPY et ADD.

Traditionnellement, lorsque vous utilisiez la commande COPY ou ADD, le constructeur créait un nouvel instantané, qui fusionnait les nouveaux fichiers avec le système de fichiers existants. Cela impliquait que toutes les couches parentes devaient exister avant que cette opération puisse être effectuée, sinon le répertoire de destination était introuvable (car non existant).

Le résultat final de cette commande est une série d’instantanés par couche, contenant la différence entre les snapshots respectifs.

Avec l’option de liaison, les nouveaux fichiers sont placés dans leur propre instantané, tous liés ensembles sans dépendre du système de fichier existant.

L’avantage majeur de cette méthode est que les fichiers ne dépendent plus des couches précédentes. Elles peuvent donc être réutilisées tant que les fichiers restent identiques, même si les couches parentes ont changé.

Conclusion

Il existe énormément de méthodes pour diminuer le temps de vos builds time et la clé pour les trouver est l’expérimentation. Même si chaque équipe et chaque cas est unique, les techniques que nous vous avons présentées dans cet article sont des méthodes approuvées qui marcheront pour la grande majorité des utilisateurs Docker.