Comment fonctionne la persistence des données avec les volumes Docker ?

Question

Accepted Answer

Par défaut, les données dans un conteneur sont **éphémères** — perdues lors de la suppression du conteneur. Les **volumes** (et les bind mounts) fournissent un **stockage persistant** qui dépasse la durée de vie des conteneurs, essentiel pour les bases de données et toute donnée qui doit survivre aux redémarrages/suppressions de conteneurs.

## Le problème : les conteneurs sont éphémères

```text
A container's writable layer is DELETED when the container is removed:
  → data written inside the container (e.g. a database's files) is LOST
  → containers are meant to be disposable/replaceable → don't store important data in them
→ For persistent data, you need storage OUTSIDE the container's lifecycle.
```

## Volumes — stockage persistant géré

```bash
# create and use a named volume (managed by Docker)
docker volume create mydata
docker run -v mydata:/var/lib/mysql mysql      # mount the volume into the container
# → data in /var/lib/mysql persists in the volume, surviving container removal

docker volume ls                 # list volumes
docker volume inspect mydata     # details
```

Les **volumes** sont un stockage persistant géré par Docker (stocké sur l'hôte, géré par Docker) — la façon préférée de persister les données. Les données dans le chemin monté survivent même si le conteneur est supprimé.

## Bind mounts — mapper un répertoire hôte

```bash
# bind mount: map a specific HOST directory into the container
docker run -v /host/path:/app -p 3000:3000 myapp
docker run -v $(pwd):/app myapp   # mount the current directory (great for development)
# → changes on the host are reflected in the container (and vice versa)
```

Les **bind mounts** mappent un répertoire hôte dans le conteneur — utile pour le développement (édition du code sur l'hôte, voir les changements en direct dans le conteneur).

## Volumes vs bind mounts

```text
VOLUMES      → Docker-managed, portable, the preferred choice for PERSISTENT DATA
               (databases, uploads) — decoupled from the host's filesystem layout
BIND MOUNTS  → map a specific host path; great for DEVELOPMENT (live code reload)
               and sharing host files; tied to the host's filesystem
tmpfs        → in-memory (non-persistent), for sensitive/temporary data
```

## Pourquoi c'est important

Comprendre la persistence des données avec les volumes est essentiel pour utiliser Docker correctement avec toute application qui a des données, c'est donc une connaissance pratique importante.

Le problème fondamental — **les conteneurs sont éphémères**, avec leur couche inscriptible supprimée lors de la suppression, ce qui signifie que **les données écrites à l'intérieur d'un conteneur sont perdues** — est un concept critique : les conteneurs sont destinés à être jetables, donc stocker des données importantes à l'intérieur (comme les fichiers d'une base de données) provoque une perte de données lors du remplacement du conteneur. Les **volumes** résolvent ce problème en fournissant un **stockage persistant géré par Docker** qui vit en dehors du cycle de vie du conteneur, donc les données (bases de données, uploads, tout état) survivent à la suppression et au remplacement du conteneur — essentiel pour les applications avec état.

Comprendre les **bind mounts** (mapper un répertoire hôte dans le conteneur) est important pour le **développement** (éditer le code sur l'hôte et voir les changements en direct dans le conteneur, un workflow dev très courant) et pour partager les fichiers d'hôte.

Connaître la **distinction** — volumes (gérés par Docker, portables, le choix préféré pour les données persistantes des applications comme les bases de données) versus bind mounts (spécifiques au chemin hôte, excellents pour le développement) — guide le choix de la bonne approche.

Puisque les conteneurs sont éphémères par conception et que la plupart des applications réelles ont des données qui doivent persister (les bases de données en particulier), et puisque les volumes sont le mécanisme essentiel du stockage persistant (avec les bind mounts importants pour le développement), comprendre la persistence des données Docker — le problème du conteneur éphémère, les volumes pour les données persistantes, les bind mounts pour le développement, et quand utiliser chacun — est une connaissance Docker essentielle, pratiquement pertinente, nécessaire pour exécuter correctement les applications avec état et éviter l'erreur grave de perdre des données stockées dans des conteneurs jetables.