Comprendre les images Docker : structure et fonctionnement

Une image Docker, c'est un modèle figé qui contient tout le nécessaire pour exécuter une application : code, dépendances, configuration et système de fichiers. Chaque image est construite couche par couche, et comprendre cette architecture est la clé pour créer des images optimisées, légères et rapides à builder.

Ce que vous allez apprendre

• Comprendre le système de couches et comment chaque instruction Dockerfile crée une nouvelle layer
• Explorer la structure interne d'une image (manifest.json, blobs, config)
• Maîtriser le cache de build pour accélérer vos pipelines CI/CD
• Analyser une image existante pour comprendre sa composition

Prérequis : avoir lu l'introduction à la conteneurisation et connaître les bases de Docker.

Comment est construite une image de conteneur ?

Pour bien comprendre ce qu’on fait quand on écrit un Dockerfile, il faut savoir ce que Docker fabrique réellement à chaque instruction. Construire une image Docker, ce n’est pas juste enchaîner des commandes. C’est empiler des couches, chacune résultant d’une instruction, à partir d’une image de base.

Tout commence par une image de base

L’image de base, c’est le point de départ. Elle peut être :

• Une distribution minimaliste comme alpine
• Une image préconfigurée comme python:3.11-slim ou nginx
• Ou même scratch, qui signifie... aucune base du tout

Quelle image de base choisir ?

Privilégiez les images slim ou alpine pour réduire la taille finale. Pour la sécurité maximale, explorez les images distroless (Google) ou Chainguard/Wolfi qui ne contiennent ni shell ni gestionnaire de paquets, uniquement votre application et ses dépendances runtime.

Type d'image	Exemple	Taille typique	Shell inclus	Cas d'usage
Standard	python:3.12	900+ Mo	✅ Oui	Dev, debug
Slim	python:3.12-slim	~150 Mo	✅ Oui	Production générale
Alpine	python:3.12-alpine	~50 Mo	✅ Oui (busybox)	Contraintes de taille
Distroless	gcr.io/distroless/python3	~20 Mo	❌ Non	Sécurité maximale
Chainguard	cgr.dev/chainguard/python	~30 Mo	❌ Non	Sécurité + zero CVE

Glissez pour voir

On construit une nouvelle image à partir de cette base

Pour construire une image, on va ajouter des couches à cette image de base. Chaque couche est le résultat d’une instruction dans le Dockerfile. Ces instructions sont exécutées dans l’ordre, et celles qui modifient le système de fichiers (FROM, RUN, COPY, ADD) créent une nouvelle couche.

« Une instruction, une couche » est un raccourci : comptez avant de conclure

La formule est commode pour comprendre le principe, mais elle ne se vérifie pas à l'écran, et l'écart peut être considérable. Sur une image construite pour l'occasion :

podman history -q mon-image | wc -l
podman inspect -f '{{len .RootFS.Layers}}' mon-image

Le premier compte les instructions, le second les couches réelles. Sur un Containerfile de sept lignes, le rapport mesuré est de 8 contre 3, et il grimpe à 23 contre 3 sur une image publiée courante.

Deux raisons à cet écart. D'abord, les instructions de métadonnées (LABEL, ENV, CMD, EXPOSE, WORKDIR) ne touchent pas au système de fichiers : elles apparaissent dans l'historique en pesant 0B, sans créer de couche. Ensuite, une image publiée est souvent aplatie, et podman history rattache alors le poids de la base à la dernière instruction connue, parfois une simple ligne LABEL qui semble peser 106 Mo.

À retenir pour optimiser : ce n'est pas le nombre d'instructions qu'il faut réduire, c'est le nombre et le poids des couches, donc des RUN, COPY et ADD.

Qu'est-ce qu'un Dockerfile ?

Un Dockerfile est un fichier texte qui définit une suite d'instructions qui vont permettre d'installer tous les éléments nécessaires à l'exécution de notre application.

Nous avons à notre disposition une dizaine d'instructions. Si peu ? Oui et c'est suffisant. À cela s'ajoute aussi la possibilité de mettre des commentaires.

Prenons un exemple simple :

FROM debian:bullseye-slim@sha256:cba95a21c96c1f5fc2470081829363eed57706634f7dc26e8c6712934303d57a

Cette instruction dit à Docker : « télécharge cette image de base depuis un registre » (par défaut Docker Hub). C’est la première couche, sur laquelle on va construire tout le reste.

