Comment utiliser la commande docker buildx inspect pour inspecter les builders

Introduction

Dans ce lab, vous apprendrez à utiliser la commande docker buildx inspect pour afficher les détails de vos instances de builder Docker. Vous commencerez par inspecter l'instance de builder actuelle, puis vous apprendrez comment spécifier un builder par son nom.

Vous explorerez également comment vérifier qu'un builder est en cours d'exécution avant l'inspection à l'aide du flag --bootstrap, et comment obtenir des informations plus détaillées avec le flag --debug, afin d'avoir une compréhension complète de la configuration et de l'état de votre builder.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL docker(("Docker")) -.-> docker/ContainerOperationsGroup(["Container Operations"]) docker(("Docker")) -.-> docker/DockerfileGroup(["Dockerfile"]) docker/ContainerOperationsGroup -.-> docker/inspect("Inspect Container") docker/DockerfileGroup -.-> docker/build("Build Image from Dockerfile") subgraph Lab Skills docker/inspect -.-> lab-555059{{"Comment utiliser la commande docker buildx inspect pour afficher les détails du builder"}} docker/build -.-> lab-555059{{"Comment utiliser la commande docker buildx inspect pour afficher les détails du builder"}} end

Inspecter l'instance de builder actuelle

Dans cette étape, vous apprendrez comment inspecter l'instance de builder Docker actuelle. Le builder Docker est responsable de la construction des images Docker. En inspectant le builder, vous pouvez obtenir des informations sur sa configuration et son état.

Commencez par utiliser la commande docker buildx inspect sans spécifier de nom de builder. Cela permettra d'inspecter l'instance de builder actuelle.

docker buildx inspect

Vous devriez voir une sortie similaire à ceci, affichant les détails de l'instance de builder par défaut :

Name: default
Driver: docker
Nodes:
  default:
    Status: running
    Buildkitd:
      Version: v0.10.5
      Platforms:
        - linux/amd64
        - linux/arm64
        - linux/riscv64
        - linux/ppc64le
        - linux/s390x
        - linux/386
        - linux/arm/v7
        - linux/arm/v6

La sortie fournit des informations telles que le nom du builder, le pilote utilisé (dans ce cas, docker), ainsi que des détails sur les nœuds de construction, y compris leur état, la version de BuildKitd et les plateformes prises en charge.

Inspecter une instance de builder spécifique par son nom

Dans l'étape précédente, vous avez inspecté l'instance de builder actuelle. Dans cette étape, vous apprendrez comment inspecter une instance de builder spécifique en utilisant son nom. Bien que vous n'ayez peut-être que le builder par défaut initialement, savoir comment spécifier un nom est utile lorsque vous avez plusieurs builders configurés.

Pour inspecter une instance de builder spécifique, utilisez la commande docker buildx inspect suivie du nom du builder. Le builder par défaut est généralement nommé default.

Inspectons explicitement le builder default par son nom :

docker buildx inspect default

Vous devriez voir la même sortie que dans l'étape précédente, confirmant que vous inspectez bien l'instance de builder default.

Name: default
Driver: docker
Nodes:
  default:
    Status: running
    Buildkitd:
      Version: v0.10.5
      Platforms:
        - linux/amd64
        - linux/arm64
        - linux/riscv64
        - linux/ppc64le
        - linux/s390x
        - linux/386
        - linux/arm/v7
        - linux/arm/v6

Cela démontre comment cibler une instance de builder spécifique pour l'inspection en utilisant son nom.

Vérifier que le builder est en cours d'exécution avant l'inspection avec --bootstrap

Dans cette étape, vous apprendrez à utiliser le flag --bootstrap avec la commande docker buildx inspect. Ce flag garantit que l'instance du builder est en cours d'exécution avant toute tentative d'inspection. Si le builder n'est pas démarré, ce flag le lancera automatiquement.

Bien que le builder par défaut soit généralement en cours d'exécution, il est recommandé d'utiliser --bootstrap lorsque vous souhaitez vous assurer que le builder est actif avant une inspection ou d'autres opérations de build.

Inspectons à nouveau le builder par défaut, cette fois-ci en utilisant le flag --bootstrap :

docker buildx inspect --bootstrap default

Vous devriez obtenir le même résultat d'inspection que précédemment. Le flag --bootstrap s'assure que le builder est dans un état actif avant l'exécution de l'inspection. Si le builder avait été arrêté, cette commande l'aurait d'abord démarré.

Name: default
Driver: docker
Nodes:
  default:
    Status: running
    Buildkitd:
      Version: v0.10.5
      Platforms:
        - linux/amd64
        - linux/arm64
        - linux/riscv64
        - linux/ppc64le
        - linux/s390x
        - linux/386
        - linux/arm/v7
        - linux/arm/v6

L'utilisation de --bootstrap est particulièrement utile dans les scripts ou les workflows automatisés où vous devez vous assurer que le builder est prêt avant de procéder à un build.

Afficher des informations détaillées avec --debug

Dans cette dernière étape, vous apprendrez comment obtenir des informations plus détaillées sur une instance de builder en utilisant le flag --debug avec la commande docker buildx inspect. Ce flag fournit un affichage supplémentaire qui peut être utile pour le dépannage ou pour comprendre plus en profondeur la configuration du builder.

Inspectons à nouveau le builder par défaut, cette fois-ci en incluant le flag --debug :

docker buildx inspect --debug default

Vous verrez le résultat standard de l'inspection, précédé de logs de débogage. Ces logs donnent un aperçu des opérations internes de la commande buildx inspect et de la communication avec le démon BuildKit.

La sortie de débogage inclura des lignes commençant par DEBU[... suivies d'informations détaillées sur le processus. Cela peut inclure des appels d'API effectués, le chargement de configurations et d'autres mécanismes internes.

DEBU[0000] loading config file /home/labex/.docker/config.json
DEBU[0000] Looking for builder "default"
DEBU[0000] found builder "default"
DEBU[0000] loading builder "default"
DEBU[0000] found 1 node(s) for builder "default"
DEBU[0000] loading node "default"
DEBU[0000] connecting to docker
DEBU[0000] running buildkitd container "buildx_buildkit_default"
DEBU[0000] buildkitd container "buildx_buildkit_default" is running
DEBU[0000] connecting to buildkitd
DEBU[0000] buildkitd connection successful
Name: default
Driver: docker
Nodes:
  default:
    Status: running
    Buildkitd:
      Version: v0.10.5
      Platforms:
        - linux/amd64
        - linux/arm64
        - linux/riscv64
        - linux/ppc64le
        - linux/s390x
        - linux/386
        - linux/arm/v7
        - linux/arm/v6

Le flag --debug est un outil puissant pour diagnostiquer des problèmes ou obtenir une meilleure compréhension de l'interaction entre docker buildx et le service BuildKit sous-jacent.

Résumé

Dans ce lab, vous avez appris à utiliser la commande docker buildx inspect pour visualiser les détails des instances de builder Docker. Vous avez commencé par inspecter l'instance de builder courante sans spécifier de nom, ce qui affiche généralement les informations du builder par défaut. Vous avez ensuite appris à inspecter explicitement une instance de builder spécifique en fournissant son nom, confirmant ainsi que cela donne les mêmes détails pour le builder par défaut.

Ces étapes ont démontré l'utilisation basique de docker buildx inspect pour obtenir des informations sur votre environnement de build Docker, incluant le nom du builder, son pilote, l'état des nœuds, la version de BuildKitd et les plateformes supportées.