Piye cara data persistence bisa gumana karo Docker volumes?

Question

Accepted Answer

Secara default, data ing container iku **ephemeral** — ilang nalika container diilangi. **Volumes** (lan bind mounts) nyedhiyakake **persistent storage** sing urip luwih dawa saka container, penting kanggo database lan data apa wae sing kudu tetep ana nalika container direstart utawa diilangi.

## Problema: container iku ephemeral

```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 — managed persistent storage

```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** iku persistent storage sing dijaga Docker (disimpen ing host, dijaga dening Docker) — cara sing disenengi kanggo tetepake data. Data ing path sing mount terus ana sanajan container diilangi.

## Bind mounts — maapke directory host

```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** maapke directory host menyang container — migunani kanggo development (besut kode ing host, delok owah-owahan langsung ing 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
```

## Apa sing penting

Ngerteni data persistence karo volumes penting banget kanggo nggunakake Docker kanthi bener karo aplikasi apa wae sing duwe data, dadi iku pengetahuan praktis sing penting.

Masalah pokok — **container iku ephemeral**, lapisan writable diilangi nalika diilangi, ateges **data sing ditulis ing container ilang** — iku konsep kritis: container kene kanggo dibuang, dadi nyimpen data penting ing dalam container (kayata file database) nyebabake ilang data nalika container diganti. **Volumes** ngatasi iki kanthi nyedhiyakake **persistent storage sing dijaga Docker** sing ana ing luar siklus urip container, dadi data (database, upload, state apa wae) tetep ana nalika container diilangi lan diganti — penting banget kanggo aplikasi stateful.

Ngerteni **bind mounts** (maapke directory host menyang container) penting kanggo **development** (besut kode ing host lan delok owah-owahan langsung ing container, workflow dev sing umum banget) lan kanggo marengakake file host.

Ngerteni **pembedaan** — volumes (dijaga Docker, portable, pilihan sing disenengi kanggo data aplikasi persistent kayata database) versus bind mounts (spesifik host-path, bagus kanggo development) — nuntun milih cara sing bener.

Amarga container iku ephemeral dening rancangan lan akeh real aplikasi duwe data sing kudu tetep (terutama database), lan amarga volumes iku mekanisme penting kanggo persistent storage (bind mounts penting kanggo development), ngerteni Docker data persistence — masalah ephemeral-container, volumes kanggo data persistent, bind mounts kanggo development, lan kapan nggunakake saben — iku pengetahuan Docker penting, relevan kanthi praktis, perlu kanggo njalanake aplikasi stateful kanthi bener lan ngindari kesalahan serius mbuwang data sing disimpen ing container sing bisa dibuang.