Comment utiliser Docker Buildx Bake pour créer des pipelines de construction d’images complexes ?

Le groupe de commandes docker buildx utilise BuildKit pour exposer des capacités avancées de construction d’images. Les builds cuites sont une fonctionnalité de haut niveau qui peut être utilisée pour définir des pipelines de construction automatisés. Elles vous permettent de produire plusieurs images à partir d’une seule opération de construction.

Les flux de travail Baked sont utiles lorsque vous souhaitez publier différentes variantes de vos images ou construire plusieurs projets liés en parallèle. Dans cet article, nous allons couvrir les principales fonctionnalités de docker buildx bake et comment vous pouvez les utiliser pour rationaliser des constructions complexes.

Mise en route

La commande docker buildx bake exécute plusieurs « cibles » de construction qui produisent chacune une image de conteneur. Les cibles s’exécutent en parallèle lorsque cela est possible afin de maximiser les performances. Les cibles peuvent également faire directement référence aux prédécesseurs pour créer des pipelines séquentiels.

Les cibles de construction peuvent être définies à l’aide de plusieurs mécanismes différents, y compris les fichiers Docker Compose existants. Buildx construira automatiquement toutes les images identifiées dans le fichier.

Des fonctionnalités plus avancées sont exposées lorsque vous listez les cibles de construction dans des fichiers JSON ou HCL. Ceux-ci prennent en charge les variables, les fonctions et l’interpolation de valeurs pour personnaliser vos constructions.

Comment utiliser Docker avec un pare-feu UFW

La commande buildx bake recherche les fichiers suivants dans l’ordre :

docker-compose.yml
docker-compose.yaml
docker-bake.json
docker-bake.override.json
docker-bake.hcl
docker-bake.override.hcl

Vous pouvez spécifier un fichier différent avec l’option -f de la commande.

Cibles de construction

Les cibles de construction encapsulent toute la configuration liée à votre construction. Elles comprennent des détails tels que

le chemin d'accès au fichier Dockerfile à construire
les chemins du contexte de construction, qui définissent le contenu disponible dans votre Dockerfile
les balises et les étiquettes à attacher aux images de sortie
les plateformes pour lesquelles produire des images.

Une liste complète des champs de configuration pris en charge est disponible dans la documentation. Auparavant, vous deviez fournir ces paramètres sous forme de drapeaux de ligne de commande à docker buildx build (ou même à docker build), ce qui vous obligeait à vous souvenir des bonnes valeurs à chaque fois. Avec buildx bake, vous pouvez utiliser de manière fiable les mêmes valeurs en les définissant dans votre fichier baked contrôlé par version.

Voici un exemple simple d’une commande docker-bake.hcl qui définit une seule cible de construction :

target « default » {
dockerfile =  » app/Dockerfile
contextes = {
app = « app/src
shared = « shared-components/src »
}
tags = [« mon-app:latest », « docker.io/my-org/my-app:latest »]
}

L’exécution de docker buildx bake avec ce fichier bake chargera le Dockerfile app/Dockerfile depuis votre répertoire de travail. Il aura accès aux répertoires app/src et shared-components/src comme contextes de construction. L’image produite se verra attribuer deux balises.

La cible par défaut est construite automatiquement lorsque vous exécutez docker buildx bake. Vous pouvez également définir des cibles nommées qui peuvent être construites à la demande :

target « app » {
// …
}

$ docker buildx bake app

Utilisation de cibles multiples

Vous pouvez construire une autre image simultanément en la définissant comme une nouvelle cible dans votre fichier bake :

group « default » {
targets = [« app », « api »]
}

target « app » {
dockerfile =  » app/Dockerfile  » (en anglais)
contextes = {
app = « app/src
shared = « shared-components/src
}
tags = [« mon-app:latest », « docker.io/my-org/my-app:latest »]
}

