Comment utiliser la commande docker buildx bake pour construire plusieurs cibles

Introduction

Dans ce lab, vous apprendrez à utiliser efficacement la commande docker buildx bake pour gérer et construire plusieurs cibles d'images Docker à partir d'un seul fichier de configuration. Nous commencerons par créer un fichier docker-bake.hcl qui définit différentes cibles de build avec des configurations variées.

À travers des étapes pratiques, vous vous exercerez à :

• Construire des cibles spécifiques définies dans le fichier bake
• Lister les cibles disponibles
• Surcharger les configurations des cibles en utilisant des flags en ligne de commande
• Prévisualiser la configuration de build sans exécuter réellement le build

Ce lab vous dotera des compétences nécessaires pour rationaliser vos workflows de construction d'images Docker pour des projets complexes.

Skills Graph

Créer un fichier docker-bake.hcl simple avec plusieurs cibles

Dans cette étape, nous allons créer un fichier docker-bake.hcl de base. Ce fichier utilise le format HCL (HashiCorp Configuration Language) et vous permet de définir plusieurs cibles de build pour vos images Docker. Ceci est particulièrement utile lorsque vous avez différentes configurations de build ou que vous souhaitez construire plusieurs images liées à partir d'une seule source.

Commencez par naviguer vers le répertoire ~/project, qui est votre répertoire de travail pour ce lab.

cd ~/project

Maintenant, créons un nouveau fichier nommé docker-bake.hcl en utilisant l'éditeur nano.

nano docker-bake.hcl

Dans l'éditeur nano, collez le contenu suivant. Ce fichier définit deux cibles de build : my-app-dev et my-app-prod. Chaque cible spécifie le Dockerfile à utiliser (Dockerfile), le contexte de build (.) et les tags pour l'image résultante.

target "my-app-dev" {
  dockerfile = "Dockerfile"
  context = "."
  tags = ["my-app:dev"]
}

target "my-app-prod" {
  dockerfile = "Dockerfile"
  context = "."
  tags = ["my-app:prod"]
  args = {
    BUILD_ENV = "production"
  }
}

Dans ce fichier :

• target "my-app-dev" définit une cible nommée my-app-dev
• dockerfile = "Dockerfile" spécifie que le build doit utiliser un fichier nommé Dockerfile dans le contexte
• context = "." définit le contexte de build comme étant le répertoire courant
• tags = ["my-app:dev"] attribue le tag my-app:dev à l'image résultante
• target "my-app-prod" définit une autre cible nommée my-app-prod
• Elle utilise également Dockerfile et le répertoire courant comme contexte
• tags = ["my-app:prod"] attribue le tag my-app:prod à cette image
• args = { BUILD_ENV = "production" } passe un argument de build BUILD_ENV avec la valeur production au Dockerfile pendant le build de cette cible

Enregistrez le fichier en appuyant sur Ctrl + S et quittez nano avec Ctrl + X.

Ensuite, nous avons besoin d'un simple Dockerfile pour que notre fichier bake puisse y faire référence. Créez un fichier nommé Dockerfile dans le même répertoire.

nano Dockerfile

Collez le contenu suivant dans le Dockerfile :

FROM alpine:latest

ARG BUILD_ENV=development

RUN echo "Building for environment: $BUILD_ENV"

CMD ["echo", "Hello from $BUILD_ENV environment!"]

Ce Dockerfile utilise l'image de base alpine:latest. Il définit un argument de build BUILD_ENV avec une valeur par défaut de development. L'instruction RUN affiche l'environnement de build pendant le processus de construction, et l'instruction CMD définit la commande par défaut à exécuter lorsqu'un conteneur est démarré à partir de cette image.

Enregistrez le Dockerfile et quittez nano.

Vous avez maintenant créé avec succès un fichier docker-bake.hcl avec deux cibles et un simple Dockerfile à utiliser avec celui-ci.

Construire une cible spécifique avec docker buildx bake

Dans l'étape précédente, nous avons créé un fichier docker-bake.hcl avec deux cibles de build : my-app-dev et my-app-prod. Maintenant, nous allons utiliser la commande docker buildx bake pour construire une cible spécifique définie dans ce fichier.