Chaque instruction crée une nouvelle couche

À chaque ligne du Dockerfile, Docker va :

1. Créer un conteneur temporaire
2. Exécuter l’instruction (par exemple une commande RUN)
3. Capturer la différence de fichiers
4. La stocker comme une nouvelle couche (en tar.gz dans les blobs)

Toutes les instructions ne créent pas de couches

Seules les instructions FROM, RUN, COPY et ADD créent des couches qui augmentent la taille de l'image. Les autres instructions (ENV, LABEL, EXPOSE, CMD, ENTRYPOINT) modifient uniquement les métadonnées sans ajouter de données au système de fichiers.

Prenons ce Dockerfile :

FROM python:3.11-slim@sha256:db3ff2e1800a8581e2c48a27c3995339d47bdf046da21c7627accd3d51053a93
COPY . /app
RUN pip install --no-cache-dir -r /app/requirements.txt

Voici ce que fait Docker :

• 1re couche : image de base python:3.11-slim
• 2e couche : copie de vos fichiers dans /app
• 3e couche : installation des dépendances Python

Chaque couche est immutabilité et cacheable. Si on relance le build sans changer les fichiers copiés, Docker réutilisera les couches précédentes.

Le cache, votre allié pour des builds rapides

L'ordre des instructions dans le Dockerfile impacte directement le cache. Placez les instructions qui changent rarement (installation de dépendances système) en haut, et celles qui changent souvent (copie du code source) en bas. Ainsi, le cache est réutilisé au maximum.

Content-Addressable Storage : la déduplication intelligente

Docker utilise un stockage adressable par contenu (Content-Addressable Storage). Chaque couche est identifiée par le hash SHA256 de son contenu, pas par son nom ou sa position. Concrètement :

• Si deux images partagent la même couche de base (ex: alpine:3.19), Docker ne la stocke qu'une seule fois sur le disque
• Lors d'un docker pull, seules les couches manquantes sont téléchargées
• La déduplication fonctionne aussi bien localement que sur les registries

Cette approche permet d'économiser énormément d'espace disque et de bande passante, surtout quand vous gérez plusieurs images basées sur les mêmes fondations.

Union Filesystem et Copy-on-Write

Pour assembler les couches en un système de fichiers cohérent, Docker utilise un Union Filesystem (généralement OverlayFS via le driver overlay2). Ce système :

• Superpose les couches read-only les unes sur les autres
• Présente une vue unifiée au conteneur (comme un seul système de fichiers)
• Utilise le mécanisme Copy-on-Write (CoW) pour les modifications

Quand un conteneur modifie un fichier existant dans une couche read-only :

1. Le fichier est copié dans la couche d'écriture du conteneur
2. La modification s'applique sur cette copie
3. La couche originale reste intacte

C'est pourquoi les modifications dans un conteneur ne persistent pas après sa suppression, sauf si vous utilisez des volumes.

Comment une image est-elle structurée ?

Pour aller plus loin, on peut extraire une image Docker pour voir comment elle est structurée. Par exemple, prenons l’image nginx:alpine :

docker save nginx:alpine -o nginx-alpine.tar
mkdir nginx-image && tar -xf nginx-alpine.tar -C nginx-image

Une fois extraite, on y trouve :

• Répertoireblobs/

  • Répertoiresha256/

    • 08000c18d16dadf9553d747a58cf44023423a9ab010aab96cf263d2216b8b350
    • 0bf5be05f1809d9c54b50ef92deba77c37c22d875842d556edd4ad202b61d033
    • 1ff4bb4faebcfb1f7e01144fa9904a570ab9bab88694457855feb6c6bba3fa07
    • 252b6db79fae151ab547c0f86a873dc97274d8b61f3921158d480b4242fef957
    • 252e179fd8212a3dc5b070bb4d702df97f20b4b52aa65a59cf61c4d85e138b55
    • 4b6e8e243d7d2a5c7af927e2137d9426d039591b0b24a368c6f9d5a3e80132e1
    • 540b632878f7db4231da7c610f2b3271efba724392e56da1569c1d94900870b4
    • 60531a653758d21ddd46bf4c65e7beec5f0e35332409fccf4500e5a02dae1c53
    • 80a2d6b308417d56c551f88704e46ab844d0db3db9ad7f2b5e283da916312e65
    • 84e2259b5616d28e968f0f5162447105736880570791aadcd4be9dabd23a2bbc
    • 8f3c313eb1240a3b86e0c76d0abda7a6fa7df30ad3151e98c4e3725a3fb710dc
    • 9af9e76ea07fe05a1f7660b80ec2417bc3fe500991df4995b0adfa13aade20b6
    • bbf43b514ee66a048d0b4cd55e455bf91481f1c04252e4c1564cf9fc7b3f0213
    • c1761f3c364a963ec0ebd4d728cb6dd5aa24273f7dba0c3dd2fdb8411682ef0a
    • c18897d5e3dd125d3d9f2ca7f361cb6b05cf7fad8ef9bc00548f3eb6f3def644
    • c9ce8cb4e76a801ef89c226cb8657556e62e3bb962b3641b051bb25f13dd1a26
    • f1f70b13aacc43849d4f4ab87a889304a4300210ecd32be5a55305486af5f1ea
    • fabf3656cbba722e0a4e35f33a5d2b67eb772a6608e467014787d0a637d7ea55
