Verwendung des docker buildx inspect Befehls zur Anzeige von Builder-Details

DockerDockerBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einführung

In diesem Lab lernen Sie, wie Sie den Befehl docker buildx inspect verwenden, um Details über Ihre Docker-Builder-Instanzen anzuzeigen. Sie beginnen mit der Überprüfung der aktuellen Builder-Instanz und erfahren dann, wie Sie einen Builder anhand seines Namens angeben können.

Außerdem werden Sie untersuchen, wie Sie sicherstellen können, dass ein Builder vor der Überprüfung mit dem Flag --bootstrap läuft, und wie Sie mit dem Flag --debug detailliertere Informationen erhalten. Dadurch erhalten Sie ein umfassendes Verständnis der Konfiguration und des Status Ihres Builders.


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{{"Verwendung des docker buildx inspect Befehls zur Anzeige von Builder-Details"}} docker/build -.-> lab-555059{{"Verwendung des docker buildx inspect Befehls zur Anzeige von Builder-Details"}} end

Aktuelle Builder-Instanz überprüfen

In diesem Schritt lernen Sie, wie Sie die aktuelle Docker-Builder-Instanz überprüfen können. Der Docker-Builder ist für das Erstellen von Docker-Images verantwortlich. Durch die Überprüfung des Builders erhalten Sie Informationen über dessen Konfiguration und Status.

Zuerst verwenden wir den Befehl docker buildx inspect ohne Angabe eines Builder-Namens. Dadurch wird die aktuelle Builder-Instanz überprüft.

docker buildx inspect

Sie sollten eine ähnliche Ausgabe wie diese sehen, die Details über die Standard-Builder-Instanz anzeigt:

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

Die Ausgabe liefert Informationen wie den Namen des Builders, den verwendeten Treiber (in diesem Fall docker) sowie Details über die Build-Knoten, einschließlich deren Status, BuildKitd-Version und unterstützten Plattformen.

Bestimmte Builder-Instanz anhand des Namens überprüfen

Im vorherigen Schritt haben Sie die aktuelle Builder-Instanz überprüft. In diesem Schritt lernen Sie, wie Sie eine bestimmte Builder-Instanz anhand ihres Namens untersuchen können. Auch wenn Sie zunächst möglicherweise nur den Standard-Builder haben, ist es nützlich zu wissen, wie man einen Namen angibt, wenn mehrere Builder konfiguriert sind.

Um eine bestimmte Builder-Instanz zu überprüfen, verwenden Sie den Befehl docker buildx inspect gefolgt vom Namen des Builders. Der Standard-Builder heißt typischerweise default.

Lassen Sie uns den default-Builder explizit anhand seines Namens überprüfen:

docker buildx inspect default

Sie sollten dieselbe Ausgabe wie im vorherigen Schritt sehen, was bestätigt, dass Sie die default-Builder-Instanz überprüfen.

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

Dies zeigt, wie Sie eine bestimmte Builder-Instanz gezielt anhand ihres Namens überprüfen können.

Sicherstellen, dass Builder vor der Inspektion mit --bootstrap läuft

In diesem Schritt lernen Sie, wie Sie das Flag --bootstrap mit docker buildx inspect verwenden. Das --bootstrap-Flag stellt sicher, dass die Builder-Instanz läuft, bevor versucht wird, sie zu inspizieren. Falls der Builder nicht läuft, wird er durch dieses Flag gestartet.

Obwohl der Standard-Builder normalerweise läuft, ist es eine gute Praxis, --bootstrap zu verwenden, wenn Sie sicherstellen möchten, dass der Builder vor der Inspektion oder anderen Build-Operationen aktiv ist.

Lassen Sie uns den Standard-Builder erneut inspizieren, diesmal mit dem --bootstrap-Flag:

docker buildx inspect --bootstrap default

Sie sollten dieselbe Inspektionsausgabe wie zuvor sehen. Das --bootstrap-Flag stellt sicher, dass der Builder sich im laufenden Zustand befindet, bevor die Inspektion durchgeführt wird. Falls der Builder gestoppt war, hätte dieser Befehl ihn zuerst gestartet.

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

Die Verwendung von --bootstrap ist besonders nützlich in Skripten oder automatisierten Workflows, bei denen Sie sicherstellen müssen, dass der Builder bereit ist, bevor Sie mit einem Build fortfahren.

Detaillierte Informationen mit --debug anzeigen

In diesem letzten Schritt lernen Sie, wie Sie mit dem --debug-Flag bei docker buildx inspect detailliertere Informationen über eine Builder-Instanz erhalten. Das --debug-Flag liefert zusätzliche Ausgaben, die bei der Fehlerbehebung oder für ein tieferes Verständnis der Builder-Konfiguration hilfreich sein können.

Lassen Sie uns den Standard-Builder erneut inspizieren, diesmal mit dem --debug-Flag:

docker buildx inspect --debug default

Sie werden die standardmäßige Inspektionsausgabe sehen, der jedoch Debug-Logs vorangestellt sind. Diese Logs geben Einblicke in die internen Abläufe des buildx inspect-Befehls und die Kommunikation mit dem BuildKit-Daemon.

Die Debug-Ausgabe enthält Zeilen, die mit DEBU[... beginnen, gefolgt von detaillierten Informationen über den Prozess. Dies kann beispielsweise API-Aufrufe, das Laden von Konfigurationen und andere interne Vorgänge umfassen.

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

Das --debug-Flag ist ein leistungsfähiges Werkzeug zur Diagnose von Problemen oder zum besseren Verständnis der Interaktion zwischen docker buildx und dem zugrundeliegenden BuildKit-Dienst.

Zusammenfassung

In diesem Lab haben Sie gelernt, wie Sie den Befehl docker buildx inspect verwenden, um Details über Docker-Builder-Instanzen anzuzeigen. Sie begannen mit der Inspektion der aktuellen Builder-Instanz ohne Namensangabe, was typischerweise Informationen über den Standard-Builder anzeigt. Anschließend lernten Sie, wie Sie explizit eine bestimmte Builder-Instanz durch Angabe ihres Namens inspizieren, wobei sich bestätigte, dass dies dieselben Details für den Standard-Builder liefert.

Diese Schritte demonstrierten die grundlegende Verwendung von docker buildx inspect, um Einblicke in Ihre Docker-Build-Umgebung zu erhalten, einschließlich des Builder-Namens, des Treibers, des Knotenstatus, der BuildKitd-Version und der unterstützten Plattformen.