La commande docker buildx bake permet de construire des images en se basant sur les configurations définies dans un fichier bake. En spécifiant le nom de la cible après la commande, vous indiquez à Buildx de ne construire que cette cible particulière.

Construisons la cible my-app-dev. Assurez-vous d'être dans le répertoire ~/project.

cd ~/project

Maintenant, exécutez la commande suivante :

docker buildx bake my-app-dev

Cette commande lira le fichier docker-bake.hcl dans le répertoire courant et construira la cible nommée my-app-dev. Vous devriez voir une sortie indiquant le processus de build, incluant les étapes définies dans le Dockerfile.

[+] Building 0.0s (0/0)
... (sortie du build) ...

Une fois le build terminé, vous pouvez vérifier que l'image my-app:dev a bien été créée en listant vos images Docker locales.

docker images

Vous devriez voir my-app avec le tag dev dans la liste des images.

Maintenant, construisons la cible my-app-prod. Cette cible inclut un argument de build BUILD_ENV défini à production.

docker buildx bake my-app-prod

Observez la sortie. Vous devriez voir la ligne Building for environment: production pendant le processus de build, ce qui confirme que l'argument de build a bien été transmis.

[+] Building 0.0s (0/0)
... (sortie du build montrant "Building for environment: production") ...

Une fois ce build terminé, listez à nouveau vos images.

docker images

Vous devriez maintenant voir à la fois my-app:dev et my-app:prod dans votre liste d'images.

En utilisant docker buildx bake suivi du nom de la cible, vous pouvez construire sélectivement différentes configurations définies dans votre fichier bake.

Lister les cibles disponibles dans le fichier bake

Dans les étapes précédentes, nous avons créé un fichier docker-bake.hcl et construit des cibles spécifiques à partir de celui-ci. Parfois, vous pourriez vouloir voir toutes les cibles disponibles définies dans un fichier bake sans les construire effectivement. La commande docker buildx bake offre cette possibilité.

Pour lister les cibles disponibles, vous pouvez simplement exécuter la commande docker buildx bake sans spécifier de noms de cibles. Par défaut, elle lira le fichier docker-bake.hcl dans le répertoire courant et affichera les noms de toutes les cibles définies.

Assurez-vous d'être dans le répertoire ~/project où se trouve votre fichier docker-bake.hcl.

cd ~/project

Maintenant, exécutez la commande suivante :

docker buildx bake

Vous devriez voir une sortie similaire à ceci, listant les cibles définies dans votre fichier docker-bake.hcl :

my-app-dev
my-app-prod

Cette sortie montre les noms des deux cibles que nous avons définies dans le fichier docker-bake.hcl : my-app-dev et my-app-prod. C'est un moyen rapide d'obtenir une vue d'ensemble des configurations de build disponibles dans un fichier bake.

Cette commande est utile pour comprendre la structure d'un fichier bake et identifier les cibles que vous pouvez construire.

Surcharger la configuration d'une cible avec le flag --set

Dans cette étape, nous allons apprendre à surcharger la configuration d'une cible spécifique définie dans le fichier docker-bake.hcl en utilisant le flag --set avec la commande docker buildx bake. Cette fonctionnalité est utile lorsque vous devez apporter des ajustements mineurs à la configuration d'une cible sans modifier le fichier bake lui-même.

Le flag --set permet de surcharger des attributs spécifiques d'une cible. La syntaxe est nom_cible.attribut=valeur.

Imaginons que nous voulions construire la cible my-app-dev mais avec un tag différent, par exemple my-app:staging. Nous pouvons y parvenir en utilisant le flag --set.

Assurez-vous d'être dans le répertoire ~/project.

cd ~/project

Maintenant, exécutez la commande suivante :

docker buildx bake my-app-dev --set my-app-dev.tags=my-app:staging

Dans cette commande :

• my-app-dev est le nom de la cible que nous construisons
• --set my-app-dev.tags=my-app:staging surcharge l'attribut tags de la cible my-app-dev, en lui donnant la valeur my-app:staging

