Volumes : où résident réellement les données des conteneurs

Un conteneur est jetable. Tout ce qui est écrit à l'intérieur disparaît avec lui. Les données doivent vivre à l'extérieur, et il existe exactement deux façons de faire : un volume nommé et un montage de répertoire hôte (bind mount).

Deux méthodes et quand les utiliser

services:
  db:
    image: postgres:17
    volumes:
      - db-data:/var/lib/postgresql/data   # named volume
  app:
    image: nginx:1.27
    volumes:
      - ./site:/usr/share/nginx/html:ro    # directory bind mount
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

volumes:
  db-data:

Un volume nommé est créé et stocké par Docker lui-même, dans /var/lib/docker/volumes/<name>/_data. Les permissions à l'intérieur sont définies automatiquement par l'image. C'est ainsi que l'on conserve les bases de données et l'état interne des services.

Un montage de répertoire hôte est un chemin ordinaire sur le disque de la machine. C'est ainsi que vous fournissez les fichiers de configuration, les ressources statiques d'un site web et les certificats : ils sont pratiques à modifier dans un éditeur et à stocker dans un dépôt.

L'option :ro rend le montage en lecture seule. Utilisez-la partout où le conteneur n'a pas besoin d'un accès en écriture — c'est une protection peu coûteuse.

Où tout est physiquement stocké

docker volume ls
docker volume inspect db-data
docker inspect -f '{{json .Mounts}}' <container> | python3 -m json.tool
sudo du -sh /var/lib/docker/volumes/* | sort -h | tail

La dernière commande est la première à exécuter lorsque l'espace disque vient à manquer. Plus de détails : espace disque.

docker compose down -v et docker volume prune suppriment définitivement les volumes. Un volume contenant une base de données semble « inutilisé » tant que le conteneur est arrêté et tombe sous le coup du nettoyage. Avant de nettoyer, consultez la liste : docker volume ls -f dangling=true.

Copie et migration

Copier un volume nommé avec un conteneur jetable :

docker run --rm -v db-data:/from -v $(pwd):/to alpine \
  tar czf /to/db-data.tar.gz -C /from .

Restauration :

docker volume create db-data
docker run --rm -v db-data:/to -v $(pwd):/from alpine \
  tar xzf /from/db-data.tar.gz -C /to

Pour les bases de données, cette méthode ne convient que lorsque le conteneur est arrêté : une copie au niveau des fichiers d'une base de données en cours d'exécution peut être incohérente. Il vaut mieux effectuer un dump avec les outils propres à la base de données — pg_dump, mysqldump. Voir ce qu'il faut copier exactement.

Permissions

L'erreur la plus fréquente avec les montages de répertoires hôte est une inadéquation du propriétaire. À l'intérieur du conteneur, le processus s'exécute sous son propre UID, et un fichier créé par l'hôte en tant que root lui est inaccessible.

docker compose exec app id
sudo chown -R 1000:1000 ./data

De nombreuses images acceptent les variables PUID/PGID — c'est plus pratique que de changer le propriétaire du répertoire.

Erreurs courantes

• Les données ont été écrites à l'intérieur du conteneur. Vous avez recréé le conteneur lors d'une mise à jour — les données ont disparu. Vérification : docker diff <container> montrera ce qui a changé dans son système de fichiers ; des écritures volumineuses à cet endroit sont un signal d'alerte.
• Vous avez monté un répertoire hôte sur un chemin non vide de l'image. Le contenu de l'image est masqué et le service ne trouve plus ses fichiers.
• Un chemin relatif dans un montage de répertoire hôte. Il est résolu depuis le répertoire contenant compose.yaml, et non depuis le répertoire courant. Une exécution depuis un autre emplacement créera un nouveau répertoire vide.
• Les volumes ont été oubliés lors de la réinstallation du système d'exploitation. La réinstallation efface entièrement le disque. La copie doit être stockée pas sur cette machine.