• index.json
• manifest.json
• oci-layout
• repositories

• manifest.json : décrit les couches et la configuration.
• repositories : indique le nom de l’image et son tag.
• Un ou plusieurs dossiers avec des noms hashés : ce sont les couches, chacune contenant :
  • layer.tar : la vraie couche de fichiers
  • des métadonnées (VERSION, json, etc.)

Dans le format OCI Image Layout, chaque élément de l’image est identifié par un digest SHA256. Les fichiers qui sont dans blobs/sha256/, sont des blobs binaires compressés représentant soit :

• des couches de fichiers (layer.tar.gz)
• des manifests JSON
• des configurations de conteneur

Chaque fichier est nommé par le digest SHA256 de son contenu, ce qui garantit l’intégrité et la déduplication.

On peut alors voir les fichiers ajoutés/modifiés à cette étape. En répétant ça pour chaque couche, on comprend exactement ce que chaque commande du Dockerfile a produit.

C’est aussi ce que fait automatiquement l’outil dive : il lit les couches d’une image et affiche ce qui a été ajouté ou modifié, couche par couche.

Description du fichier manifest.json

Ce fichier manifest.json est un élément clé d'une image Docker exportée au format OCI. Il décrit la composition complète de l'image, notamment :

• le fichier de configuration (Config)
• les couches de fichiers (Layers)
• les informations sur chaque blob (LayerSources)
• les tags associés à l'image (RepoTags)

Notre exemple de manifest.json :

