Docker Build-Traces analysieren mit buildx history trace | Anleitung

Einführung

In diesem Lab lernen Sie, wie Sie docker buildx history trace verwenden, um die Build-Traces Ihrer Docker-Images anzuzeigen und zu analysieren. Sie beginnen mit dem Erstellen eines einfachen Docker-Images und zeichnen dessen Build-Verlauf mit standardmäßigen Docker-Befehlen auf.

Nach dem initialen Build untersuchen Sie, wie Sie die aufgezeichneten Build-Historie-Datensätze auflisten können, bevor Sie sich mit der detaillierten OpenTelemetry-Trace eines spezifischen Build-Datensatzes befassen. Abschließend lernen Sie, wie Sie die Traces zweier unterschiedlicher Build-Datensätze vergleichen, was wertvolle Einblicke in den Build-Prozess und potenzielle Optimierungen bietet.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL docker(("Docker")) -.-> docker/ContainerOperationsGroup(["Container Operations"]) docker(("Docker")) -.-> docker/ImageOperationsGroup(["Image Operations"]) docker(("Docker")) -.-> docker/DockerfileGroup(["Dockerfile"]) docker/ContainerOperationsGroup -.-> docker/inspect("Inspect Container") docker/ImageOperationsGroup -.-> docker/images("List Images") docker/DockerfileGroup -.-> docker/build("Build Image from Dockerfile") subgraph Lab Skills docker/inspect -.-> lab-555056{{"Verwendung von docker buildx history trace zum Anzeigen von Build-Traces"}} docker/images -.-> lab-555056{{"Verwendung von docker buildx history trace zum Anzeigen von Build-Traces"}} docker/build -.-> lab-555056{{"Verwendung von docker buildx history trace zum Anzeigen von Build-Traces"}} end

Ein Image erstellen und dessen Verlauf aufzeichnen

In diesem Schritt lernen Sie, wie Sie ein Docker-Image erstellen und dessen Build-Verlauf aufzeichnen. Docker-Images werden aus einer Dockerfile erstellt, einer Textdatei, die alle Befehle enthält, die ein Benutzer auf der Kommandozeile aufrufen würde, um ein Image zusammenzustellen.

Erstellen wir zunächst eine einfache Dockerfile. Navigieren Sie in das Verzeichnis ~/project, falls Sie sich nicht bereits dort befinden.

cd ~/project

Erstellen Sie nun eine Datei namens Dockerfile mit dem nano-Editor.

nano Dockerfile

Fügen Sie folgenden Inhalt zur Dockerfile hinzu:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y --no-install-recommends fortune-mod
CMD ["/usr/games/fortune"]

Diese Dockerfile basiert auf dem neuesten Ubuntu-Image, aktualisiert die Paketliste, installiert das Paket fortune-mod und legt den Standardbefehl fest, um das Programm fortune auszuführen.

Speichern Sie die Datei und beenden Sie nano (Drücken Sie Strg + X, dann Y, dann Eingabe).

Nun erstellen wir das Docker-Image mit dem Befehl docker build. Wir versehen das Image mit dem Tag my-fortune-image und verwenden das aktuelle Verzeichnis (.) als Build-Kontext.

docker build -t my-fortune-image .

Sie sehen eine Ausgabe, die den Build-Prozess anzeigt, einschließlich des Herunterladens des Basis-Images und der Ausführung des apt-get-Befehls.

Um den Build-Verlauf aufzuzeichnen, können wir den Befehl docker history verwenden. Dieser Befehl zeigt die Historie eines Images an.

docker history my-fortune-image

Die Ausgabe zeigt eine Liste der Schichten, aus denen das Image besteht, zusammen mit dem Befehl, der zur Erstellung jeder Schicht verwendet wurde, der Größe der Schicht und dem Erstellungszeitpunkt. Diese Historie ist nützlich, um zu verstehen, wie ein Image erstellt wurde, und für Debugging-Zwecke.

Build-Historie-Datensätze auflisten

In diesem Schritt lernen Sie mehr über das Auflisten der Build-Historie-Datensätze eines Docker-Images. Wie Sie im vorherigen Schritt gesehen haben, bietet der Befehl docker history eine detaillierte Ansicht der Schichten, aus denen ein Image besteht.

Lassen Sie uns den docker history-Befehl erneut für das my-fortune-image ausführen, das wir im vorherigen Schritt erstellt haben.

docker history my-fortune-image

Die Ausgabe zeigt mehrere Spalten an:

IMAGE: Die ID der Image-Schicht
CREATED: Der Zeitstempel der Erstellung der Schicht
CREATED BY: Der Befehl, der die Schicht erstellt hat
SIZE: Die Größe der Schicht
COMMENT: Etwaige Kommentare zur Schicht

Jede Zeile in der Ausgabe repräsentiert eine Schicht des Images. Die Schichten sind von der neuesten (oben) bis zur ältesten (unten) aufgelistet. Das Basis-Image (ubuntu:latest in unserem Fall) bildet die unterste Schicht.

Sie können auch das Flag -q verwenden, um nur die Image-IDs anzuzeigen.

docker history -q my-fortune-image

Dies kann nützlich sein, wenn Sie nur die Layer-IDs für Skripte oder andere Zwecke benötigen.

Der docker history-Befehl ist ein leistungsfähiges Werkzeug, um den Aufbau eines Docker-Images zu verstehen und Probleme im Zusammenhang mit Image-Schichten zu debuggen.

OpenTelemetry-Trace eines Build-Datensatzes anzeigen

