Jusqu’ici, nous avons appris à créer et lancer des conteneurs très facilement. Mais il y a un piège important quand on débute avec Docker : les données d’un conteneur ne sont pas faites pour durer.
Et ce comportement n’est pas un défaut.
C’est un choix de conception volontaire dans Docker.
Pour comprendre pourquoi, il faut revenir à un principe fondamental :
Un conteneur est éphémère.
Un conteneur est une instance temporaire d’une image
Dans les sections précédentes, nous avons vu qu’une image Docker est un modèle prêt à l’emploi, en lecture seule.
Lorsque Docker lance un conteneur à partir de cette image, il ajoute simplement une couche d’écriture temporaire au-dessus de l’image. Toutes les modifications effectuées dans le conteneur sont enregistrées dans cette couche.
Schéma simplifié :
IMAGE (lecture seule)
│
▼
CONTENEUR
(couche d'écriture temporaire)Cela signifie que si un fichier est créé, modifié ou supprimé dans le conteneur, la modification est stockée dans cette couche temporaire.
Que se passe-t-il si le conteneur disparaît ?
Lorsque l’on supprime un conteneur avec la commande :
docker rm mon-conteneur
Docker supprime également la couche d’écriture associée.
Concrètement, tout ce qui avait été créé ou modifié dans ce conteneur disparaît avec lui : les fichiers générés, les logs, les uploads… et même les bases de données si elles sont stockées à l’intérieur du conteneur.
Un petit exemple
Imaginons que l’on lance un conteneur Ubuntu pour faire quelques tests :
docker run -it ubuntu bash
À l’intérieur du conteneur, on crée un fichier :
touch fichier-important.txt
Le fichier est bien présent :
ls
fichier-important.txt
Mais si l’on quitte le conteneur, puis qu’on le supprime, toute cette couche d’écriture disparaît. Si l’on relance un nouveau conteneur basé sur la même image Ubuntu, ce fichier n’existera plus.
Ce n’est pas un bug : c’est simplement parce que le conteneur précédent n’existe plus.
Pourquoi Docker fonctionne comme ça ?
Ce fonctionnement peut surprendre au début, mais il apporte plusieurs avantages importants.
D’abord, les conteneurs deviennent jetables. On peut les arrêter, les supprimer et les recréer très rapidement. Cela simplifie énormément la gestion des applications et des environnements.
Ensuite, cela rend les déploiements prévisibles et reproductibles. Au lieu de modifier un serveur au fil du temps, on reconstruit simplement les conteneurs à partir de leur image.
Enfin, cette approche s’inscrit dans ce que l’on appelle l’infrastructure immutable : on ne modifie pas un conteneur existant, on le remplace par un nouveau.
Le problème pour les applications
Dans la réalité, certaines applications doivent conserver des données.
Une base de données MariaDB doit garder ses tables, un site WordPress doit conserver les images envoyées par les utilisateurs, et un outil comme Grafana doit stocker ses dashboards.
Si ces données restent à l’intérieur du conteneur, elles disparaîtront au moment où le conteneur sera supprimé ou recréé.
On comprend vite que ce serait catastrophique pour une application en production.
La solution : sortir les données du conteneur
Pour résoudre ce problème, Docker permet de stocker les données en dehors du conteneur, dans un espace persistant appelé volume.
Le principe est simple : le conteneur continue de fonctionner normalement, mais les données importantes sont écrites dans un emplacement externe.
CONTENEUR
│
▼
VOLUME DOCKER
(stockage persistant)
Ainsi, même si le conteneur est supprimé puis recréé, les données restent intactes.
C’est exactement ce que l’on fait, par exemple, avec MariaDB. Les fichiers de la base de données sont stockés dans un volume, ce qui garantit qu’ils ne disparaîtront pas lors d’une mise à jour ou d’un redémarrage du conteneur.
🧠 À retenir
Un conteneur Docker est temporaire par nature. Toutes les modifications qu’il contient sont enregistrées dans une couche d’écriture qui disparaît lorsque le conteneur est supprimé.
Pour les applications qui doivent conserver des données, il est donc indispensable d’utiliser un stockage persistant, généralement sous forme de volumes Docker.
C’est ce mécanisme qui permet de mettre à jour ou recréer des conteneurs sans jamais perdre les données de l’application.
Dans la prochaine partie, nous allons découvrir les deux grandes méthodes de persistance dans Docker : les Bind Mounts et les Named Volumes, ainsi que les cas où chacun d’eux est le plus adapté.
Et c’est souvent là que l’on commence à vraiment comprendre comment structurer correctement un projet Docker.