TP-03 — Réduire une image avec une construction multistage

Dockerfile.sdk conserve le SDK .NET, qui contient les outils de compilation, dans l’image finale.

Dans Dockerfile, nous ajoutons une dernière étape :

# Démarrer une étape de construction basée sur l’image indiquée.
FROM mcr.microsoft.com/dotnet/aspnet:8.0.15-bookworm-slim AS runtime

Ce nouveau FROM démarre une étape indépendante, basée sur une image contenant le runtime ASP.NET nécessaire à l’exécution, sans le SDK.

Nous y copions uniquement l’application compilée depuis l’étape build :

# Copier les artefacts de l’étape de construction vers l’image finale.
COPY --from=build /out/ ./

Les outils de compilation restent dans l’étape build et ne sont pas embarqués dans l’image finale.
Le nom runtime désigne cette étape ; c’est le choix de l’image après FROM qui détermine son contenu.
La ligne COPY --from=front ajoute aussi les fichiers du front déjà compilés, sans embarquer les outils Node.

Avec la commande suivante, nous pouvons examiner les informations des deux images :

# Afficher les informations des deux images pour examiner Id et RepoDigests.
docker image inspect asd-tp03-sdk:1.0 asd-todo:1.0

Deux champs sont intéressants :

• Id : l’empreinte SHA-256 de la configuration de l’image locale. Elle permet notamment de vérifier si deux tags désignent la même image locale : même Id, même image.
• RepoDigests : les références connues sous la forme dépôt@sha256:…. Chaque référence associe un dépôt au digest d’un manifeste ou d’un index dans un registre. Ce champ devrait être vide pour nos images construites localement, car nous ne les avons pas publiées.

Pourquoi utiliser un digest plutôt qu’un tag ?

Un tag est une étiquette que l’on peut réaffecter à une autre image.

Par exemple, les tags asd-tp03-sdk:1.0 et asd-todo:1.0 désignent actuellement les images que nous venons de construire. Ils peuvent être réaffectés à d’autres images lors d’une prochaine construction avec les mêmes tags. Dans un registre, une nouvelle publication sous un même tag peut également remplacer l’image qu’il désigne.

Une référence par digest permet de demander exactement le même contenu publié, même si le tag a été déplacé depuis.

Un digest est immuable : il ne change jamais. Si une reconstruction produit un contenu différent, celui-ci possède un autre digest ; l’ancien reste associé à son contenu initial. Une reconstruction à l’identique ne produit donc pas nécessairement un nouveau digest.

Pour approfondir : 3.5 — Identifier les images : noms, tags et digests.

Vous pouvez aussi afficher les images dont le nom commence par asd-.
Voici un exemple de résultat ; les identifiants et les tailles peuvent différer sur votre poste.

# Lister les images correspondant au filtre pour vérifier leur présence.
docker image ls asd-*

IMAGE              ID             DISK USAGE   CONTENT SIZE   EXTRA
asd-todo:1.0       4a820dd8d40a        329MB         92.7MB    U
asd-tp02-web:1.0   466ad37191f3       73.7MB           21MB    U
asd-tp03-sdk:1.0   80ef4daa6f3f       1.27GB          342MB    U

# Lire les métadonnées de l’image pour contrôler son identité ou sa construction.
docker image inspect asd-tp03-sdk:1.0 asd-todo:1.0 --format '{{.RepoTags}} {{.Size}}'
[asd-tp03-sdk:1.0] 341773478
[asd-todo:1.0] 92656081

Avec le stockage containerd, les deux colonnes mesurent des choses différentes :

• CONTENT SIZE : taille du contenu compressé de l’image.
• DISK USAGE : occupation locale comprenant le contenu compressé et les couches décompressées utilisées pour exécuter les conteneurs. Le stockage containerd conserve ces deux formes.

Dans cet exemple, le champ .Size de docker image inspect correspond à CONTENT SIZE, exprimé en octets : 341773478 octets donnent environ 342 MB, et 92656081 octets environ 92,7 MB.
Il ne correspond pas à la colonne DISK USAGE.

Pour comparer les images, utilisez la même mesure pour les deux et calculez la réduction à partir de vos résultats.

Documentation Docker — stockage containerd et espace disque

Dans le Dockerfile fautif, l’instruction RUN dotnet publish -c Release -o /out --no-restore produit les fichiers de l’application dans /out, à l’intérieur de l’étape build.
Le chemin /publication-absente/ utilisé par COPY --from=build n’existe pas dans cette étape.

Remplacez uniquement cette instruction par :

# Copier la publication réellement produite dans l’étape build vers /app.
COPY --from=build /out/ ./

Cette ligne est celle du Dockerfile fonctionnel étudié au début du TP.
Depuis le dossier todo-list-fault où vous êtes déjà placé, reconstruisez l’image, puis vérifiez que l’application répond :

Terminal — PowerShell (Windows) ou Bash (Linux)

# Vérifier que la construction réussit après la correction du chemin COPY.
docker build --progress=plain -t asd-tp03-fault:1.0 .

# Démarrer l’image corrigée dans un conteneur de vérification.
docker run -d --name asd-tp03-correction -p 127.0.0.1:8089:8080 asd-tp03-fault:1.0

# Attendre le démarrage et vérifier que le point de santé répond sans erreur.
curl --retry 10 --retry-connrefused --retry-delay 1 -f http://127.0.0.1:8089/healthz

À observer : le build franchit l’instruction COPY et termine sans l’erreur de chemin initiale ; /healthz répond HTTP 200.
Comme seul le chemin source de COPY a été modifié, cette comparaison confirme la cause de l’échec initial.

• COPY --from transfère les artefacts d’une étape.
• Le runtime reste nécessaire pour cette publication.
• Build produit une image, run crée/exécute un conteneur.