[
  {
    "Config": "blobs/sha256/1ff4bb4faebcfb1f7e01144fa9904a570ab9bab88694457855feb6c6bba3fa07",
    "RepoTags": [
      "nginx:alpine"
    ],
    "Layers": [
      "blobs/sha256/08000c18d16dadf9553d747a58cf44023423a9ab010aab96cf263d2216b8b350",
      "blobs/sha256/c1761f3c364a963ec0ebd4d728cb6dd5aa24273f7dba0c3dd2fdb8411682ef0a",
      "blobs/sha256/8f3c313eb1240a3b86e0c76d0abda7a6fa7df30ad3151e98c4e3725a3fb710dc",
      "blobs/sha256/c9ce8cb4e76a801ef89c226cb8657556e62e3bb962b3641b051bb25f13dd1a26",
      "blobs/sha256/252b6db79fae151ab547c0f86a873dc97274d8b61f3921158d480b4242fef957",
      "blobs/sha256/f1f70b13aacc43849d4f4ab87a889304a4300210ecd32be5a55305486af5f1ea",
      "blobs/sha256/9af9e76ea07fe05a1f7660b80ec2417bc3fe500991df4995b0adfa13aade20b6",
      "blobs/sha256/c18897d5e3dd125d3d9f2ca7f361cb6b05cf7fad8ef9bc00548f3eb6f3def644"
    ],
    "LayerSources": {
      "sha256:08000c18d16dadf9553d747a58cf44023423a9ab010aab96cf263d2216b8b350": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 8120832,
        "digest": "sha256:08000c18d16dadf9553d747a58cf44023423a9ab010aab96cf263d2216b8b350"
      },
      "sha256:252b6db79fae151ab547c0f86a873dc97274d8b61f3921158d480b4242fef957": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 2560,
        "digest": "sha256:252b6db79fae151ab547c0f86a873dc97274d8b61f3921158d480b4242fef957"
      },
      "sha256:8f3c313eb1240a3b86e0c76d0abda7a6fa7df30ad3151e98c4e3725a3fb710dc": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 3584,
        "digest": "sha256:8f3c313eb1240a3b86e0c76d0abda7a6fa7df30ad3151e98c4e3725a3fb710dc"
      },
      "sha256:9af9e76ea07fe05a1f7660b80ec2417bc3fe500991df4995b0adfa13aade20b6": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 7168,
        "digest": "sha256:9af9e76ea07fe05a1f7660b80ec2417bc3fe500991df4995b0adfa13aade20b6"
      },
      "sha256:c1761f3c364a963ec0ebd4d728cb6dd5aa24273f7dba0c3dd2fdb8411682ef0a": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 4504064,
        "digest": "sha256:c1761f3c364a963ec0ebd4d728cb6dd5aa24273f7dba0c3dd2fdb8411682ef0a"
      },
      "sha256:c18897d5e3dd125d3d9f2ca7f361cb6b05cf7fad8ef9bc00548f3eb6f3def644": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 36649472,
        "digest": "sha256:c18897d5e3dd125d3d9f2ca7f361cb6b05cf7fad8ef9bc00548f3eb6f3def644"
      },
      "sha256:c9ce8cb4e76a801ef89c226cb8657556e62e3bb962b3641b051bb25f13dd1a26": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 4608,
        "digest": "sha256:c9ce8cb4e76a801ef89c226cb8657556e62e3bb962b3641b051bb25f13dd1a26"
      },
      "sha256:f1f70b13aacc43849d4f4ab87a889304a4300210ecd32be5a55305486af5f1ea": {
        "mediaType": "application/vnd.oci.image.layer.v1.tar",
        "size": 5120,
        "digest": "sha256:f1f70b13aacc43849d4f4ab87a889304a4300210ecd32be5a55305486af5f1ea"
      }
    }
  }
]

Voici une explication détaillée de chacune des parties de ce fichier manifest.json :

"Config" : métadonnées de l’image

"Config": "blobs/sha256/1ff4bb4faebcfb1f7e01144fa9904a570ab9bab88694457855feb6c6bba3fa07"

Ce fichier (un blob JSON) contient toutes les instructions du Dockerfile compilées : la commande par défaut (CMD), les variables d’environnement, les volumes, les labels, etc. C’est ce blob que le moteur de conteneurs lit au docker run pour savoir quel processus démarrer et dans quel environnement, une fois les couches empilées. La valeur est un chemin relatif à l’intérieur de l’archive : vous pouvez extraire ce fichier et l’ouvrir pour lire la configuration réelle de l’image.

"RepoTags" : nom et version de l’image

"RepoTags": ["nginx:alpine"]

Cela indique que l’image correspond au tag nginx:alpine. C’est le nom que vous verriez avec docker images.

"Layers" : couches empilées de l’image

"Layers": [
  "blobs/sha256/08000c18d16da...",
  "blobs/sha256/c1761f3c364a...",
  ...
]

Chaque fichier listé ici correspond à une couche de fichiers (layer.tar) ajoutée lors du docker build. Elles sont appliquées dans l’ordre, de la base vers le haut. Le contenu de ces archives représente les ajouts ou suppressions de fichiers à chaque étape du build.

"LayerSources" : métadonnées des couches

Cette section associe à chaque digest :

• le type MIME du fichier (mediaType)
• la taille en octets
• le digest SHA256, qui sert d’identifiant unique

Exemple :

"sha256:c18897d5e3dd125...": {
  "mediaType": "application/vnd.oci.image.layer.v1.tar",
  "size": 36649472,
  "digest": "sha256:c18897d5e3dd125..."
}

Cela indique que la couche contient une archive .tar, non compressée ici, de 36 Mo environ.

En résumé

Cette image est donc composée de :

• 8 couches, empilées dans un ordre précis
• Un fichier de configuration global
• Un tag nginx:alpine associé
• Des métadonnées bien définies pour chaque élément

Et techniquement, Docker ou un autre moteur (comme containerd) reconstruit le système de fichiers final en appliquant ces couches les unes après les autres, sur la base des instructions du Config.

Mettre en pratique

Manipulez des images de conteneurs sur une VM : les récupérer (pull), les taguer, les sauvegarder (save) et les inspecter, les gestes de base de la gestion d'images.

Lab pratique