Vous verrez apparaître la sortie du processus de build.

[+] Building 0.0s (0/0)
... (sortie du build) ...

Une fois le build terminé, listez vos images Docker locales pour vérifier que l'image avec le nouveau tag a bien été créée.

docker images

Vous devriez maintenant voir my-app avec le tag staging dans la liste, en plus des tags dev et prod des étapes précédentes.

Vous pouvez également surcharger d'autres attributs, comme les arguments de build. Construisons la cible my-app-prod en surchargeant l'argument BUILD_ENV avec la valeur qa.

docker buildx bake my-app-prod --set my-app-prod.args.BUILD_ENV=qa

Observez la sortie du build. Vous devriez voir Building for environment: qa, ce qui indique que l'argument de build a bien été surchargé.

[+] Building 0.0s (0/0)
... (sortie du build affichant "Building for environment: qa") ...

Le flag --set offre un moyen flexible de personnaliser vos builds directement depuis la ligne de commande sans modifier votre fichier bake.

Afficher la configuration finale sans construire

Dans cette dernière étape, nous allons explorer comment visualiser la configuration finale que docker buildx bake utilisera pour une cible spécifique, y compris les éventuelles surcharges appliquées avec le flag --set, sans déclencher réellement la construction. Cela est utile pour déboguer vos fichiers bake et comprendre la configuration effective avant de lancer le build.

Le flag --print avec docker buildx bake permet d'afficher la configuration résolue au format JSON.

Assurez-vous d'être dans le répertoire ~/project.

cd ~/project

Affichons la configuration pour la cible my-app-dev.

docker buildx bake my-app-dev --print

Cette commande produira une représentation JSON de la configuration de la cible my-app-dev telle qu'elle est dérivée du fichier docker-bake.hcl.

{
  "target": {
    "my-app-dev": {
      "dockerfile": "Dockerfile",
      "context": ".",
      "tags": ["my-app:dev"]
    }
  }
}

Voyons maintenant comment le flag --set affecte la configuration affichée. Nous allons afficher la configuration pour my-app-dev tout en surchargeant le tag avec my-app:testing.

docker buildx bake my-app-dev --set my-app-dev.tags=my-app:testing --print

Observez le résultat. L'attribut tags dans la sortie JSON devrait maintenant refléter la valeur surchargée.

{
  "target": {
    "my-app-dev": {
      "dockerfile": "Dockerfile",
      "context": ".",
      "tags": ["my-app:testing"]
    }
  }
}

De même, vous pouvez afficher la configuration pour la cible my-app-prod et surcharger son argument de build.

docker buildx bake my-app-prod --set my-app-prod.args.BUILD_ENV=staging --print

La sortie JSON pour la cible my-app-prod montrera les args avec la valeur surchargée de BUILD_ENV.

{
  "target": {
    "my-app-prod": {
      "dockerfile": "Dockerfile",
      "context": ".",
      "tags": ["my-app:prod"],
      "args": {
        "BUILD_ENV": "staging"
      }
    }
  }
}

Le flag --print est un outil précieux pour vérifier vos configurations de fichiers bake et comprendre comment les surcharges sont appliquées avant de lancer des constructions potentiellement longues.

Résumé

Dans ce lab, nous avons appris à utiliser la commande docker buildx bake pour gérer et construire plusieurs cibles d'images Docker définies dans un seul fichier docker-bake.hcl. Nous avons commencé par créer un fichier docker-bake.hcl de base avec des cibles distinctes, chacune spécifiant son Dockerfile, son contexte, ses tags et ses arguments de build.

Nous avons ensuite exploré comment :

• Construire une cible spécifique du fichier bake avec docker buildx bake <nom_cible>
• Lister toutes les cibles disponibles dans le fichier
• Surcharger les configurations des cibles à la volée en utilisant le flag --set
• Prévisualiser la configuration de build résultante sans exécuter réellement le build grâce au flag --print

Ces étapes démontrent la flexibilité et la puissance de docker buildx bake pour rationaliser les workflows complexes de construction multi-images.