In diesem Schritt lernen Sie, wie Sie den OpenTelemetry-Trace eines Docker-Build-Datensatzes einsehen können. OpenTelemetry ist eine Sammlung von Tools, APIs und SDKs, die zur Instrumentierung, Generierung, Sammlung und Export von Telemetriedaten (Metriken, Logs und Traces) verwendet werden, um die Leistung und das Verhalten Ihrer Software zu analysieren. Docker kann mit OpenTelemetry integriert werden, um detaillierte Traces des Build-Prozesses bereitzustellen.

Um den OpenTelemetry-Trace anzuzeigen, müssen Sie das Tracing beim Erstellen des Images aktivieren. Wir werden das my-fortune-image mit aktiviertem Tracing neu erstellen.

Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden.

cd ~/project

Erstellen Sie das Image nun erneut, aber diesmal setzen wir die Umgebungsvariable BUILDKIT_TRACE, um das Tracing zu aktivieren. Wir verwenden außerdem das Flag --progress=plain, um die Build-Ausgabe direkt zu sehen.

BUILDKIT_TRACE=trace.json docker build --progress=plain -t my-fortune-image .

Dieser Befehl erstellt das Image neu und speichert die OpenTelemetry-Trace-Daten in einer Datei namens trace.json im aktuellen Verzeichnis.

Nach Abschluss des Builds können Sie den Inhalt der trace.json-Datei einsehen. Diese Datei enthält die Trace-Daten im JSON-Format.

cat trace.json

Die Ausgabe wird ein großes JSON-Objekt sein, das detaillierte Informationen über den Build-Prozess enthält, einschließlich der Dauer jedes Schritts, Abhängigkeiten und anderer Metadaten. Diese Trace-Daten können in ein OpenTelemetry-kompatibles Tracing-Backend (wie Jaeger oder Zipkin) importiert werden, um sie zu visualisieren und zu analysieren.

Auch wenn wir in diesem Lab kein vollständiges Tracing-Backend einrichten werden, ist das Verständnis, wie die Trace-Datei generiert wird, der erste Schritt, um OpenTelemetry für die Docker-Build-Analyse zu nutzen.

Traces zweier Build-Datensätze vergleichen

In diesem Schritt lernen Sie, wie Sie OpenTelemetry-Traces von zwei verschiedenen Docker-Build-Datensätzen generieren und vergleichen können. Der Vergleich von Traces ist nützlich, um Leistungsunterschiede zwischen Builds zu identifizieren, insbesondere nach Änderungen an Ihrer Dockerfile oder der Build-Umgebung.

Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden.

cd ~/project

Wir haben bereits eine trace.json-Datei vom vorherigen Build. Benennen wir sie in trace1.json um, um sie zu behalten.

mv trace.json trace1.json

Nun nehmen wir eine kleine Änderung an unserer Dockerfile vor und erstellen das Image erneut, wobei wir eine zweite Trace-Datei generieren. Wir fügen der Dockerfile eine einfache LABEL-Anweisung hinzu.

Öffnen Sie die Dockerfile zur Bearbeitung.

nano Dockerfile

Fügen Sie folgende Zeile nach der CMD-Anweisung ein:

LABEL version="1.0"

Die aktualisierte Dockerfile sollte nun so aussehen:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y --no-install-recommends fortune-mod
CMD ["/usr/games/fortune"]
LABEL version="1.0"

Speichern Sie die Datei und beenden Sie nano.

Erstellen Sie nun das Image erneut und generieren Sie eine neue Trace-Datei namens trace2.json.

BUILDKIT_TRACE=trace2.json docker build --progress=plain -t my-fortune-image .

Nach Abschluss des Builds haben Sie zwei Trace-Dateien: trace1.json und trace2.json.

Während der direkte Vergleich der rohen JSON-Dateien schwierig sein kann, sind diese Dateien für die Verwendung mit OpenTelemetry-Tracing-Backends konzipiert. In einem realen Szenario würden Sie beide Dateien (trace1.json und trace2.json) in ein Tracing-Visualisierungstool (wie Jaeger) importieren. Dieses Tool würde es ermöglichen, die Zeitabläufe und Spans der beiden Builds visuell zu vergleichen, um Unterschiede in der Ausführungszeit zu erkennen und festzustellen, welche Schritte von Ihren Änderungen betroffen waren.

Wenn Sie diese Traces beispielsweise in Jaeger betrachten würden, sähen Sie die einzelnen Schritte des Docker-Builds (wie FROM, RUN, CMD, LABEL) als Spans. Sie könnten dann die Dauer dieser Spans zwischen den beiden Traces vergleichen, um festzustellen, ob das Hinzufügen der LABEL-Anweisung messbare Auswirkungen auf die Build-Zeit hatte.

Da wir in diesem Lab kein Tracing-Backend eingerichtet haben, werden wir lediglich überprüfen, dass beide Trace-Dateien existieren.

Zusammenfassung

In diesem Lab haben Sie gelernt, wie man ein Docker-Image aus einer Dockerfile mit dem Befehl docker build erstellt und das Image zur einfachen Identifizierung mit einem Tag versieht. Anschließend haben Sie untersucht, wie Sie den Build-Verlauf des erstellten Images mit dem Befehl docker history einsehen können, der Einblicke in die während des Build-Prozesses verwendeten Layer und Befehle bietet.

Das Lab führte Sie weiterhin durch die detailliertere Auflistung von Build-Verlaufsdatensätzen und zeigte die Informationen auf, die über den docker history-Befehl verfügbar sind. Sie haben außerdem gelernt, wie Sie den OpenTelemetry-Trace eines bestimmten Build-Datensatzes anzeigen können, was eine tiefergehende Analyse des Build-Prozesses ermöglicht. Abschließend haben Sie praktisch geübt, die Traces zweier verschiedener Build-Datensätze zu vergleichen - eine nützliche Methode, um Änderungen nachzuvollziehen und Build-Probleme zu debuggen.