Lire une image OCI et son identité

Vous lancez busybox:1.37.0 aujourd'hui, un collègue le lance demain : rien ne garantit que vous exécutiez la même image. Cette leçon vous apprend à dire exactement quelle image tourne sur une machine, par son empreinte, et pour quelle plateforme. Vous lirez ce que Docker affiche pour une image tirée par son tag, puis par son digest, vous inspecterez une image qui existe pour plusieurs plateformes, vous constaterez qu'un même tag peut désigner deux images successives, et vous retrouverez l'image de base d'une image que vous avez construite.

L'angle est celui de Docker : ce que docker image ls, docker image inspect et docker inspect affichent, et ce qu'ils omettent. La structure OCI elle-même, ouverte sans moteur, est détaillée dans Lire une image OCI et vérifier son digest ; le format et ses spécifications sont dans Comprendre OCI. Le diagnostic de exec format error au choix d'un socle est dans choisir une image de base. La publication d'une image et son pull par digest sont dans Publier et récupérer une image de façon maîtrisée. La construction multi-architecture, la signature des images et la vérification des attestations ne sont pas traitées ici.

Les sorties de cette page viennent de Docker Engine 29.9.2 et de Buildx 0.38.1, sur une machine Debian 13 en amd64. Docker y range ses images dans le magasin containerd (l'endroit du disque où le moteur stocke les images), le choix par défaut des nouvelles installations de Docker 29. Les digests de busybox sont ceux relevés le 3 novembre 2026, et la section sur la plateforme étrangère emploie un autre index de busybox que le reste de la leçon ; les digests des images que vous construirez différeront de ceux de la page.

Ce que vous allez apprendre

• Distinguer le tag, l'index, le manifeste, la configuration et la couche d'une image
• Lire dans docker image inspect l'identité que Docker garde pour une image, et savoir si c'est celle d'un index ou d'un manifeste
• Vérifier qu'un conteneur lancé par tag et un conteneur lancé par digest exécutent la même image
• Lire l'état d'une image dont seule une plateforme étrangère est stockée, et inspecter la bonne plateforme
• Prouver qu'un même tag a désigné deux images différentes
• Retrouver, dans la provenance, l'image de base réellement utilisée par une construction, avec son propre digest

Prérequis

• Un Docker Engine qui fonctionne (installation de Docker), et un accès à Docker Hub pour tirer une image publique.
• Savoir construire une image à partir d'un Dockerfile (écrire un Dockerfile).
• Savoir publier une image dans un registre et la tirer par digest (publier et récupérer une image).
• Avoir vu pourquoi un tag peut changer de contenu (choisir une image de base).

De quoi est faite l'identité d'une image ?

Une image n'a pas un nom unique mais une chaîne de documents, et seul le digest d'un document est fiable. Le tag 1.37.0 est un nom que l'éditeur peut déplacer. Il mène à un index, la liste des manifestes de l'image, un par plateforme. Une plateforme est la combinaison d'un système et d'une architecture de processeur, par exemple linux/amd64.

Chaque manifeste décrit l'image pour une seule plateforme. Il désigne une configuration (la plateforme, les variables d'environnement, la commande par défaut et la liste des couches) et des couches (les archives des fichiers).

Le digest est l'empreinte d'un de ces documents : une valeur calculée sur ses octets (en pratique avec sha256), qui change dès qu'un seul octet change. Celui de l'index identifie l'image pour toutes ses plateformes, celui d'un manifeste l'image pour une seule.

Le schéma suit cette chaîne de haut en bas. Le tag, tout en haut, est le seul maillon qui peut changer. L'index, encadré en rouge, est ce que le registre renvoie quand vous lui demandez le tag. Dessous, un manifeste par plateforme, dont linux/amd64 et linux/arm64/v8 ; les autres plateformes tiennent dans une case grisée. Le manifeste linux/amd64 mène à sa configuration et à sa couche. La case grisée « Docker local », en haut, annonce ce que les sections suivantes mesurent : l'identité que Docker retient en local est celle de l'index.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

L'index n'est pas toujours là : une image construite pour une seule plateforme peut être publiée avec un manifeste seul. Les images officielles comme busybox, elles, publient un index.

Que contient le tag que je viens de tirer ?

Tirez l'image par son tag. Cette commande est le point de départ du comparatif, pas un modèle à suivre en production, puisque le contenu derrière un tag peut changer.

docker pull busybox:1.37.0   # ❌ tag seul, pour le comparer au digest

1.37.0: Pulling from library/busybox
68fe9bff2ad4: Pulling fs layer
68fe9bff2ad4: Download complete
9177639ff916: Download complete
68fe9bff2ad4: Pull complete
Digest: sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec
Status: Downloaded newer image for busybox:1.37.0
docker.io/library/busybox:1.37.0

Trois lignes comptent. La ligne 68fe9bff2ad4 est la seule couche téléchargée : une image se transfère couche par couche. La ligne 9177639ff916: Download complete n'est pas une couche, c'est l'attestation de cette plateforme (même chose que pour arm64 plus bas). La ligne Digest: donne l'empreinte de ce que le registre a servi pour le tag, et c'est celle de l'index, ce que vous allez vérifier ci-dessous.

Relevez ce digest dans une variable, pour le réutiliser sans le recopier :

IDX=$(docker image inspect busybox:1.37.0 --format '{{index .RepoDigests 0}}' | cut -d@ -f2)
echo "$IDX"

