Comment visualiser les traces de build Docker avec docker buildx history trace

Introduction

Dans ce lab, vous apprendrez à utiliser docker buildx history trace pour visualiser et analyser les traces de construction de vos images Docker. Vous commencerez par construire une image Docker simple et enregistrer son historique de construction à l'aide des commandes Docker standard.

Après la construction initiale, vous explorerez comment lister les enregistrements d'historique de construction sauvegardés, puis vous plongerez dans la visualisation des traces OpenTelemetry détaillées d'un enregistrement de construction spécifique. Enfin, vous apprendrez à comparer les traces de deux enregistrements de construction différents, ce qui fournira des informations précieuses sur le processus de construction et les optimisations potentielles.

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{{"Comment utiliser docker buildx history trace pour visualiser les traces de build"}} docker/images -.-> lab-555056{{"Comment utiliser docker buildx history trace pour visualiser les traces de build"}} docker/build -.-> lab-555056{{"Comment utiliser docker buildx history trace pour visualiser les traces de build"}} end

Construire une image et enregistrer son historique

Dans cette étape, vous apprendrez à construire une image Docker et à enregistrer son historique de construction. Les images Docker sont construites à partir d'un Dockerfile, un fichier texte contenant toutes les commandes qu'un utilisateur pourrait exécuter en ligne de commande pour assembler une image.

Commencez par créer un simple Dockerfile. Placez-vous dans le répertoire ~/project si ce n'est pas déjà fait.

cd ~/project

Maintenant, créez un fichier nommé Dockerfile avec l'éditeur nano.

nano Dockerfile

Ajoutez le contenu suivant au Dockerfile :

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

Ce Dockerfile part de l'image Ubuntu la plus récente, met à jour la liste des paquets, installe le paquet fortune-mod et définit la commande par défaut pour exécuter le programme fortune.

Enregistrez le fichier et quittez nano (appuyez sur Ctrl + X, puis Y, puis Entrée).

Maintenant, construisons l'image Docker avec la commande docker build. Nous allons étiqueter l'image comme my-fortune-image et utiliser le répertoire courant (.) comme contexte de construction.

docker build -t my-fortune-image .

Vous verrez une sortie indiquant le processus de construction, incluant le téléchargement de l'image de base et l'exécution de la commande apt-get.

Pour enregistrer l'historique de construction, nous pouvons utiliser la commande docker history. Cette commande affiche l'historique d'une image.

docker history my-fortune-image

La sortie affichera une liste des couches composant l'image, ainsi que la commande utilisée pour créer chaque couche, la taille de la couche et sa date de création. Cet historique est utile pour comprendre comment une image a été construite et pour le débogage.

Lister les enregistrements d'historique de construction

Dans cette étape, vous en apprendrez davantage sur la liste des enregistrements d'historique de construction d'une image Docker. Comme vous l'avez vu à l'étape précédente, la commande docker history fournit une vue détaillée des couches qui composent une image.

Exécutons à nouveau la commande docker history pour l'image my-fortune-image que nous avons construite précédemment.

docker history my-fortune-image

Le résultat affiche plusieurs colonnes :

IMAGE : L'ID de la couche d'image
CREATED : L'horodatage de création de la couche
CREATED BY : La commande ayant créé la couche
SIZE : La taille de la couche
COMMENT : Tout commentaire associé à la couche

Chaque ligne du résultat représente une couche de l'image. Les couches sont listées de la plus récente (en haut) à la plus ancienne (en bas). L'image de base (ubuntu:latest dans notre cas) se trouve dans la couche inférieure.

Vous pouvez également utiliser l'option -q pour n'afficher que les IDs d'images.

docker history -q my-fortune-image

Cela peut être utile si vous n'avez besoin que des IDs de couches pour des scripts ou d'autres usages.

La commande docker history est un outil puissant pour comprendre la composition d'une image Docker et pour déboguer des problèmes liés aux couches d'images.

Visualiser la trace OpenTelemetry d'un enregistrement de build

Dans cette étape, vous apprendrez comment visualiser la trace OpenTelemetry d'un enregistrement de build Docker. OpenTelemetry est un ensemble d'outils, d'API et de SDK utilisés pour instrumenter, générer, collecter et exporter des données de télémétrie (métriques, logs et traces) afin d'analyser les performances et le comportement de votre logiciel. Docker peut s'intégrer avec OpenTelemetry pour fournir des traces détaillées du processus de build.

