Comment utiliser la commande docker buildx ls pour lister les instances de builder

DockerDockerBeginner
Pratiquer maintenant

💡 Ce tutoriel est traduit par l'IA à partir de la version anglaise. Pour voir la version originale, vous pouvez cliquer ici

Introduction

Dans ce lab, vous apprendrez à utiliser la commande docker buildx ls pour lister les instances de builder (constructeur) et leurs nœuds associés. Vous explorerez l'utilisation basique de cette commande pour visualiser les environnements de build disponibles et leurs configurations.

De plus, vous découvrirez comment formater la sortie de docker buildx ls en utilisant des templates Go pour personnaliser les informations affichées. Cela inclut le formatage de la sortie pour afficher des champs spécifiques et visualiser les relations entre les instances de builder et leurs nœuds.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL docker(("Docker")) -.-> docker/ContainerOperationsGroup(["Container Operations"]) docker/ContainerOperationsGroup -.-> docker/ls("List Containers") subgraph Lab Skills docker/ls -.-> lab-555060{{"Comment utiliser la commande docker buildx ls pour lister les instances de builder"}} end

Lister toutes les instances de builder et leurs nœuds

Dans cette étape, vous apprendrez à lister toutes les instances de builder (constructeur) et leurs nœuds en utilisant la commande docker buildx ls. Cette commande est utile pour comprendre les environnements de build disponibles et leurs configurations.

Commençons par exécuter la commande de base pour lister les instances de builder et leurs nœuds.

docker buildx ls

Vous devriez voir une sortie similaire à ceci :

NAME/NODE       DRIVER/ENDPOINT STATUS  BUILDKIT             PLATFORMS
default         docker
  default       docker          running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x

La sortie fournit des informations sur les instances de builder et leurs nœuds associés. La colonne NAME/NODE affiche le nom de l'instance de builder et le nœud dans cette instance. La colonne DRIVER/ENDPOINT indique le driver utilisé et le endpoint pour le nœud. La colonne STATUS montre l'état actuel du nœud (par exemple running). La colonne BUILDKIT affiche la version de BuildKit. Enfin, la colonne PLATFORMS liste les plateformes supportées par le nœud.

Dans cet exemple, nous voyons une instance de builder nommée default avec un seul nœud également nommé default. Elle utilise le driver docker et est actuellement en état running. Elle supporte plusieurs plateformes.

Formater la sortie à l'aide d'un template Go

Dans cette étape, vous apprendrez à formater la sortie de la commande docker buildx ls en utilisant un template Go. Les templates Go offrent une méthode flexible pour personnaliser le format de sortie afin d'afficher uniquement les informations dont vous avez besoin.

Le flag --format vous permet de spécifier un template Go. Le template utilise des placeholders comme {{.Name}}, {{.Driver}}, {{.Status}}, etc. pour accéder aux différents champs des objets instance de builder et nœuds.

Essayons de formater la sortie pour n'afficher que le nom et le driver des instances de builder et de leurs nœuds.

docker buildx ls --format "{{.Name}}\t{{.Driver}}"

Vous devriez obtenir une sortie similaire à :

default docker
default docker

Dans ce template, {{.Name}} représente le nom du builder ou du nœud, et {{.Driver}} représente le driver. Le \t est utilisé pour insérer un caractère de tabulation entre le nom et le driver pour une meilleure lisibilité.

Ceci démontre comment utiliser un template Go simple pour extraire des informations spécifiques de la sortie de docker buildx ls. Dans les étapes suivantes, nous explorerons des templates plus complexes pour formater la sortie de différentes manières.

Formater la sortie avec des champs spécifiques

Dans cette étape, nous allons continuer à explorer les templates Go pour formater la sortie de docker buildx ls et afficher des champs spécifiques d'intérêt. Vous pouvez sélectionner divers champs parmi les objets instance de builder et nœuds à inclure dans votre sortie personnalisée.

Formatons la sortie pour afficher le nom, le statut et les plateformes supportées pour chaque nœud de builder.

docker buildx ls --format "{{.Name}}\t{{.Status}}\t{{.Platforms}}"

Vous devriez obtenir une sortie similaire à :

default running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x
default running linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x

Dans ce template :

  • {{.Name}} fait référence au nom du nœud de builder
  • {{.Status}} indique le statut du nœud de builder (par exemple running)
  • {{.Platforms}} liste les plateformes supportées par le nœud de builder

Nous utilisons à nouveau \t pour séparer les champs par des tabulations. Cela vous permet de voir rapidement le statut et les plateformes supportées pour chaque nœud.

Vous pouvez combiner différents champs dans votre template selon vos besoins. Essayez d'inclure d'autres champs comme {{.Driver}} ou {{.Buildkit}} pour observer comment la sortie évolue.

Formater la sortie pour afficher les relations entre builders et nœuds

Dans cette étape, nous utiliserons un template Go plus avancé pour visualiser la relation entre les instances de builder et leurs nœuds. Cela peut être utile lorsque vous avez plusieurs instances de builder et nœuds configurés.

Nous pouvons utiliser des instructions conditionnelles et des boucles dans le template Go pour y parvenir. Cependant, pour rester simple et nous concentrer sur le formatage de base, nous créerons un template qui montre clairement quel nœud appartient à quelle instance de builder.

Utilisons un template qui affiche le nom du builder suivi de ses nœuds, avec une indentation.

docker buildx ls --format "{{range .}}{{if .Builder}}{{.Name}} (Builder){{range .Nodes}}\n  - {{.Name}} (Node){{end}}{{else}}\n{{.Name}} (Node){{end}}{{end}}"

Vous devriez obtenir une sortie similaire à :

default (Builder)
  - default (Node)

Décomposons ce template :

  • {{range .}}...{{end}} : Itère sur la liste des instances de builder et des nœuds
  • {{if .Builder}}...{{else}}...{{end}} : Vérifie si l'élément courant est une instance de builder (.Builder est vrai)
  • Si c'est un builder :
    • {{.Name}} (Builder) : Affiche le nom du builder suivi de "(Builder)"
    • {{range .Nodes}}...{{end}} : Itère sur les nœuds du builder courant
    • \n - {{.Name}} (Node) : Affiche un saut de ligne, une indentation, "- ", le nom du nœud et "(Node)"
  • Si ce n'est pas un builder (c'est-à-dire un nœud autonome, moins courant dans les configurations de base) :
    • \n{{.Name}} (Node) : Affiche un saut de ligne, le nom du nœud et "(Node)"

Ce template fournit une sortie structurée qui montre clairement quels nœuds sont associés à quelles instances de builder. Bien que cet exemple soit simple avec un seul builder et un seul nœud, ce template devient plus utile lorsque vous avez une configuration buildx plus complexe.

Résumé

Dans ce lab, vous avez appris à utiliser la commande docker buildx ls pour lister les instances de builder et leurs nœuds associés. Vous avez commencé par exécuter la commande de base pour voir le résultat par défaut, qui fournit des détails sur le nom du builder, le nom du nœud, le pilote (driver), l'état, la version de BuildKit et les plateformes prises en charge.

De plus, vous avez exploré comment formater la sortie en utilisant un template Go avec l'option --format. Cela vous permet de personnaliser les informations affichées en spécifiant des placeholders pour différents champs, vous donnant la possibilité d'extraire et de présenter uniquement les données pertinentes concernant vos instances de builder et leurs nœuds.