Comment utiliser la commande docker buildx create pour gérer les builders

Introduction

Dans ce lab, vous apprendrez à gérer efficacement les builders Docker en utilisant la commande docker buildx create. Nous aborderons les étapes essentielles pour créer une nouvelle instance de builder, ajouter de nouveaux nœuds à un builder existant, spécifier des noms personnalisés pour les builders et nœuds, définir les plateformes prises en charge pour un nœud de build, et basculer automatiquement vers un nouveau builder pour vos opérations de build. À la fin de ce lab, vous aurez une compréhension solide de la configuration et de l'utilisation de différentes configurations de builder pour des builds multi-architectures et distribués.

Skills Graph

Créer une nouvelle instance de builder

Dans cette étape, nous allons apprendre à créer une nouvelle instance de builder en utilisant la commande docker buildx create. Une instance de builder est un objet Docker qui gère plusieurs nœuds de build. Chaque nœud peut représenter une architecture ou un environnement différent pour construire des images.

Avant de créer un nouveau builder, vérifions les builders existants sur votre système. Vous pouvez le faire avec la commande docker buildx ls.

docker buildx ls

Vous devriez voir l'instance de builder par défaut, généralement nommée default.

Maintenant, créons une nouvelle instance de builder. Nous allons nommer ce nouveau builder mybuilder.

docker buildx create --name mybuilder

Cette commande crée une nouvelle instance de builder nommée mybuilder. Par défaut, ce nouveau builder n'aura encore aucun nœud associé. Nous ajouterons des nœuds dans les étapes suivantes.

Après avoir créé le nouveau builder, vous pouvez lister à nouveau les builders pour voir celui qui vient d'être créé.

docker buildx ls

Vous devriez maintenant voir à la fois le builder default et le builder mybuilder listés. Le builder mybuilder sera indiqué comme inactif pour le moment, car il n'a pas encore de nœuds actifs.

Ajouter un nouveau nœud à un builder existant

Dans l'étape précédente, nous avons créé une nouvelle instance de builder nommée mybuilder. Actuellement, ce builder ne possède aucun nœud de build. Dans cette étape, nous allons ajouter un nouveau nœud à ce builder existant.

Un nœud de build est essentiellement un endpoint Docker où le processus de build s'exécutera. Par défaut, lorsque vous créez un nouveau builder sans spécifier de nœud, il est créé sans aucun nœud actif.

Pour ajouter un nouveau nœud au builder mybuilder, nous utiliserons à nouveau la commande docker buildx create, mais cette fois en spécifiant le builder auquel nous voulons ajouter le nœud à l'aide du flag --append. Nous allons ajouter un nœud au builder mybuilder.

docker buildx create --name mybuilder --append

Cette commande ajoute un nouveau nœud au builder mybuilder. Par défaut, lorsque vous ajoutez un nœud sans spécifier de nom, Docker Buildx génère automatiquement un nom pour celui-ci.

Listons à nouveau les builders pour voir l'instance mybuilder mise à jour avec son nouveau nœud.

docker buildx ls

Vous devriez maintenant voir mybuilder listé avec un nœud sous celui-ci. Le nœud aura un nom généré automatiquement et sera probablement dans un état "running".

Spécifier un nom pour le builder et le nœud

Dans les étapes précédentes, nous avons créé un builder nommé mybuilder et y avons ajouté un nœud. Le nœud s'est vu attribuer automatiquement un nom généré. Dans cette étape, nous allons apprendre à spécifier des noms à la fois pour le builder et le nœud lors de leur création.

Commençons par supprimer le builder mybuilder créé précédemment afin de repartir à zéro.

docker buildx rm mybuilder

Maintenant, créons une nouvelle instance de builder en spécifiant son nom comme custombuilder. Nous allons également spécifier un nom pour le nœud initial de ce builder en le nommant node1. Nous pouvons le faire en utilisant le flag --name pour le builder et le flag --node pour le nœud.

docker buildx create --name custombuilder --node node1

Cette commande crée une nouvelle instance de builder nommée custombuilder avec un nœud initial nommé node1.