Pour visualiser la trace OpenTelemetry, vous devez activer le tracing lors de la construction de l'image. Nous allons reconstruire l'image my-fortune-image avec le tracing activé.

Tout d'abord, assurez-vous d'être dans le répertoire ~/project.

cd ~/project

Maintenant, reconstruisez l'image, mais cette fois en définissant la variable d'environnement BUILDKIT_TRACE pour activer le tracing. Nous utiliserons également le flag --progress=plain pour voir directement la sortie du build.

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

Cette commande reconstruira l'image et sauvegardera les données de trace OpenTelemetry dans un fichier nommé trace.json dans le répertoire courant.

Une fois le build terminé, vous pouvez visualiser le contenu du fichier trace.json. Ce fichier contient les données de trace au format JSON.

cat trace.json

La sortie sera un gros objet JSON contenant des informations détaillées sur le processus de build, incluant la durée de chaque étape, les dépendances et d'autres métadonnées. Ces données de trace peuvent être importées dans un backend de tracing compatible OpenTelemetry (comme Jaeger ou Zipkin) pour visualisation et analyse.

Bien que nous ne configurerons pas un backend de tracing complet dans ce lab, comprendre comment générer le fichier de trace constitue la première étape pour exploiter OpenTelemetry dans l'analyse des builds Docker.

Comparer les traces de deux enregistrements de build

Dans cette étape, vous apprendrez comment générer et comparer les traces OpenTelemetry de deux enregistrements de build Docker différents. La comparaison des traces peut être utile pour identifier les différences de performance entre les builds, notamment après avoir apporté des modifications à votre Dockerfile ou à l'environnement de build.

Tout d'abord, assurez-vous d'être dans le répertoire ~/project.

cd ~/project

Nous disposons déjà d'un fichier trace.json provenant du build précédent. Renommons-le en trace1.json pour le conserver.

mv trace.json trace1.json

Maintenant, apportons une petite modification à notre Dockerfile et reconstruisons l'image, en générant un second fichier de trace. Nous allons ajouter une simple instruction LABEL au Dockerfile.

Ouvrez le Dockerfile pour le modifier.

nano Dockerfile

Ajoutez la ligne suivante après l'instruction CMD :

LABEL version="1.0"

Le Dockerfile mis à jour devrait ressembler à ceci :

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

Enregistrez le fichier et quittez nano.

Maintenant, reconstruisez l'image en générant un nouveau fichier de trace nommé trace2.json.

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

Une fois le build terminé, vous disposerez de deux fichiers de trace : trace1.json et trace2.json.

Bien que la comparaison directe des fichiers JSON bruts puisse être complexe, ces fichiers sont conçus pour être utilisés par des backends de tracing OpenTelemetry. Dans un scénario réel, vous importeriez les deux fichiers trace1.json et trace2.json dans un outil de visualisation de traces (comme Jaeger). Cet outil vous permettrait de comparer visuellement les chronologies et les spans des deux builds, facilitant l'identification des différences de temps d'exécution et des étapes affectées par vos modifications.

Par exemple, si vous visualisiez ces traces dans Jaeger, vous verriez les étapes individuelles du build Docker (comme FROM, RUN, CMD, LABEL) sous forme de spans. Vous pourriez alors comparer la durée de ces spans entre les deux traces pour voir si l'ajout de l'instruction LABEL a eu un impact mesurable sur le temps de build.

Comme nous n'avons pas configuré de backend de tracing dans ce lab, nous nous contenterons de vérifier que les deux fichiers de trace existent.

Résumé

Dans ce lab, vous avez appris à construire une image Docker à partir d'un Dockerfile en utilisant la commande docker build, tout en taguant l'image pour une identification facile. Vous avez ensuite exploré comment visualiser l'historique de build de l'image créée à l'aide de la commande docker history, qui fournit des informations sur les couches et les commandes utilisées lors du processus de build.

Le lab vous a également guidé pour lister les enregistrements d'historique de build avec plus de détails, démontrant les informations disponibles via la commande docker history. Vous avez aussi appris à visualiser la trace OpenTelemetry d'un enregistrement de build spécifique, permettant une analyse approfondie du processus de build. Enfin, vous avez pratiqué la comparaison des traces de deux enregistrements de build différents, ce qui est utile pour comprendre les changements et déboguer les problèmes de build.