Cum funcționează persistența datelor cu Docker volumes?

Question

Accepted Answer

În mod implicit, datele dintr-un container sunt **efemere** — pierdute atunci când containerul este eliminat. **Volumes** (și bind mounts) oferă **stocare persistentă** care supraviețuiește containerelor, esențial pentru baze de date și orice date care trebuie să supraviețuiască restarturilor/eliminărilor containerelor.

## Problema: containerele sunt efemere

```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 — stocare persistentă gestionată

```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** sunt stocare persistentă gestionată de Docker (stocată pe host, gestionată de Docker) — modul preferat pentru a persista datele. Datele din calea montată supraviețuiesc chiar dacă containerul este eliminat.

## Bind mounts — mapează un director gazdă

```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** mapează un director gazdă în container — util pentru dezvoltare (editarea codului pe gazdă, observarea schimbărilor în viu în container).

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

## De ce contează

Înțelegerea persistenței datelor cu volumes este esențială pentru utilizarea corectă a Docker cu orice aplicație care are date, deci este cunoștință practică importantă.

Problema fundamentală — **containerele sunt efemere**, cu stratul lor inscriptibil șters la eliminare, ceea ce înseamnă că **datele scrise în interiorul unui container sunt pierdute** — este un concept critic: containerele sunt concepute să fie disponibile, deci stocarea datelor importante în interiorul lor (cum ar fi fișierele unei baze de date) provoacă pierderea datelor când containerul este înlocuit. **Volumes** rezolvă aceasta prin furnizarea **stocare persistentă gestionată de Docker** care trăiește în afara ciclului de viață al containerului, deci datele (baze de date, încărcări, orice stare) supraviețuiesc eliminării și înlocuirii containerului — esențial pentru aplicații stateful.

Înțelegerea **bind mounts** (maparea unui director gazdă în container) este importantă pentru **dezvoltare** (editarea codului pe gazdă și observarea schimbărilor în viu în container, un flux de dezvoltare foarte obișnuit) și pentru partajarea fișierelor gazdei.

Cunoașterea **distincției** — volumes (gestionat de Docker, portabil, alegerea preferată pentru datele persistent ale aplicației, cum ar fi bazele de date) versus bind mounts (specific cale gazdă, excelent pentru dezvoltare) — ghidează alegerea abordării corecte.

Deoarece containerele sunt efemere din concepție și majoritatea aplicațiilor reale au date care trebuie să persiste (special bazele de date), și deoarece volumes sunt mecanismul esențial pentru stocare persistentă (cu bind mounts importante pentru dezvoltare), înțelegerea persistenței datelor Docker — problema containerului efemer, volumes pentru date persistent, bind mounts pentru dezvoltare, și când să utilizezi fiecare — este cunoștință Docker esențială, practic relevantă, necesară pentru a executa corect aplicații stateful și pentru a evita greșeala gravă de a pierde datele stocate în containerele disponibile.