Si votre digest diffère de a7dbc319…, le tag a été republié depuis le relevé de cette page : c'est exactement le phénomène que la leçon étudie, et vous gardez le vôtre. Les sorties ci-dessous gardent a7dbc319…. Listez maintenant les images avec leur digest. Les sorties de cette page ne gardent que les images de la leçon ; votre liste en contient peut-être d'autres.

docker image ls --digests

REPOSITORY   TAG       DIGEST                                                                    IMAGE ID       CREATED       SIZE
busybox      1.37.0    sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec   a7dbc319b143   2 years ago   6.77MB

La colonne DIGEST reprend celui du pull, et la colonne IMAGE ID en est le début : a7dbc319b143 correspond aux douze premiers caractères du digest. Avec le magasin containerd, l'identifiant local d'une image tirée par son tag est le digest de son index, comme celui d'une image construite. RepoDigests (lu plus bas) porte ce même digest précédé du nom, et c'est la forme à noter pour une image venue d'un registre, comme le montre publier et récupérer une image. Avec un autre magasin d'images, l'identifiant local peut être une valeur que le registre ne connaît pas : notez RepoDigests, pas l'identifiant local.

Pour voir les plateformes que l'index annonce, ajoutez l'option --tree :

docker image ls --tree

IMAGE              ID               DISK USAGE   CONTENT SIZE   EXTRA
busybox:1.37.0     a7dbc319b143         6.77MB         2.22MB
├─ linux/amd64     66a6306db78b         6.77MB         2.21MB
├─ linux/arm/v5    88132f86ce62             0B             0B
├─ linux/arm/v6    6d857b42a8c6             0B             0B
├─ linux/arm/v7    91aa2a66a996             0B             0B
├─ linux/arm64/v8  d82c2ab94640             0B             0B
├─ linux/386       a88c21a22c5d             0B             0B
├─ linux/ppc64le   025d95c7d9b6             0B             0B
├─ linux/riscv64   be2e8702261d             0B             0B
└─ linux/s390x     7f0d4675ec87             0B             0B

L'index annonce neuf plateformes linux, et chacune porte l'identifiant de son manifeste. Regardez la colonne DISK USAGE : seule linux/amd64 occupe de la place (6,77 Mo), parce que Docker n'a téléchargé que le contenu de la plateforme de votre machine, ici amd64. Les huit autres sont connues par leur manifeste, mais leurs couches ne sont pas sur le disque.

L'index brut de ce tag compte en réalité dix-sept entrées : les neuf plateformes, et huit attestations. Une attestation est un manifeste de plateforme unknown/unknown qui décrit la fabrication de l'image au lieu de contenir des fichiers à exécuter (voir lire une image OCI). docker image ls --tree ne les affiche pas.

Quelle identité Docker garde-t-il pour cette image ?

Lisez la fiche complète de l'image avec docker image inspect.

docker image inspect busybox:1.37.0

