Vous démarrez une base de données dans un conteneur, ajoutez des données, supprimez le conteneur et en démarrez un nouveau. Les données ont disparu. Presque tout le monde apprend cette leçon à ses dépens. Les volumes Docker et les montages de liaison existent pour maintenir les données en vie au-delà de la durée de vie d’un conteneur.

Ce guide explique comment chacun fonctionne et comment choisir. Les commandes et fichiers ici sont des exemples standards, basés sur le comportement documenté de Docker, et nous ne les avons pas exécutés pour cet article, alors essayez-les d’abord sur des données jetables. Les détails peuvent différer entre les versions de Docker et sur Docker Desktop. Si vous débutez avec les conteneurs, commencez par notre Tutoriel Docker pour débutants.

Pourquoi les données des conteneurs disparaissent

Une image Docker est constituée de calques en lecture seule. Lorsqu’un conteneur démarre, Docker ajoute une fine couche inscriptible sur le dessus et toutes les modifications y sont transférées. Cette couche survit à un arrêt et un redémarrage, mais elle est supprimée lorsque le conteneur est supprimé.

docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# ... create tables and add data ...
docker rm -f db
docker run -d --name db -e POSTGRES_PASSWORD=devonly postgres:17
# The data you added is not there

C’est intentionnel, car cela vous permet de remplacer librement les conteneurs. Cela signifie que tout ce que vous devez conserver doit vivre en dehors du conteneur. Il existe trois façons de procéder :

Volumes Docker vs montages de liaison côte à côte

Volumes nommés

Un volume est un stockage créé et géré par Docker. Vous l’appelez par son nom et vous n’avez pas besoin de vous soucier de l’endroit où il vit physiquement.

docker volume create pgdata

docker run -d --name db \
  -e POSTGRES_PASSWORD=devonly \
  -v pgdata:/var/lib/postgresql/data \
  postgres:17

Désormais, les fichiers de la base de données résident dans pgdata. Supprimez le conteneur et démarrez-en un nouveau avec le même volume, et vos données seront toujours là. Sous Linux, les volumes se trouvent généralement sous /var/lib/docker/volumes/, mais vous ne devez pas modifier ces fichiers directement. Sur Docker Desktop, ils vivent dans une machine virtuelle, pas dans un dossier normal.

Le chemin à l’intérieur du conteneur dépend de l’image, consultez donc la documentation de l’image. Monter sur le mauvais chemin est une erreur classique : tout semble fonctionner, mais les données sont toujours en cours d’écriture dans la couche conteneur. Les versions majeures plus récentes d’une image peuvent également modifier ce chemin, alors lisez les notes de version avant la mise à niveau.

Docker créera automatiquement un volume nommé s’il n’existe pas. Un volume anonyme, créé sans nom, fonctionne également, mais il obtient un long identifiant aléatoire et est facile à perdre de vue. Donnez toujours les noms de vos volumes.

Lier les montures

Un montage de liaison mappe un chemin d’hôte spécifique directement dans le conteneur. Les deux parties voient immédiatement les mêmes fichiers. Cela le rend parfait pour le développement, car les modifications dans votre éditeur prennent effet dans le conteneur en cours d’exécution sans reconstruction :

docker run -d --name web \
  -p 8080:80 \
  -v "$(pwd)/site:/usr/share/nginx/html:ro" \
  nginx:1.27

Modifiez un fichier dans site/, actualisez le navigateur et vous verrez le changement. Le :ro rend le montage en lecture seule à l’intérieur du conteneur, ce qui est une bonne habitude lorsque le conteneur n’a pas besoin d’y écrire.

Les montures liées comportent certains compromis :

• Ils vous lient à l’hôte. Le chemin doit exister sur chaque machine, les configurations sont donc moins portables.
• Ils cachent le contenu de l’image. Si vous montez sur /app, tout ce que l’image contenait devient invisible. Un exemple courant est la disparition de node_modules.
• Ils exposent l’hôte. Un conteneur avec un montage inscriptible peut modifier ou supprimer de vrais fichiers hôtes. Ne montez jamais de chemins sensibles comme / ou le socket Docker à moins que vous ne compreniez parfaitement le risque.
• Les performances peuvent varier. Sur Docker Desktop pour macOS et Windows, le partage de fichiers franchit les limites de la virtualisation et peut être plus lent que sous Linux.

montages tmpfs

Un montage tmpfs réside dans la mémoire de l’hôte et n’est jamais écrit dans la couche conteneur. Il disparaît lorsque le conteneur s’arrête, il convient donc aux fichiers temporaires, aux caches et aux données sensibles de courte durée :

docker run -d --tmpfs /app/cache:size=64m myapp:1.0

tmpfs est disponible sur les hôtes Linux. Il peut également accélérer les bases de données dans des environnements de test jetables, où vous ne vous souciez pas de conserver les données.

-v ou –mount ?

