Images, conteneurs et volumes : le modèle mental en 30 minutes

Prérequis : Installer Docker et vérifier son poste (chapitre 01) : tag dk01 posé.

Le modèle mental en quatre phrases

1. Une image est un modèle en lecture seule, fait de couches empilées. Elle se construit avec un Dockerfile et se partage via un registre.
2. Un conteneur est une image en cours d’exécution, plus une fine couche d’écriture. Il est jetable : le supprimer efface tout ce qui a été écrit dedans.
3. Un volume est un espace de stockage géré par Docker, monté dans un conteneur. Il survit à la suppression du conteneur.
4. Un réseau relie des conteneurs entre eux : sur un réseau commun, ils se joignent par leur nom.

C’est la réponse au défi du chapitre 01 : votre fichier était dans la couche d’écriture du conteneur, supprimée avec lui.

Étape 1 : explorer une image

docker pull node:22-alpine
docker image ls node
docker image history node:22-alpine   # les couches et leur taille
docker image inspect node:22-alpine --format '{{.Architecture}} {{.Config.User}}'

Notez la taille : environ 150 Mo pour Node sur Alpine, contre plus de 1 Go pour node:22. Cette différence pèsera sur chaque build et chaque déploiement de MonTour.

Les couches : ce qu’est vraiment une image

Une image n’est pas un gros fichier. C’est une pile de couches en lecture seule, chacune contenant uniquement les fichiers ajoutés, modifiés ou supprimés par une instruction du Dockerfile. Quand un conteneur démarre, Docker pose par-dessus une couche d’écriture vide, et Linux (pilote overlay2) présente l’ensemble comme un seul disque.

• Partage : dix images basées sur node:22-alpine ne stockent cette base qu’une fois. docker system df -v montre l’espace partagé.
• Copie à l’écriture : si un conteneur modifie un fichier d’une couche de l’image, ce fichier est d’abord copié dans sa couche d’écriture. L’image ne change jamais.
• Supprimer ne libère rien : un RUN rm dans une couche ultérieure cache le fichier, mais il reste dans la couche où il a été ajouté, donc dans l’image (et il fuit si c’était un secret).
• Cache de build : Docker réutilise une couche tant que l’instruction et ses fichiers d’entrée n’ont pas changé. Dès qu’une couche change, toutes les suivantes sont reconstruites.

Lab : voir les couches de vos propres yeux

docker pull node:22-alpine
docker history node:22-alpine                          # une ligne par couche, avec sa taille
docker image inspect node:22-alpine --format '{{json .RootFS.Layers}}' | tr ',' '\n' | wc -l
docker image inspect node:22-alpine --format '{{json .GraphDriver.Data}}'    # LowerDir, UpperDir, MergedDir

# Copie à l'écriture : ce qu'un conteneur change
docker run -d --name essai node:22-alpine sleep 600
docker exec essai sh -c 'echo test > /tmp/a.txt && rm /usr/local/bin/npx'
docker diff essai                                      # A = ajouté, C = changé, D = supprimé
docker rm -f essai

# Espace partagé entre images
docker system df -v | head -20

Ce que vous observez	Pourquoi
docker history montre des couches de 0 o (ENV, WORKDIR, CMD)	Ces instructions ne changent que les métadonnées, pas les fichiers
docker diff affiche A /tmp/a.txt et D /usr/local/bin/npx	Les changements sont dans la couche d’écriture du conteneur, l’image est intacte
Dans un nouveau conteneur, npx est de nouveau là	La couche d’écriture a disparu avec le conteneur supprimé
La colonne SHARED SIZE de docker system df -v n’est pas nulle	Les images de même base partagent leurs couches sur le disque

Étape 2 : le cycle de vie d’un conteneur

docker run -d --name essai node:22-alpine sleep 600
docker ps                       # il tourne
docker exec -it essai sh        # entrer dedans, puis : node -v ; exit
docker stop essai && docker ps -a   # arrêté, mais toujours là
docker rm essai                 # supprimé, couche d'écriture comprise

docker volume create pgdata
docker run -d --name pg -e POSTGRES_PASSWORD=dev -v pgdata:/var/lib/postgresql/data postgres:17-alpine
docker exec -it pg psql -U postgres -c "create table tickets(id serial primary key, numero int);"
docker rm -f pg
docker run -d --name pg -e POSTGRES_PASSWORD=dev -v pgdata:/var/lib/postgresql/data postgres:17-alpine
docker exec -it pg psql -U postgres -c "\dt"   # la table tickets est là

Étape 3 : relier deux conteneurs par un réseau

docker network create montour_net
docker network connect montour_net pg
docker run --rm -it --network montour_net postgres:17-alpine \
  psql -h pg -U postgres -c "select 1"   # "pg" est résolu par son nom

Aucun port n’a été publié sur votre machine : la base n’est joignable que depuis le réseau montour_net. C’est exactement ce que vous ferez en production.

Étape 4 : faire le ménage

docker rm -f pg
docker network rm montour_net
docker volume rm pgdata
docker system df       # ce que Docker occupe sur le disque
docker system prune    # supprime ce qui est arrêté et inutilisé (lisez la question)

Le prompt reproductible

Même point de départ, même contexte, même résultat : partez du tag indiqué et collez ce prompt tel quel.

Point de départ : tag dk01 du dépôt MonTour.
Rôle : tu es un formateur Docker. Tu poses des questions, tu ne donnes
pas les réponses.
Tâche : pose-moi 5 questions courtes pour vérifier que je distingue image,
conteneur, volume et réseau, avec un exemple tiré de MonTour (base PostgreSQL,
application Next.js). Attends ma réponse à chaque question avant la suivante,
puis corrige en une ligne.
Contraintes : n'exécute aucune commande.

Qualité et sécurité : ce que vous vérifiez

• Les données ne vivent jamais dans un conteneur : toujours un volume nommé pour une base.
• Des tags précis : postgres:17-alpine, pas postgres:latest, pour que la même commande donne le même résultat dans six mois.
• Le minimum de ports publiés, et sur 127.0.0.1 quand c’est local.
• Sans IA : expliquez à voix haute ce que fait chaque option de la commande docker run de la base.

Vérifier

• ☐ Vous expliquez la différence entre image et conteneur en une phrase.
• ☐ La table tickets a survécu à la suppression du conteneur grâce au volume.
• ☐ Deux conteneurs se sont joints par leur nom sur montour_net.
• ☐ docker ps -a et docker volume ls sont propres après le ménage.
• ☐ Commit et tag dk02 posés (vos commandes dans docs/docker-memo.md).

Pour aller plus loin

• Chapitre suivant : premier Dockerfile pour MonTour
• Décrire tout cela dans un fichier avec Docker Compose (chapitre 07)
• Sauvegarder et restaurer une base (chapitre 20)