Hoe werkt gegevenspersistentie met Docker volumes?

Question

Accepted Answer

Standaard zijn gegevens in een container **vluchtig** — verloren wanneer de container wordt verwijderd. **Volumes** (en bind mounts) bieden **persistente opslag** die containers overleeft, essentieel voor databases en alle gegevens die container-restarts/verwijderingen moeten overleven.

## Het probleem: containers zijn vluchtig

```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 — beheerde persistente opslag

```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
```

**Volumes** zijn door Docker beheerde persistente opslag (opgeslagen op de host, beheerd door Docker) — de voorkeurmanier om gegevens persistent te maken. Gegevens in het gemounte pad overleven zelfs als de container wordt verwijderd.

## Bind mounts — een hostmap toewijzen

```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)
```

**Bind mounts** wijzen een hostdirectory toe aan de container — nuttig voor ontwikkeling (code bewerken op de host, wijzigingen live zien in de container).

## Volumes versus 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
```

## Waarom het belangrijk is

Inzicht in gegevenspersistentie met volumes is essentieel voor correct gebruik van Docker met elke applicatie die gegevens heeft, dus het is belangrijke praktische kennis.

Het fundamentele probleem — **containers zijn vluchtig**, met hun beschrijfbare laag verwijderd bij verwijdering, wat betekent dat **gegevens die in een container zijn geschreven verloren gaan** — is een kritiek concept: containers zijn bedoeld om wegwerpbaar te zijn, dus het opslaan van belangrijke gegevens erin (zoals bestanden van een database) veroorzaakt gegevensverlies wanneer de container wordt vervangen. **Volumes** lossen dit op door **door Docker beheerde persistente opslag** te bieden die buiten de containerlevenscyclus leeft, dus gegevens (databases, uploads, elke status) overleven containerverwijdering en vervanging — essentieel voor stateful applicaties.

Inzicht in **bind mounts** (een hostdirectory aan de container toewijzen) is belangrijk voor **ontwikkeling** (code bewerken op de host en wijzigingen live zien in de container, een zeer gebruikelijke dev-workflow) en voor het delen van hostbestanden.

Kennis van het **onderscheid** — volumes (door Docker beheerd, draagbaar, de voorkeur voor persistente applicatiegegevens zoals databases) versus bind mounts (host-pad-specifiek, geweldig voor ontwikkeling) — leidt tot het kiezen van de juiste benadering.

Daardat containers inherent vluchtig zijn en de meeste echte applicaties gegevens hebben die persistent moeten zijn (vooral databases), en daardat volumes het essentiële mechanisme zijn voor persistente opslag (met bind mounts belangrijk voor ontwikkeling), is inzicht in Docker-gegevenspersistentie — het vluchtig-containerprobleem, volumes voor persistente gegevens, bind mounts voor ontwikkeling, en wanneer elk te gebruiken — essentiële, praktisch relevante Docker-kennis, nodig voor correct uitvoeren van stateful applicaties en voorkoming van de ernstige fout van gegevensverlies dat in wegwerpbare containers is opgeslagen.