Les deux drapeaux fonctionnent. --mount est plus long, mais il est plus explicite, et beaucoup de gens le préfèrent dans les scripts :

# Short form
docker run -v pgdata:/var/lib/postgresql/data postgres:17

# Explicit form
docker run --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres:17

# Bind mount, read-only
docker run --mount type=bind,source="$(pwd)"/site,target=/usr/share/nginx/html,readonly nginx:1.27

Il y a une différence significative. Avec -v, un chemin d’hôte manquant est créé pour vous sous la forme d’un dossier vide, ce qui peut masquer une faute de frappe. Avec --mount et un type de liaison, Docker signale une erreur à la place. De plus, avec -v, le côté gauche décide du type : un nom signifie un volume et un chemin signifie un montage lié. Donc -v data:/x et -v ./data:/x font des choses très différentes.

Volumes dans Docker Compose

La plupart des projets réels déclarent le stockage dans un fichier Compose. Celui-ci utilise les deux types, chacun pour son propre travail :

services:
  web:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src      # bind mount: live code
    depends_on:
      - db

  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: devonly
    volumes:
      - pgdata:/var/lib/postgresql/data   # named volume: data

volumes:
  pgdata:

Les volumes nommés doivent être déclarés dans la section de niveau supérieur volumes. Compose préfixe le nom réel avec le nom du projet. Consultez notre Tutoriel Docker Compose pour une présentation complète.

Commandes de volume utiles

Vérifiez ce que prune supprimera avant de le confirmer, car cela ne peut pas être annulé. Les volumes qu’aucun conteneur n’utilise actuellement peuvent toujours contenir des données importantes.

Sauvegarder et restaurer un volume

Un volume peut être sauvegardé en exécutant un conteneur éphémère qui monte à la fois le volume et un dossier hôte :

# Back up
docker run --rm \
  -v pgdata:/data:ro \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/pgdata.tar.gz -C /data .

# Restore into a new volume
docker volume create pgdata_restored
docker run --rm \
  -v pgdata_restored:/data \
  -v "$(pwd)":/backup \
  alpine tar xzf /backup/pgdata.tar.gz -C /data

Pour une base de données active, la copie de fichiers comme celui-ci peut capturer un état incohérent. Arrêtez d’abord le conteneur, ou mieux, utilisez le propre outil de la base de données, tel que pg_dump pour PostgreSQL. Et une sauvegarde que vous n’avez jamais restaurée n’est en réalité qu’un espoir, alors testez la restauration.

Autorisations de fichiers

« Autorisation refusée » est le problème le plus courant avec les montages. Les fichiers conservent leurs identifiants numériques d’utilisateur et de groupe sous Linux, donc si un conteneur s’exécute en tant qu’utilisateur 1000 et que le dossier hôte appartient à un autre utilisateur, les écritures échoueront. Quelques façons de résoudre ce problème :

• Exécutez le conteneur avec un utilisateur correspondant : docker run --user "$(id -u):$(id -g)" ...
• Configurez la propriété correcte de votre image, comme décrit dans nos Bonnes pratiques Dockerfile.
• Préférez les volumes nommés pour les données, car un nouveau volume devient propriétaire du dossier de l’image lors de sa première utilisation.
• Sur les systèmes utilisant SELinux, les montages de liaison peuvent nécessiter une étiquette :z ou :Z.

Évitez la tentation de chmod 777, comme l’explique notre guide des commandes Linux.

Lequel devriez-vous utiliser ?

Cette dernière ligne compte. En production, le code appartient à l’image, de sorte que ce que vous avez testé correspond à ce que vous exécutez. Dans les clusters, le stockage des données fonctionne encore différemment, via des volumes persistants, qui sont traités dans la documentation plus large de Kubernetes. Notre guide Docker vs Kubernetes explique la relation entre les deux.

Erreurs courantes

• Montage sur le mauvais chemin. Les données résident toujours dans la couche conteneur et disparaissent plus tard.
• Exécuter down -v avec désinvolture. Cela supprime vos volumes nommés.
• Utilisation de chemins relatifs avec -v. Des formulaires comme -v data:/x créent un volume plutôt qu’un mappage de dossiers.
• Mettre les secrets dans des montages de liaison inscriptibles. Montez-les en lecture seule ou utilisez une fonctionnalité de secrets.
• Pointage de deux conteneurs de base de données sur un seul volume. Cela peut corrompre les données.
• N’avoir aucune sauvegarde. Un volume n’est pas une sauvegarde. Il vit sur le même disque.

Pour conclure

La règle générale est courte : des volumes nommés pour les données, des montages de liaison pour le code que vous modifiez et des tmpfs pour les choses qui ne devraient pas durer. Essayez-le sur une base de données jetable. Créez un volume nommé, ajoutez une ligne, supprimez le conteneur, démarrez-en un nouveau et confirmez que votre ligne a survécu. Pratiquez ensuite une sauvegarde et une restauration avant d’en avoir besoin.

Questions fréquentes

Continuez à apprendre