Gérer la persistance des données avec les volumes (concept de base)

Le défi des données dans un monde de conteneurs éphémères

L'un des concepts les plus importants à saisir lorsque l'on travaille avec Docker est la nature éphémère du système de fichiers d'un conteneur. Par défaut, lorsqu'un conteneur est créé, il dispose de sa propre couche d'écriture isolée. Tous les fichiers créés ou modifiés par l'application à l'intérieur de ce conteneur résident sur cette couche. Cependant, cette couche est intrinsèquement liée au cycle de vie du conteneur : si vous supprimez le conteneur (`docker rm`), toutes les données présentes sur cette couche sont définitivement perdues.

Cela pose un problème majeur pour toute application qui doit conserver un état ou des données au-delà d'une simple exécution. Pensez aux bases de données, aux fichiers téléversés par les utilisateurs, aux fichiers de configuration modifiables, aux logs que vous souhaitez conserver durablement, etc. Si ces données étaient stockées directement dans le système de fichiers par défaut du conteneur, elles disparaîtraient avec lui.

Pour résoudre ce problème fondamental, Docker propose un mécanisme puissant et flexible : les volumes. Les volumes sont le moyen privilégié et recommandé pour assurer la persistance des données générées et utilisées par les conteneurs Docker.

Qu'est-ce qu'un volume Docker ?

Un volume Docker est essentiellement un répertoire (ou un fichier, dans certains cas avancés) qui est géré par Docker et qui existe en dehors du système de fichiers union (UnionFS) standard du conteneur. Ce répertoire est stocké sur la machine hôte, mais son emplacement exact est géré par Docker lui-même (dans le cas des volumes nommés) ou spécifié par l'utilisateur (dans le cas des bind mounts).

L'idée clé est de découpler le stockage des données du cycle de vie du conteneur. Vous "montez" un volume à un emplacement spécifique à l'intérieur du système de fichiers du conteneur (par exemple, monter un volume dans `/var/lib/mysql` pour un conteneur MySQL). L'application à l'intérieur du conteneur lit et écrit dans ce répertoire comme si c'était un répertoire normal, mais en réalité, les données sont stockées dans le volume sur l'hôte.

Grâce à ce mécanisme :

• Les données persistent même si le conteneur est arrêté, supprimé et recréé.
• Les données peuvent être facilement partagées entre plusieurs conteneurs (par exemple, un conteneur applicatif et un conteneur de sauvegarde accédant aux mêmes données).
• La gestion des données (sauvegarde, migration, inspection) est simplifiée car elles résident dans un emplacement distinct et géré.

Types de montages pour la persistance : volumes nommés et bind mounts

Pour attacher un stockage persistant à un conteneur, Docker propose principalement deux types de montages (il en existe d'autres comme tmpfs, mais nous nous concentrons sur la persistance) :

1. Volumes nommés (Named Volumes) : C'est la méthode recommandée par Docker pour la persistance des données applicatives. Avec un volume nommé, vous donnez un nom logique au volume (ex: `donnees-postgres`, `config-wordpress`). Docker se charge de créer (si nécessaire) et de gérer le stockage physique de ce volume dans une zone dédiée de la machine hôte (généralement sous `/var/lib/docker/volumes/` sur Linux). L'emplacement exact n'a pas d'importance pour l'utilisateur au quotidien. Les volumes nommés sont portables, faciles à gérer avec les commandes `docker volume ...` (create, ls, inspect, rm, prune), et fonctionnent de manière cohérente sur toutes les plateformes (Linux, Windows, macOS).

# Syntaxe avec -v : docker run -v : image
docker run -d --name db -v pgdata:/var/lib/postgresql/data postgres

# Syntaxe préférée avec --mount : docker run --mount type=volume,source=,target= image
docker run -d --name db --mount type=volume,source=pgdata,target=/var/lib/postgresql/data postgres

2. Bind Mounts : Avec un bind mount, vous montez un fichier ou un répertoire existant de votre machine hôte directement à un emplacement spécifique dans le conteneur. Contrairement aux volumes nommés, vous contrôlez (et devez connaître) l'emplacement exact sur l'hôte. C'est très utile dans certains scénarios, notamment :

• Monter le code source de votre application dans le conteneur pendant le développement pour voir les changements en direct sans reconstruire l'image.
• Monter des fichiers de configuration spécifiques depuis l'hôte vers le conteneur.

# Syntaxe avec -v : docker run -v : image
docker run -d -p 80:80 -v /home/user/my-site:/usr/share/nginx/html nginx

# Syntaxe préférée avec --mount : docker run --mount type=bind,source=,target= image
docker run -d -p 80:80 --mount type=bind,source=/home/user/my-site,target=/usr/share/nginx/html nginx

Quand utiliser quoi ? Le choix judicieux

La règle générale est simple :

• Pour toutes les données générées par l'application qui doivent persister (bases de données, uploads, état interne...), utilisez des volumes nommés.
• Pour fournir des fichiers depuis l'hôte vers le conteneur (code source en développement, fichiers de configuration spécifiques), utilisez des bind mounts.

Comprendre et utiliser correctement les volumes est absolument fondamental pour déployer des applications stateful (qui maintiennent un état) avec Docker. Sans eux, vos données seraient perdues à chaque suppression de conteneur, rendant impossible l'utilisation de Docker pour des applications comme les bases de données ou les systèmes de gestion de contenu. En privilégiant les volumes nommés pour les données applicatives, vous bénéficiez d'une solution de persistance robuste, portable et bien intégrée à l'écosystème Docker.