[
    {
        "Id": "sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec",
        "RepoTags": [
            "busybox:1.37.0"
        ],
        "RepoDigests": [
            "busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec"
        ],
        "Created": "2024-09-26T21:31:42Z",
        "Config": {
            "Env": [
                "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
            ],
            "Cmd": [
                "sh"
            ]
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 6767335,
        "RootFS": {
            "Type": "layers",
            "Layers": [
                "sha256:5a9bfd996c6d49c6c3cb4ddfb76e8d09cf16b6b7cf6601d1f2dffbdbc3edb5d4"
            ]
        },
        …
        "Descriptor": {
            "mediaType": "application/vnd.oci.image.index.v1+json",
            "digest": "sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec",
            "size": 9535
        },
        …
    }
]

La sortie est tronquée par … aux endroits sans intérêt pour cette leçon (l'horodatage du tag et la provenance du pull). Cinq repères portent l'identité.

• Id et Descriptor.digest ont la même valeur, et Descriptor.mediaType dit pourquoi : c'est un index (application/vnd.oci.image.index.v1+json, 9535 octets).
• RepoDigests porte aussi le digest de l'index, pas celui du manifeste linux/amd64. C'est la valeur à noter pour retrouver cette image sur un registre.
• Architecture et Os disent pour quelle plateforme cette image locale est faite. Il n'y a pas de clé Variant. Le variant précise l'architecture (comme v8 pour arm64), mais seules certaines images en déclarent un, et l'image amd64 de busybox n'en déclare pas.
• RootFS.Layers liste les couches par l'empreinte de leur contenu décompressé. L'image n'en a qu'une, 5a9bfd99…. Cette valeur n'est pas 68fe9bff2ad4, l'empreinte affichée au pull : celle-ci est l'empreinte de l'archive compressée téléchargée, le digest de la liste layers du manifeste linux/amd64. Lire une image OCI explique pourquoi une couche a deux empreintes.
• Created vaut le 26 septembre 2024, alors que les annotations de l'entrée linux/amd64 de l'index (visibles plus bas) annoncent une création le 8 septembre 2026. Les deux dates ne mesurent pas la même chose : l'une est écrite dans la configuration de l'image, l'autre dans ces annotations. Ne déduisez pas l'âge d'une image avant d'avoir identifié laquelle vous lisez.

Un conteneur lancé par tag et un par digest exécutent-ils la même image ?

Lancez deux conteneurs sur la même image, l'un désigné par son tag, l'autre par le digest relevé plus haut dans $IDX.

docker run -d --name essai-tag busybox:1.37.0 sleep 300   # ❌ tag seul, pour la comparaison
docker run -d --name essai-digest busybox@$IDX sleep 300

Chaque commande affiche l'identifiant long du conteneur créé. Interrogez ensuite les deux conteneurs sur l'image qu'ils exécutent et sur la référence saisie à la création :

docker inspect essai-tag --format 'Image={{.Image}} | Config.Image={{.Config.Image}}'
docker inspect essai-digest --format 'Image={{.Image}} | Config.Image={{.Config.Image}}'

Image=sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec | Config.Image=busybox:1.37.0
Image=sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec | Config.Image=busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec

Le champ Image est identique dans les deux cas : les deux conteneurs exécutent la même image. Le champ Config.Image, lui, garde la référence telle qu'elle a été saisie. Il prouve ce que vous avez tapé, pas ce qui tourne. Un conteneur lancé par tag affiche toujours son tag, même si le tag a été déplacé depuis ; seul Image (ou le digest du manifeste, ci-dessous) dit sur quel contenu il repose.

La colonne IMAGE de docker ps suit la même logique, avec une surprise :

docker ps --format '{{.Names}} {{.Image}}'

essai-digest a7dbc319b143
essai-tag busybox:1.37.0

Pour le conteneur lancé par digest, docker ps n'affiche pas la référence saisie mais l'identifiant raccourci de l'image. Si vous cherchez un digest dans la sortie de docker ps, vous ne le trouverez pas : passez par docker inspect.

Un dernier champ nomme le manifeste réellement utilisé parmi ceux de l'index :

docker inspect essai-tag --format 'ImageManifestDescriptor={{json .ImageManifestDescriptor}}'

ImageManifestDescriptor={"mediaType":"application/vnd.oci.image.manifest.v1+json","digest":"sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4","size":610,"annotations":{"com.docker.official-images.bashbrew.arch":"amd64","org.opencontainers.image.base.name":"scratch","org.opencontainers.image.created":"2026-09-08T23:04:09Z","org.opencontainers.image.revision":"066dbf90090ab2dbb905310fac2fa10ea39a7ba6","org.opencontainers.image.source":"https://github.com/docker-library/busybox.git","org.opencontainers.image.url":"https://hub.docker.com/_/busybox","org.opencontainers.image.version":"1.37.0-glibc"},"platform":{"architecture":"amd64","os":"linux"}}

Regardez digest et platform : sha256:66a6306d… est le manifeste linux/amd64 de l'index, celui que le conteneur a réellement utilisé, et sa plateforme est linux/amd64. L'index offre neuf choix, le conteneur en exécute un. Supprimez les deux conteneurs avant de continuer :

docker rm -f essai-tag essai-digest

Tirer le digest d'un manifeste donne-t-il la même identité ?

Non. Le digest de l'index et le digest d'un manifeste désignent deux documents différents, donc deux identités locales différentes pour Docker. Supprimez l'image, puis tirez le manifeste linux/amd64 directement par son digest.

docker image rm busybox:1.37.0
docker pull busybox@sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4
docker image ls --digests

docker.io/library/busybox@sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4: Pulling from library/busybox
68fe9bff2ad4: Pulling fs layer
68fe9bff2ad4: Download complete
68fe9bff2ad4: Pull complete
Digest: sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4
Status: Downloaded newer image for busybox@sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4
docker.io/library/busybox@sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4
REPOSITORY   TAG       DIGEST                                                                    IMAGE ID       CREATED       SIZE
busybox      <none>    sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4   66a6306db78b   2 years ago   6.77MB

La couche est la même (68fe9bff2ad4), mais l'identité locale est maintenant 66a6306db78b, le début du digest du manifeste, et non plus a7dbc319b143. Les deux images partagent leur contenu et ont deux identités : l'une désigne « busybox pour toutes les plateformes », l'autre « busybox pour linux/amd64 seulement ».

Le digest à épingler dépend donc de ce que vous voulez figer. Avec le digest de l'index, la plateforme est choisie à l'exécution selon la machine. Avec le digest d'un manifeste, vous figez la plateforme, et, sans émulation, l'image ne démarrera pas sur une machine d'une autre architecture. Pour un déploiement qui peut tourner sur des machines différentes, le digest de l'index est la bonne référence. Supprimez cette image avant de continuer :

docker image rm busybox@sha256:66a6306db78bf2dbf3487f293aa8d6990d8e506fdffab9cc43fe422becf886e4

Que se passe-t-il avec une plateforme qui n'est pas celle de la machine ?

Tirer une seule plateforme, et de surcroît une plateforme étrangère à la machine, laisse le magasin dans un état particulier : l'index est présent, mais aucun contenu n'existe pour la plateforme de la machine. Le diagnostic de exec format error (code de sortie 255, avertissement du moteur, rôle de binfmt_misc) est déjà démontré dans choisir une image de base. Cette section regarde ce que cette autre leçon ne montre pas : ce que docker image ls et docker image inspect rendent dans cet état, et pourquoi l'identité d'une image dépend de la plateforme interrogée.

Pour partir d'un magasin où aucune plateforme n'est présente, elle emploie un index de busybox que la leçon n'a pas encore tiré, celui du tag 1.35.0. Son digest d'index commence par 98ad9d1a. On le désigne sous la forme busybox@sha256:…, car Docker ne conserve pas le tag quand on tire par digest. Contrôlez d'abord qu'il est absent : la commande suivante ne doit rien afficher.

docker image ls --digests | grep 98ad9d1a2be3

Tirez cet index en demandant la plateforme linux/arm64, alors que la machine est en amd64 :

docker pull --platform linux/arm64 busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a

docker.io/library/busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a: Pulling from library/busybox
235378d388b7: Pulling fs layer
0260d15b349c: Download complete
235378d388b7: Download complete
235378d388b7: Pull complete
Digest: sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a
Status: Downloaded newer image for busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a
docker.io/library/busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a

Le pull réussit : Docker ne vérifie pas que la plateforme demandée est exécutable sur cette machine. 235378d388b7 est la couche arm64. La ligne 0260d15b349c n'est pas la configuration de l'image, c'est le document d'attestation de cette plateforme, que vous pouvez ignorer ici. Regardez maintenant l'état du magasin.

docker image ls --tree

IMAGE                                                                             ID             DISK USAGE   CONTENT SIZE   EXTRA
busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a   98ad9d1a2be3       6.01MB         1.84MB
├─ linux/amd64                                                                    584c3aa5ea27           0B             0B
├─ linux/arm/v5                                                                   09eda79e741b           0B             0B
├─ linux/arm/v6                                                                   239384fd9d83           0B             0B
├─ linux/arm/v7                                                                   d54919441af6           0B             0B
├─ linux/arm64/v8                                                                 2c600b8134e6       6.01MB         1.84MB
├─ linux/386                                                                      9d52a4c48435           0B             0B
├─ linux/mips64le                                                                 5cf00c12beea           0B             0B
├─ linux/ppc64le                                                                  48bab78e87cc           0B             0B
├─ linux/riscv64                                                                  a1051192e4b2           0B             0B
└─ linux/s390x                                                                    cb5e3290aa0c           0B             0B

Lisez la colonne DISK USAGE : l'index est présent (6,01 Mo au total), mais la ligne linux/amd64, la plateforme de la machine, occupe 0B, et seule linux/arm64/v8 occupe de la place. C'est l'inverse du pull par tag de la section précédente. Pour Docker, l'image est donc bien là, sans aucun contenu que cette machine puisse exécuter.

docker image ls --digests

REPOSITORY   TAG       DIGEST                                                                    IMAGE ID       CREATED        SIZE
busybox      <none>    sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a   98ad9d1a2be3   56 years ago   6.01MB

L'identité est celle de l'index (98ad9d1a2be3), comme pour un pull par tag, mais deux détails diffèrent. La colonne CREATED affiche « 56 years ago » : docker image ls lit la date dans la configuration de la plateforme de la machine, cette configuration n'est pas stockée, le champ Created est absent, et une date absente s'affiche comme l'année 1970. La taille de 6,01 Mo est celle du contenu arm64, le seul sur le disque.

Le piège vient de l'inspection. Sans option de plateforme, docker image inspect lit la plateforme de la machine, et celle-ci n'est pas stockée. La commande réussit (code de sortie 0) et rend une fiche vidée : Config et RootFS valent {}, Architecture et Os valent "", Size vaut 0. La fiche n'a même pas de champ Created, ce que prouve un gabarit qui le lit :

docker image inspect busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a --format 'Id={{.Id}} Arch={{.Architecture}} Os={{.Os}} Created={{.Created}}'

template parsing error: template: :1:55: executing "" at <.Created>: map has no entry for key "Created"

L'image n'est pas cassée : l'inspection interroge une plateforme qui n'est pas stockée. Nommez la plateforme pour lire la bonne fiche :

docker image inspect --platform linux/arm64 busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a --format 'Id={{.Id}} Arch={{.Architecture}} Os={{.Os}} Variant={{.Variant}} layers={{len .RootFS.Layers}} {{json .RootFS.Layers}}'

Id=sha256:2c600b8134e63d2cc2b04c98bb496e721296c31087ac039b074a374d9f4875b8 Arch=arm64 Os=linux Variant=v8 layers=1 ["sha256:6212b10af89b703c40267722bd32ae49a55232e35d759708a386fc1038f23b56"]

Cette fois, l'Id est 2c600b81…, le digest du manifeste linux/arm64/v8 (celui de la sortie --tree ci-dessus), l'architecture est arm64, le variant v8, et la fiche décrit une couche. Pour une même image, l'identité dépend donc de la plateforme que vous interrogez : l'index répond pour toutes, un manifeste pour une seule.

Lancez maintenant un conteneur sur cette image, sans préciser de plateforme, puis en demandant arm64 :

docker run --rm busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a uname -m
echo $?
docker run --rm --platform linux/arm64 busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a uname -m
echo $?

WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v3) and no specific platform was requested
exec /bin/uname: exec format error
255
exec /bin/uname: exec format error
255

Les deux lancements échouent avec le code 255 ; seul l'avertissement disparaît quand --platform est explicite. C'est l'erreur décrite dans choisir une image de base, qui arrive à l'exécution et jamais au pull. Elle suppose qu'aucune émulation d'architecture n'est enregistrée dans le noyau. Pour le vérifier, listez ls /proc/sys/fs/binfmt_misc/ : sur la machine de mesure, la liste contient python3.13, register et status, et aucune entrée pour arm64. Une émulation arm64 apparaîtrait comme une entrée qemu-aarch64 (nom usuel de QEMU, non mesuré ici).

Demandez enfin la plateforme de la machine :

docker run --rm --platform linux/amd64 busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a uname -m

Unable to find image 'busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a' locally
docker.io/library/busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a: Pulling from library/busybox
a9b82d1f2d6e: Pulling fs layer
a9b82d1f2d6e: Download complete
fb0ee184eda1: Download complete
a9b82d1f2d6e: Pull complete
Digest: sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a
Status: Image is up to date for busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a
x86_64

Deux choses se lisent ici. Le message « Unable to find image locally » apparaît alors que l'index est présent : il manque le contenu amd64, et docker run --platform le télécharge au moment du lancement (a9b82d1f2d6e est sa couche, fb0ee184eda1 son attestation). Ensuite, uname -m répond x86_64 : le conteneur tourne. Le magasin contient désormais les deux plateformes :

docker image ls --tree

IMAGE                                                                             ID             DISK USAGE   CONTENT SIZE   EXTRA
busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a   98ad9d1a2be3       12.6MB         3.99MB
├─ linux/amd64                                                                    584c3aa5ea27       6.55MB         2.15MB
├─ linux/arm/v5                                                                   09eda79e741b           0B             0B
├─ linux/arm/v6                                                                   239384fd9d83           0B             0B
├─ linux/arm/v7                                                                   d54919441af6           0B             0B
├─ linux/arm64/v8                                                                 2c600b8134e6       6.01MB         1.84MB
├─ linux/386                                                                      9d52a4c48435           0B             0B
├─ linux/mips64le                                                                 5cf00c12beea           0B             0B
├─ linux/ppc64le                                                                  48bab78e87cc           0B             0B
├─ linux/riscv64                                                                  a1051192e4b2           0B             0B
└─ linux/s390x                                                                    cb5e3290aa0c           0B             0B

L'index occupe 12,6 Mo, la somme des deux contenus (6,55 Mo pour amd64, 6,01 Mo pour arm64/v8).

Un tag peut-il désigner deux images successives ?

Oui, et un registre local suffit à le prouver. Cette section reconstruit la situation que décrit publier et récupérer une image, pour la lire cette fois avec les digests. Lancez un registre local, épinglé par digest, qui n'écoute que sur la boucle locale :

docker run -d --name registre-identite -p 127.0.0.1:5000:5000 registry:3@sha256:d4032d4cc323c1731c707931ecada07a53076eac38e3b61ae57533f170f2c6c3

Dans un dossier de travail, écrivez deux Dockerfile qui ne diffèrent que par le contenu d'un fichier, puis construisez et publiez le premier sous le tag 1.0 :

mkdir -p ~/identite-image && cd ~/identite-image
printf 'FROM busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec\nRUN echo v1 > /version\nCMD ["cat","/version"]\n' > Dockerfile.v1
printf 'FROM busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec\nRUN echo v2 > /version\nCMD ["cat","/version"]\n' > Dockerfile.v2
docker build -f Dockerfile.v1 -t localhost:5000/demo:1.0 .
docker push localhost:5000/demo:1.0

The push refers to repository [localhost:5000/demo]
44136fa355b3: Pushed
68fe9bff2ad4: Pushed
47a073a1b52e: Pushed
8cb537d930a3: Pushed
1.0: digest: sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a size: 855

Le digest affiché en dernière ligne est celui d'un index de 855 octets, alors que vous avez construit pour une seule plateforme. Avec Docker 29.9.2 et le magasin containerd, docker build produit un index qui contient le manifeste de l'image et une attestation de provenance, un document qui décrit comment l'image a été construite. Vous la retrouverez plus bas, sous la forme de l'entrée unknown/unknown que montre imagetools inspect.

Vérifiez que l'identité locale suit le même principe, et gardez ce digest dans une variable :

docker image inspect localhost:5000/demo:1.0 --format '{{.Id}} {{json .RepoDigests}}'
D1=$(docker image inspect localhost:5000/demo:1.0 --format '{{index .RepoDigests 0}}' | cut -d@ -f2)

sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a ["localhost:5000/demo@sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a"]

L'Id local, le digest du push et RepoDigests sont la même valeur, celle de l'index : une image construite suit la même règle qu'une image tirée. RepoDigests est une liste ; index .RepoDigests 0 en prend la première entrée, ce qui est sûr ici puisque l'image n'en a qu'une, et cut -d@ -f2 ne garde que ce qui suit le @. Reconstruisez à présent avec le second Dockerfile, sous le même tag, et republiez. Le docker image rm du bloc suivant retire l'image v1 de la liste locale : le tag 1.0 ne désigne alors que la nouvelle image, et le digest de la première reste dans $D1, son contenu dans le registre.

docker image rm localhost:5000/demo:1.0
docker build -f Dockerfile.v2 -t localhost:5000/demo:1.0 .
docker push localhost:5000/demo:1.0
D2=$(docker image inspect localhost:5000/demo:1.0 --format '{{index .RepoDigests 0}}' | cut -d@ -f2)

The push refers to repository [localhost:5000/demo]
a30ce9ef8501: Pushed
44136fa355b3: Already exists
27427d4eab2d: Pushed
68fe9bff2ad4: Layer already exists
1.0: digest: sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81 size: 855

Le push accepte le tag sans avertissement, et le digest a changé : b7871059… au lieu de 6d89c236…. Interrogez le registre sur ce qu'il liste, puis sur ce qu'il sert pour le tag :

curl -s http://localhost:5000/v2/demo/tags/list
curl -sI -H 'Accept: application/vnd.oci.image.manifest.v1+json, application/vnd.oci.image.index.v1+json' http://localhost:5000/v2/demo/manifests/1.0 | grep -i docker-content-digest

{"name":"demo","tags":["1.0"]}
Docker-Content-Digest: sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81

Le registre ne connaît toujours qu'un tag, 1.0, mais le digest qu'il sert pour ce tag a changé : l'en-tête Docker-Content-Digest vaut maintenant le digest du second push. Pour lire l'index que le tag désigne, avec ses entrées, utilisez Buildx :

docker buildx imagetools inspect localhost:5000/demo:1.0

Name:      localhost:5000/demo:1.0
MediaType: application/vnd.oci.image.index.v1+json
Digest:    sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81

Manifests:
  Name:        localhost:5000/demo:1.0@sha256:0de200393ec2039fe02aa81808804128eb99a6bdaed0c291e6e722e344e68b20
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    linux/amd64

  Name:        localhost:5000/demo:1.0@sha256:eaef13c89f99ea0b144fa73d965ae134c5d6eb2a337d6c98cf7b14dfb3eee481
  MediaType:   application/vnd.oci.image.manifest.v1+json
  Platform:    unknown/unknown
  Annotations:
    vnd.docker.reference.type:   attestation-manifest
    vnd.docker.reference.digest: sha256:0de200393ec2039fe02aa81808804128eb99a6bdaed0c291e6e722e344e68b20

Lisez la sortie comme le schéma : un index, deux manifestes. Le premier est l'image pour linux/amd64. Le second, de plateforme unknown/unknown et d'annotation attestation-manifest, est l'attestation, qui renvoie par vnd.docker.reference.digest vers le manifeste qu'elle décrit.

Que devient le premier contenu ? Il est toujours dans le registre, adressable par son digest. Tirez et lancez chacun des deux digests :

docker image rm localhost:5000/demo:1.0
docker pull localhost:5000/demo@$D1
docker run --rm localhost:5000/demo@$D1
docker pull localhost:5000/demo@$D2
docker run --rm localhost:5000/demo@$D2

localhost:5000/demo@sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a: Pulling from demo
47a073a1b52e: Pulling fs layer
68fe9bff2ad4: Pulling fs layer
68fe9bff2ad4: Already exists
47a073a1b52e: Already exists
8cb537d930a3: Download complete
44136fa355b3: Download complete
68fe9bff2ad4: Pull complete
47a073a1b52e: Pull complete
Digest: sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a
Status: Downloaded newer image for localhost:5000/demo@sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a
localhost:5000/demo@sha256:6d89c2360a281fe7d4c97e7d101d601938f831f9b0f233a19108463e1209213a
v1
localhost:5000/demo@sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81: Pulling from demo
a30ce9ef8501: Pulling fs layer
68fe9bff2ad4: Pulling fs layer
a30ce9ef8501: Already exists
68fe9bff2ad4: Already exists
27427d4eab2d: Download complete
44136fa355b3: Already exists
a30ce9ef8501: Pull complete
Digest: sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81
Status: Downloaded newer image for localhost:5000/demo@sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81
localhost:5000/demo@sha256:b7871059c1ff315d11455e61fcae280567cfe3899a70014d1e310d5ee10f8b81
v2

Le premier digest relance v1, le second v2. Le tag 1.0 a donc désigné deux images successives, et seul le digest permet de choisir laquelle vous exécutez.

Deux autres points à retenir. Une référence par tag (docker pull localhost:5000/demo:1.0) aurait tiré la version v2. Et dans le magasin local, reconstruire sous un tag existant déplace aussi le tag vers la nouvelle image, comme le rappelle écrire un Dockerfile : retenez le digest avant de reconstruire.

Sur quelle image de base une image repose-t-elle ?

L'image de base d'une image construite est une image à part entière, avec son propre digest, différent de celui de l'image construite. Cette section construit une image qui repose sur busybox, puis relève la base que la construction a réellement utilisée. Un point surprend : BuildKit, le moteur de construction de Docker, utilise la base sans la ranger dans la liste d'images locale. La preuve de la base se trouve donc dans la provenance, et la lire en local demande de la tirer d'abord. Le registre registre-identite de la section précédente doit encore tourner.

Écrivez un Dockerfile dont la ligne FROM désigne la base par son tag et son digest, puis construisez et publiez l'image sous le tag 1.0 :

cd ~/identite-image
printf 'FROM busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec\nRUN echo horloge > /etc/horloge\n' > Dockerfile
docker buildx build --push -t localhost:5000/atelier/horloge:1.0 .

La construction affiche son journal d'étapes, qui n'est pas reproduit ici. L'option --push envoie l'image au registre et la laisse aussi dans la liste d'images locale. Lisez son identité :

docker image inspect localhost:5000/atelier/horloge:1.0 --format '{{.Id}} {{json .RepoDigests}}'

sha256:4d59158ac547237d5049bb0c12e987dc2756cf158d27411f8f8a62562f796725 ["localhost:5000/atelier/horloge@sha256:4d59158ac547237d5049bb0c12e987dc2756cf158d27411f8f8a62562f796725"]

La règle est la même que pour une image tirée : l'Id local est le digest de l'index, et RepoDigests porte ce même digest précédé du nom. C'est la forme à noter pour retrouver une image dans un registre. Le digest de votre image différera de celui-ci, car il change à chaque construction ; seul celui de busybox est fixe, puisque le FROM le désigne.

Une liste RepoDigests remplie ne prouve pas une publication. Une image construite avec docker build et jamais poussée en a une aussi, dérivée de son nom :

docker build -t localhost:5000/atelier/horloge:local .
docker image inspect localhost:5000/atelier/horloge:local --format '{{.Id}} {{json .RepoDigests}}'

sha256:3ef1438741afe2623f2ddd4a52d4f7b1089563fa4dfdc49571b4d469e9d6b773 ["localhost:5000/atelier/horloge@sha256:3ef1438741afe2623f2ddd4a52d4f7b1089563fa4dfdc49571b4d469e9d6b773"]

Pour savoir si une image est publiée, interrogez donc le registre, pas cette liste.

L'image de base n'est pas dans la liste d'images

Cherchez maintenant la base, avec la référence exacte du FROM :

docker image inspect busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec

[]
Error response from daemon: No such image: busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec

L'erreur n'est pas un défaut de la construction : BuildKit a lu la base dans le registre sans la ranger dans la liste d'images. Elle apparaît après docker buildx build --push comme après docker build. C'est pourquoi docker image inspect sur la base ne prouve rien tant qu'on ne l'a pas tirée, et pourquoi la vraie preuve est ailleurs.

La provenance prouve la base réellement utilisée

L'attestation de provenance, produite à la construction, déclare les images que BuildKit a résolues. Avec docker buildx build --push lancé sans option de provenance, elle est présente par défaut. Lisez ses dépendances résolues :

docker buildx imagetools inspect localhost:5000/atelier/horloge:1.0 --format '{{json .Provenance.SLSA.buildDefinition.resolvedDependencies}}'

[
  {
    "digest": {
      "sha256": "a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec"
    },
    "uri": "pkg:docker/busybox@1.37.0?digest=sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec\u0026platform=linux%2Famd64"
  }
]

Le champ digest donne le digest de la base tel que le FROM l'a désignée : l'algorithme (sha256) sert de clé, et la valeur n'a donc pas de préfixe sha256:. Le champ uri en rappelle le nom, la version et la plateforme (\u0026 est le caractère & dans le JSON). C'est la preuve de la base réellement utilisée par la construction. Elle disparaît si vous construisez avec --provenance=false : imagetools inspect répond alors {}. L'inventaire des paquets (SBOM), lui, est absent par défaut :

docker buildx imagetools inspect localhost:5000/atelier/horloge:1.0 --format '{{json .SBOM}}'

{}

La base se lit en local après un pull

Pour lire la base comme n'importe quelle image, tirez-la d'abord, puis lisez son identité :

docker pull busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec
docker image inspect busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec --format '{{.Id}} {{json .RepoDigests}}'

docker.io/library/busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec: Pulling from library/busybox
Digest: sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec
Status: Downloaded newer image for busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec
docker.io/library/busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec
sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec ["busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec"]

Regardez les deux dernières lignes : l'Id et RepoDigests valent le digest du FROM, alors que l'image construite a le sien (4d59158a…). Les deux images sont distinctes dans le magasin local. Cette lecture confirme la provenance, elle ne la remplace pas : elle suppose que vous tiriez la base par son digest, ce que fait justement le FROM.

Les couches prouvent la parenté

Deux images peuvent avoir deux digests et pourtant partager leur contenu. Comparez leurs couches :

docker image inspect --format '{{json .RootFS.Layers}}' busybox:1.37.0@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec
docker image inspect --format '{{json .RootFS.Layers}}' localhost:5000/atelier/horloge:1.0

["sha256:5a9bfd996c6d49c6c3cb4ddfb76e8d09cf16b6b7cf6601d1f2dffbdbc3edb5d4"]
["sha256:5a9bfd996c6d49c6c3cb4ddfb76e8d09cf16b6b7cf6601d1f2dffbdbc3edb5d4","sha256:65fa40cc5c9114e805a75a9e51c5060cb13c7ad6f286972799c02ce30e47dfbf"]

La liste de l'image construite commence par la couche de la base, 5a9bfd99…, puis ajoute une couche, 65fa40cc…, celle de l'instruction RUN. Cette parenté par les couches est une preuve de contenu. Elle ne donne pas le digest de la base : deux images différentes pourraient commencer par la même couche.

Une dernière commande est tentante : docker history liste l'étape qui a produit la base parmi les étapes de l'historique, mais sans le digest de l'image de base. Elle affiche <missing> pour une étape qui n'a pas d'identifiant d'image local, ce qui n'est pas une erreur. Pour le digest de la base, lisez la provenance.

Que faire quand l'identité d'une image prête à confusion ?

Les symptômes de cette leçon ont chacun une cause précise. Le tableau les rapproche de leur diagnostic.

Symptôme	Cause	Que faire
exec format error au lancement, code de sortie 255	L'architecture du binaire de l'image n'est pas celle de la machine, et aucune émulation n'est installée (voir choisir une image de base)	Lire Architecture avec docker image inspect --platform <plateforme>, puis tirer ou construire l'image de la bonne plateforme
docker image inspect rend Architecture et Os vides, sans erreur	Seule une plateforme étrangère à la machine est stockée, et l'inspection interroge celle de la machine	Ajouter --platform linux/arm64 (ou la plateforme stockée) à l'inspection
docker history affiche <missing> au lieu du digest de la base	L'étape n'a pas d'identifiant d'image local, et docker history ne donne pas le digest de la base	Lire la provenance avec imagetools inspect --format '{{json .Provenance.SLSA.buildDefinition.resolvedDependencies}}'
No such image: busybox:1.37.0@sha256:… sur la base, juste après une construction	BuildKit utilise la base sans la ranger dans la liste d'images locale	Tirer la base avec docker pull, ou lire la provenance
template parsing error … map has no entry for key "Variant" (ou "Created")	Le gabarit lit un champ absent : l'image amd64 ne déclare pas de variant, et la fiche d'une plateforme non stockée n'a pas de Created	Retirer le champ du gabarit, ou ne lire {{.Variant}} que pour les plateformes qui en ont (arm/v7, arm64/v8)

Glissez pour voir

Le symptôme du gabarit se reproduit avec un gabarit proche de celui de la section sur les plateformes, lancé sans --platform sur la base tirée plus haut, dans la section sur l'image de base : l'inspection lit alors la plateforme amd64 de la machine, qui ne déclare pas de variant. L'erreur désigne le champ fautif, ce qui permet de trouver la cause sans deviner :

docker image inspect busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec --format '{{.Id}} | {{json .RepoTags}} | {{json .RepoDigests}} | {{.Architecture}} {{.Os}} variant=[{{.Variant}}] | layers={{len .RootFS.Layers}}'

template parsing error: template: :1:92: executing "" at <.Variant>: map has no entry for key "Variant"

Comment nettoyer après les essais ?

Les images de cette leçon ne servent plus. Supprimez le registre avec ses données, les images construites et les images de base. Les variables $IDX, $D1 et $D2 n'existent que dans le terminal où vous les avez créées : dans un autre terminal, elles sont vides et la commande échoue, remplacez-les alors par les digests lus dans docker image ls --digests.

docker rm -f -v registre-identite
docker image rm localhost:5000/demo@$D1 localhost:5000/demo@$D2 localhost:5000/atelier/horloge:1.0 localhost:5000/atelier/horloge:local registry:3@sha256:d4032d4cc323c1731c707931ecada07a53076eac38e3b61ae57533f170f2c6c3 busybox@$IDX busybox@sha256:98ad9d1a2be345201bb0709b0d38655eb1b370145c7d94ca1fe9c421f76e245a
cd ~ && rm -rf ~/identite-image
docker builder prune -af

Les deux derniers digests de la commande docker image rm sont ceux des index de busybox, supprimés avec les contenus de plateforme qu'ils ont téléchargés. Si votre $IDX diffère de a7dbc319…, la base épinglée par les FROM reste sur la machine : supprimez-la aussi avec docker image rm busybox@sha256:a7dbc319b1438115a207e11930dc4bb3e643dcb3ec0bdd694bb36cd8fad289ec. La commande docker builder prune -af vide tout le cache de construction de la machine, pas seulement celui de cette leçon : évitez-la sur une machine partagée. Si une commande répond qu'une image est utilisée par un conteneur, supprimez d'abord ce conteneur avec docker rm -f.

Mettre en pratique

Le lab vous place devant une image locale dont vous ne savez pas si le tag désigne encore ce qu'il désignait. Vous devez établir trois faits et les écrire dans un fichier de réponse que l'énoncé du lab désigne : le digest de l'image que ce tag désigne aujourd'hui, le digest de l'image de base stockée sur la machine, et sa plateforme sous la forme os/architecture. Recopier un digest trouvé dans un fichier d'aide est refusé. Aucune commande n'est notée : seul le résultat compte, et la validation se lance avec dsoxlab check.

Lab guidé Pratique

Apprendre à faire

Identité d'une image : le tag ment, le digest non

$ dsoxlab run images-identifier-image

Environnement : VM·Durée : ~30 min

Vérification : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start images-identifier-image vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/containers-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run images-identifier-image
dsoxlab check images-identifier-image

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

Une image est une chaîne de documents : un tag, qui est un nom déplaçable, mène à un index, qui liste un manifeste par plateforme, chacun désignant une configuration et des couches. Seul un digest, calculé sur le contenu, est fiable.

Avec le magasin containerd de Docker 29.9.2, l'Id local d'une image est le digest de son index, qu'elle soit tirée ou construite. RepoDigests porte le même digest précédé du nom : c'est la forme à noter pour une image venue d'un registre, mais sa présence ne prouve pas une publication. Tirer le digest d'un manifeste donne une autre identité locale, celle de ce manifeste.

Un conteneur lancé par tag et un conteneur lancé par digest peuvent exécuter la même image. docker inspect dit laquelle par .Image, et quel manifeste par .ImageManifestDescriptor. .Config.Image ne rappelle que la référence saisie, et docker ps affiche l'identifiant raccourci pour un conteneur lancé par digest.

La plateforme se lit sur l'image avec docker image inspect --platform. Sans cette option, une image dont seule une plateforme étrangère est stockée donne des champs vides, sans erreur. Le pull réussit avec --platform même pour une plateforme que la machine ne sait pas exécuter, et l'erreur exec format error n'arrive qu'au lancement. docker run --platform télécharge le contenu manquant. Le diagnostic complet de l'erreur est dans choisir une image de base.

Un tag peut désigner deux images successives sans qu'aucun message ne l'annonce, et l'ancienne image reste adressable par son digest tant que le registre la conserve. Pour un déploiement sur des machines variées, épinglez le digest de l'index ; pour figer une architecture, celui d'un manifeste.

L'image de base d'une image construite a son propre digest, mais BuildKit ne la range pas dans la liste d'images : la base réellement utilisée se lit dans resolvedDependencies de la provenance, présente par défaut avec docker buildx build --push. La lire en local avec docker image inspect demande de la tirer d'abord. Les couches de l'image construite commencent par celles de la base, et docker history ne donne pas son digest.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →