Docker Volume : rendre les données persistantes

Un docker volume est une unité de stockage persistant qui maintient vos données en vie même lorsqu'un container est supprimé, recréé ou que son image est mise à jour. Par conception, les containers Docker sont éphémères : lorsque vous en supprimez un avec docker rm, tout ce qui se trouve dans sa couche inscriptible disparaît avec lui. Si des fichiers de base de données, des images téléversées ou des logs d'application vivent dans cette couche, un seul docker compose down peut effacer des heures de données accumulées. Les volumes existent précisément pour résoudre ce problème.

Pourquoi écrire des données dans un container est risqué

Une image Docker est construite à partir de couches en lecture seule empilées. Quand un container s'exécute, une fine couche inscriptible est ajoutée par-dessus et chaque modification y est écrite. Cette couche est liée à la durée de vie du container ; quand le container disparaît, la couche aussi. En conséquence :

• Recréer le container (mise à jour d'image, changement de configuration) supprime les données.
• L'accès disque via la couche inscriptible est plus lent qu'une écriture directe sur le disque.
• Sauvegarder les données depuis l'extérieur du container, ou les partager avec un autre container, devient difficile.

Tout ce qui doit persister doit vivre en dehors du système de fichiers du container, dans un espace géré par Docker. Cet espace est un volume.

Volume, bind mount et tmpfs

Docker propose trois types de montages, et savoir lequel choisir compte :

• Volume : géré par Docker sur l'hôte sous /var/lib/docker/volumes/. Il est portable, facile à sauvegarder et l'option recommandée en production.
• Bind mount : relie un dossier précis de l'hôte (comme /home/user/projet) directement dans le container. Idéal pour éditer le code en direct pendant le développement, mais fortement couplé à la structure de l'hôte.
• tmpfs : conserve les données uniquement en RAM ; elles disparaissent à l'arrêt du container. Utilisé pour des données temporaires ou sensibles.

Une règle simple : utilisez un volume quand vous voulez que les données appartiennent à Docker, et un bind mount quand vous voulez les lier à un répertoire réel sur l'hôte.

Créer et utiliser un volume

Le scénario le plus courant consiste à créer un volume nommé et à l'attacher à un container :

docker volume create db_data

docker run -d \
  --name postgres \
  -v db_data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret \
  postgres:16

La partie -v db_data:/var/lib/postgresql/data dit : monte le volume nommé db_data sur le répertoire de données de PostgreSQL dans le container. Supprimez le container et relancez-le avec le même volume : la base de données est toujours là. Pour inspecter les volumes existants :

docker volume ls
docker volume inspect db_data

Données persistantes avec Compose

Dans des projets réels, vous définissez généralement les volumes dans docker-compose.yml. L'exemple ci-dessous exécute une base de données avec un volume persistant :

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: secret
    volumes:
      - mysql_data:/var/lib/mysql

volumes:
  mysql_data:

Le bloc volumes: de premier niveau déclare le volume nommé, et la ligne à l'intérieur du service le monte. Exécuter docker compose down supprime les containers mais conserve le volume mysql_data ; docker compose up ramène les données. Pour supprimer aussi le volume, vous lancez délibérément docker compose down -v.

Sauvegarder et restaurer un volume

Comme les volumes vivent intégrés dans le système de fichiers de l'hôte, la manière propre d'en sauvegarder un est d'archiver son contenu avec un container auxiliaire jetable :

# Sauvegarde : enregistrer le volume db_data en tar.gz
docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/db_data.tar.gz -C /data .

# Restauration : extraire l'archive dans un volume vide
docker run --rm \
  -v db_data:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/db_data.tar.gz -C /data

Cette approche monte un petit container alpine sur le volume et le répertoire courant, puis le compresse avec tar. Pour les bases de données, réaliser des sauvegardes logiques comme mysqldump ou pg_dump ajoute une seconde couche plus sûre contre la corruption.

Erreurs fréquentes

• Monter le mauvais chemin : si vous ne montez pas le volume sur le répertoire où l'application écrit réellement (par ex. /var/lib/postgresql/data pour PostgreSQL), rien ne persiste.
• Problèmes de permissions : quand l'identifiant utilisateur du container ne correspond pas au propriétaire des fichiers dans le volume, vous obtenez des erreurs « permission denied ».
• Accumuler des volumes anonymes : les volumes créés sans nom s'accumulent et remplissent le disque avec le temps ; nettoyez-les avec docker volume prune (prudemment).

Questions fréquentes

Dois-je choisir un volume ou un bind mount ?

En production, choisissez un volume quand vous voulez des données portables et gérées par Docker. Pendant le développement, un bind mount est plus pratique si vous voulez éditer le code de l'hôte en direct.

Si je supprime le container, le volume est-il supprimé aussi ?

Non. Les volumes nommés sont indépendants du container et ne sont pas supprimés par docker rm. Seule une commande explicite comme docker volume rm ou docker compose down -v supprime le volume.

Plusieurs containers peuvent-ils partager le même volume ?

Oui, vous pouvez attacher le même volume à plusieurs containers. Cependant, pour des services qui attendent un seul rédacteur, comme les bases de données, écrire en parallèle dans le même volume peut provoquer une corruption ; planifiez cela soigneusement.

Ne laissez pas vos données à la merci d'un container. Si vous avez besoin d'aide pour une stratégie de docker volume, des sauvegardes ou la mise en place d'une infrastructure de containers, contactez-moi.