target « api » {
dockerfile = « api/Dockerfile » [api/Dockerfile
contextes = {
src = « api/src »
}
tags = [ « my-api:latest », « docker.io/my-org/my-api:latest »]
}

Ces images peuvent être construites simultanément car elles sont imbriquées dans un groupe. Les images api et app seront construites en parallèle chaque fois que vous exécuterez la commande docker buildx bake car le groupe par défaut est automatiquement sélectionné. Vous pouvez utiliser les groupes nommés de manière similaire à l’exemple des cibles nommées ci-dessus.

Héritage des cibles de construction

Les cibles de construction peuvent hériter les unes des autres pour réutiliser la configuration. Un scénario où cela peut être utile concerne les images qui doivent être personnalisées pour différents environnements. Vous pourriez vouloir ajouter des fichiers de configuration supplémentaires aux variantes d’images destinées au développement. Voici un fichier docker-bake.hcl qui illustre ce modèle :

group « default » {
targets = [« backend », « backend-dev »]
}

cible « backend » {
dockerfile =  » backend/Dockerfile
contextes = {
src = « api/src
config = « api/config »
}
tags = [ « backend:latest »]
}

target « backend-dev » {
inherits = [« backend »]
contextes = {
config = « api/config-dev
}
tags = [ « backend:dev »]
}

La cible backend-dev hérite de toutes les propriétés de la cible backend mais remplace le contexte config et applique une balise différente.

Vous pouvez prévisualiser la structure des fichiers fusionnés en exécutant la commande bake avec l’option –print :

$ docker buildx bake –print
…
« backend-dev » : {
« context » : « . »,
« contextes » : {
« config » : « api/config-dev »,
« src » : « api/src »
},
« dockerfile » : « backend/Dockerfile »,
« tags » : [
« backend:dev »
]
}
…

Utilisation d’une cible précédente comme image de base

Parfois, vous pouvez souhaiter qu’une cible de construction utilise l’image créée par une cible précédente comme sa propre base. Il s’agit d’une alternative aux constructions en plusieurs étapes qui peut être utilisée lorsque vos Dockerfiles dépendent les uns des autres mais ne peuvent pas être fusionnés, peut-être parce qu’ils existent dans des projets différents.

group « default » {
targets = [« org-base-image », « api »]
}

target « org-base-image » {
dockerfile = « docker-base/Dockerfile
tags = [« org-base-image:latest »]
}

cible « api » {
dockerfile = « api/Dockerfile
contextes = {
base = « cible:org-base-image
}
tags = [ « api:latest »]
}

L’exemple construit d’abord la cible org-base-image. Elle peut contenir des utilitaires communs aux charges de travail conteneurisées de votre organisation. La cible api est ensuite construite avec la sortie de la cible org-base-image accessible comme contexte de construction de base. Le Dockerfile de l’API peut maintenant faire référence au contenu de l’image de base :

COPY –from=base /utilities/example /usr/bin/example-utility

Il s’agit d’un modèle puissant qui vous permet de créer des liens de dépendance entre les images tout en conservant des Dockerfiles distincts.

Remplacement des propriétés des cibles au moment de la construction

La commande docker buildx bake vous permet de remplacer les propriétés de vos cibles lorsque vous exécutez votre construction :

$ docker buildx bake –set api.dockerfile= »api/Dockerfile-dev »

Cet exemple modifie le Dockerfile de la cible api. Le caractère générique * est pris en charge lors de l’identification de la cible à modifier. * seul sélectionne toutes les cibles, tandis que api* modifiera toutes les cibles qui commencent par api.

Définition de variables

Les fichiers HCL peuvent définir des variables que vous pouvez référencer dans vos cibles de construction. Utilisez un bloc de variables pour les configurer :

variable « TAG » {
default = « latest »
}

groupe « default » {
targets = [« app »]
}

target « app » {
dockerfile = « src/Dockerfile
tags = [« mon-app:${TAG} »]
}

L’exécution de docker buildx bake avec cette configuration marquera la cible « app » comme my-app:latest. Vous pouvez modifier la valeur de la variable TAG en définissant une variable d’environnement avant d’exécuter la commande :

$ TAG=v1 docker buildx bake

Vous pouvez utiliser toutes les capacités d’interpolation et de comparaison de variables du langage HCL pour rendre vos cibles de construction réutilisables. Des fonctions sont également disponibles pour analyser et transformer vos valeurs.

Conclusion

Les builds Buildx baked vous permettent d’encapsuler la configuration de la construction d’images en tant que « cibles » définies dans un fichier. Lorsque vous exécutez buildx bake, les images de toutes les cibles référencées sont construites en parallèle.

Les cibles peuvent hériter les unes des autres et dépendre les unes des autres. Vous pouvez également utiliser des variables et des fonctions pour créer des pipelines de construction hautement complexes et configurables.

La commande docker buildx bake est une opération de haut niveau qui n’est pas nécessaire dans tous les flux de travail. Vous n’avez pas besoin de l’utiliser lorsque vous créez des images simples sans dépendances inter-projets. L’utilisation de docker compose build est une meilleure alternative pour la plupart des cas d’utilisation qui conserve la configuration de la construction dans votre fichier docker-compose.yml. Le passage à la construction par cuisson doit être envisagé lorsque vous construisez plusieurs images simultanément en utilisant des variables, des plateformes, des contextes de construction et des surcharges de configuration différents.