Jak działa trwałość danych z Docker volumes?

Question

Accepted Answer

Domyślnie dane w kontenerze są **efemeryczne** — tracone quando kontener jest usuwany. **Volumes** (i bind mounts) zapewniają **trwałe przechowywanie** danych, które przetrwają kontenery, niezbędne dla baz danych i wszystkich danych, które muszą przetrwać ponowne uruchomienia/usunięcia kontenerów.

## Problem: kontenery są efemeryczne

```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 — zarządzane trwałe przechowywanie

```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** to zarządzane przez Docker trwałe przechowywanie (przechowywane na hoście, zarządzane przez Docker) — preferowany sposób na utrwalanie danych. Dane w zamontowanej ścieżce przetrwają nawet jeśli kontener zostanie usunięty.

## Bind mounts — mapowanie katalogu hosta

```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** mapują katalog hosta do kontenera — przydatne do tworzenia aplikacji (edytowanie kodu na hoście, zobaczenie zmian na bieżąco w kontenerze).

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

## Dlaczego to ważne

Rozumienie trwałości danych z volumes jest niezbędne do prawidłowego korzystania z Docker z dowolną aplikacją, która ma dane, dlatego jest to ważna wiedza praktyczna.

Fundamentalny problem — **kontenery są efemeryczne**, z ich warstwą do zapisu usuniętą przy usunięciu, co oznacza, że **dane napisane wewnątrz kontenera są tracone** — jest kluczowym pojęciem: kontenery są przeznaczone do być jednorazowe, więc przechowywanie ważnych danych wewnątrz nich (takich jak pliki bazy danych) powoduje utratę danych quando kontener jest zastępowany. **Volumes** rozwiązują ten problem zapewniając **zarządzane przez Docker trwałe przechowywanie** które istnieje poza cyklem życia kontenera, więc dane (bazy danych, przesyłane pliki, dowolny stan) przetrwają usunięcie i zastąpienie kontenera — niezbędne dla aplikacji stanowych.

Rozumienie **bind mounts** (mapowanie katalogu hosta do kontenera) jest ważne dla **tworzenia aplikacji** (edytowanie kodu na hoście i zobaczenie zmian na bieżąco w kontenerze, bardzo powszechny przepływ pracy dev) i do dzielenia plików hosta.

Znajomość **rozróżnienia** — volumes (zarządzane przez Docker, przenośne, preferowany wybór dla trwałych danych aplikacji takich jak bazy danych) versus bind mounts (specyficzne dla ścieżki hosta, świetne do tworzenia) — prowadzi do wyboru właściwego podejścia.

Ponieważ kontenery są efemeryczne z założenia i większość rzeczywistych aplikacji ma dane, które muszą się utrzymać (szczególnie bazy danych), a volumes są istotnym mechanizmem dla trwałego przechowywania (z bind mounts ważnymi do tworzenia), rozumienie Docker data persistence — problem kontenera efemerycznego, volumes dla trwałych danych, bind mounts do tworzenia, i kiedy używać każdy — jest niezbędną, praktycznie istotną wiedzą Docker, konieczną do prawidłowego uruchamiania aplikacji stanowych i uniknięcia poważnego błędu utraty danych przechowywanych wewnątrz jednorazowych kontenerów.