Gérer les images de conteneurs : pull, tag, save et inspection

$ dsoxlab run l4-podman-images

Environnement : VM·Durée : ~25 min

Validé : 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.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l4-podman-images
dsoxlab check l4-podman-images

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

À retenir

Les 7 points clés

1. Images = couches empilées : chaque instruction FROM, RUN, COPY, ADD crée une nouvelle layer stockée comme un blob tar
2. Content-Addressable Storage : les couches sont identifiées par leur hash SHA256, permettant la déduplication automatique
3. Union Filesystem (OverlayFS) : superpose les couches read-only et utilise le Copy-on-Write pour les modifications
4. Immutabilité : une fois créée, une couche ne change jamais, c'est ce qui permet le cache et la déduplication
5. manifest.json : décrit la composition complète de l'image (config, layers, tags)
6. Ordre des instructions : crucial pour exploiter le cache : dépendances stables en haut, code en bas
7. Images minimales : préférez distroless ou Chainguard pour la sécurité (pas de shell, pas de CVE)

Testez vos connaissances

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

15 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

FAQ : questions fréquentes sur les images Docker

Ces réponses courtes reprennent les questions les plus posées sur la structure des images : ce qu'est réellement une couche, la différence entre une image et un conteneur, et comment réduire la taille finale. Elles complètent le guide sans le répéter.

Qu'est-ce qu'une image Docker ?

Une image Docker est un modèle figé en lecture seule qui contient une application, ses dépendances, sa configuration et un système de fichiers. Elle est construite couche par couche à partir d'une image de base et sert de patron pour lancer des conteneurs.

Quelle est la différence entre une image et un conteneur ?

Une image est un modèle figé en lecture seule ; un conteneur est une instance en cours d'exécution de cette image. Docker ajoute au démarrage une couche d'écriture par-dessus les couches read-only. On lance plusieurs conteneurs depuis une même image.

Qu'est-ce qu'une couche (layer) dans une image Docker ?

Une couche est le résultat figé d'une instruction du Dockerfile qui modifie le système de fichiers : FROM, RUN, COPY et ADD. Chaque couche a un hash SHA256, est mise en cache et déduplicable. Les métadonnées comme ENV ou CMD ne créent pas de couche.

Comment réduire la taille d'une image Docker ?

Partez d'une image de base légère (slim, alpine, distroless), regroupez les commandes RUN pour limiter les couches, supprimez les caches d'installation dans la même instruction, et utilisez un build multi-stage pour ne garder que le binaire final.

À quoi sert le fichier manifest.json d'une image ?

Le manifest.json décrit la composition d'une image au format OCI : le blob de configuration, la liste ordonnée des couches et leurs métadonnées (type MIME, taille, digest SHA256). Le moteur l'utilise pour reconstruire le système de fichiers final.

Comment inspecter les couches d'une image Docker ?

Exportez l'image avec docker save image -o image.tar puis extrayez l'archive pour lire manifest.json et les blobs. L'outil dive affiche le contenu ajouté ou modifié couche par couche. docker history montre la taille de chaque couche.

Qu'est-ce que le Copy-on-Write dans Docker ?

Le Copy-on-Write est le mécanisme d'OverlayFS qui superpose les couches en lecture seule. Quand un conteneur modifie un fichier, il est copié dans sa couche d'écriture ; la couche d'origine reste intacte. C'est pourquoi les changements sont perdus sans volume.

Pourquoi choisir une image Alpine ou distroless ?

Alpine réduit fortement la taille grâce à musl et busybox. Les images distroless (Google) ou Chainguard ne contiennent ni shell ni gestionnaire de paquets, seulement l'application et ses dépendances runtime, ce qui réduit la surface d'attaque et le nombre de CVE.

Prochaines étapes

Écrire un Dockerfile Maîtrisez la syntaxe complète et les bonnes pratiques pour créer des images optimisées

Bonnes pratiques Dockerfile Cache, .dockerignore, multi-stage, non-root, healthcheck

Standard OCI Tags vs digests, manifests, multi-arch et artefacts ORAS

CI/CD d'images Stratégie de tags, cache BuildKit, multi-arch, promotion dev→prod

Outils de build d'images Découvrez Buildah, Kaniko et BuildKit pour construire vos images

Analyser une image avec Dive Explorez les couches d'une image et identifiez les fichiers superflus

×

📖 Voir la documentation →