Docker (4/9) — Persistance : volumes & données

L’idée reçue

« Ce que j’écris dans un conteneur est sauvegardé, comme sur un PC. »

Faux — et c’est même une propriété fondamentale de Docker. Par défaut, tout ce qu’un conteneur écrit disparaît avec lui. On va le prouver, comprendre pourquoi c’est voulu, puis apprendre à garder les données qui comptent grâce aux volumes.

À la fin de ce module, tu sauras…

Prouver que le système de fichiers d’un conteneur est éphémère
Expliquer pourquoi cette éphémérité est une force, pas un défaut
Créer et brancher un volume pour persister des données
Distinguer volume nommé et montage de dossier (bind mount)

01La preuve par l’oubli

Expérience 1

Écris, détruis, constate

Manipule

docker run -it --name test-data debian bash
echo "données importantes" > /data.txt
cat /data.txt
exit

Le conteneur est arrêté. Supprime-le, recrée-en un tout neuf de la même image, et cherche le fichier :

Manipule

docker rm test-data
docker run -it --name test-data debian bash
cat /data.txt

Observe

cat: /data.txt: No such file or directory

Le fichier a disparu. Le nouveau conteneur repart de l’image d’origine, vierge. Tout ce qui avait été écrit est perdu.

Comprends la couche inscriptible

Un conteneur ajoute une fine couche inscriptible par-dessus l’image (en lecture seule). Tes écritures vont dans cette couche — qui est détruite avec le conteneur. L’image, elle, ne change jamais. D’où l’oubli.

02Pourquoi c’est une bonne chose

Cette éphémérité peut sembler absurde. Elle est en fait au cœur de la puissance de Docker.

Comprends jetable = reproductible

Comme un conteneur repart toujours de l’image, il est reproductible et jetable : même comportement partout, aucun état caché qui traîne. On peut le tuer et le relancer sans crainte. C’est ce qui rend possible la mise à l’échelle et les déploiements fiables. La règle : le conteneur est sans état ; les données qui doivent survivre vivent ailleurs — dans un volume.

03Le volume nommé

Expérience 2

Persister pour de vrai

Manipule

docker volume create mes-donnees
docker run -it --name coffre -v mes-donnees:/data debian bash
echo "je survivrai" > /data/note.txt
exit

Détruis le conteneur, recrée-en un autre branché sur le même volume :

Manipule

docker rm coffre
docker run -it --name coffre2 -v mes-donnees:/data debian bash
cat /data/note.txt

Observe

je survivrai

Cette fois, la donnée a survécu à la destruction du conteneur : elle vit dans le volume, indépendant du conteneur.

Comprends le volume, en une phrase

Un volume est un espace de stockage géré par Docker, séparé du cycle de vie des conteneurs. On le « monte » dans le conteneur avec -v nom:/chemin. Les conteneurs vont et viennent ; le volume, lui, reste. C’est là que vivent bases de données, fichiers uploadés, etc.

04Monter un dossier de l’hôte (bind mount)

Expérience 3

Partager un dossier réel avec le conteneur

Manipule

mkdir ~/partage
echo "fichier depuis l'hote" > ~/partage/hello.txt
docker run -it --name lien -v ~/partage:/data debian bash
cat /data/hello.txt

Observe

fichier depuis l'hote

Le conteneur lit un dossier de la VM hôte. Crée un fichier dans /data depuis le conteneur : il apparaît aussi côté hôte. Le dossier est partagé dans les deux sens.

Comprends volume nommé vs bind mount

Un volume nommé (mes-donnees:/data) est géré par Docker, idéal pour les données de production (bases…). Un bind mount (~/partage:/data) monte un dossier précis de l’hôte, pratique en développement pour partager du code. Deux outils, deux usages.

✓Ce que tu retiens

Le conteneur est éphémère et sans état — et c’est une force. Les données qui doivent survivre vivent dans un volume : nommé (géré par Docker, pour la production) ou en bind mount (un dossier de l’hôte, pour le développement). Conteneur jetable, données persistantes : la séparation clé.

Mini-projet

Une donnée qui survit

À faire

Crée un volume db-data.
Lance un conteneur qui écrit un fichier dans /var/lib/data monté sur ce volume.
Détruis le conteneur, recrée-en un sur le même volume, prouve que la donnée est là.
Avec docker volume ls et docker volume inspect db-data, retrouve où Docker stocke ce volume sur l’hôte.
Explique en 3 lignes : pourquoi ne jamais stocker une base de données dans le conteneur ?

Fil rouge — Tu sais faire tourner et persister. Il est temps de lancer un vrai service accessible depuis le réseau : au module suivant, on met en ligne Nginx, avec ports et fichiers montés.

?Auto-évaluation

1. Que deviennent les fichiers écrits dans un conteneur, sans volume, après sa suppression ?

Ils sont perdus : la couche inscriptible du conteneur est détruite avec lui.

2. Pourquoi l’éphémérité d’un conteneur est-elle une force ?

Elle le rend reproductible et jetable : même comportement partout, aucun état caché, on peut le relancer sans crainte.

3. Quand préférer un bind mount à un volume nommé ?

En développement, pour partager un dossier précis de l’hôte (ex. du code). Le volume nommé est préférable pour les données de production.