Listons les builders pour confirmer les noms.

docker buildx ls

Vous devriez maintenant voir custombuilder listé, et en dessous le nœud nommé node1. Cela vous donne plus de contrôle sur l'organisation et l'identification de vos builders et nœuds.

Définir les plateformes prises en charge par un nœud

Dans cette étape, nous allons apprendre à spécifier les plateformes supportées par un nœud de build. Ceci est crucial pour construire des images multi-architectures. Par défaut, un nœud supporte l'architecture de l'hôte sur lequel il s'exécute. Cependant, avec Buildx, vous pouvez configurer des nœuds pour supporter des plateformes supplémentaires en utilisant l'émulation (comme QEMU).

Commençons par inspecter le custombuilder créé précédemment pour voir les plateformes supportées par son nœud.

docker buildx inspect custombuilder

Recherchez le champ "Platforms" dans la sortie. Il devrait afficher l'architecture native de votre VM LabEx (par exemple linux/amd64).

Maintenant, mettons à jour le nœud node1 dans custombuilder pour supporter des plateformes supplémentaires. Nous pouvons utiliser la commande docker buildx create avec les flags --append et --platform. Nous allons ajouter le support pour linux/arm64 et linux/riscv64.

docker buildx create --name custombuilder --append --node node1 --platform linux/arm64,linux/riscv64

Notez que nous utilisons --append avec le nom du builder existant et le nom du nœud. Cette commande met à jour le nœud existant node1 dans custombuilder pour inclure les plateformes spécifiées.

Inspectons à nouveau le builder pour voir les plateformes mises à jour pour node1.

docker buildx inspect custombuilder

Le champ "Platforms" pour node1 devrait maintenant inclure linux/amd64, linux/arm64 et linux/riscv64. Cela signifie que ce nœud est désormais capable de construire des images pour ces architectures.

Basculer automatiquement vers le nouveau builder créé

Dans cette dernière étape, nous allons apprendre à basculer automatiquement vers l'utilisation du nouveau builder créé. Lorsque vous disposez de plusieurs builders, vous devez indiquer à Docker Buildx lequel utiliser pour vos opérations de build.

Par défaut, Docker Buildx utilise le builder default. Vous pouvez voir quel builder est actuellement actif en examinant la sortie de docker buildx ls. Le builder actif est marqué d'un astérisque (*) à côté de son nom.

docker buildx ls

Pour basculer vers le custombuilder que nous avons créé, utilisez la commande docker buildx use suivie du nom du builder.

docker buildx use custombuilder

Cette commande définit custombuilder comme builder actif. Toutes les commandes docker buildx build suivantes utiliseront désormais les nœuds configurés dans custombuilder.

Vérifions que custombuilder est maintenant le builder actif en listant à nouveau les builders.

docker buildx ls

Vous devriez maintenant voir un astérisque (*) à côté de custombuilder, indiquant qu'il s'agit du builder actif.

Vous avez réussi à :

1. Créer une nouvelle instance de builder
2. Y ajouter un nœud
3. Spécifier des noms pour les deux
4. Définir les plateformes supportées pour le nœud
5. Basculer vers l'utilisation de ce nouveau builder

Résumé

Dans ce lab, nous avons appris à gérer les builders Docker en utilisant la commande docker buildx create. Nous avons commencé par créer une nouvelle instance de builder nommée mybuilder, démontrant comment initialiser un environnement de build séparé. Nous avons ensuite exploré comment ajouter un nouveau nœud de build à un builder existant, ajoutant ainsi un point de terminaison de build à notre instance mybuilder.

De plus, nous avons vu comment spécifier des noms personnalisés pour le builder et ses nœuds afin d'améliorer l'organisation et la clarté. Nous avons également appris à définir les plateformes spécifiques (architectures) qu'un nœud de build particulier supporte, permettant des builds ciblés. Enfin, nous avons pratiqué le basculement automatique vers le nouveau builder créé, le rendant ainsi le builder actif pour les opérations de build ultérieures.