Docker volumes کے ساتھ ڈیٹا persistence کیسے کام کرتا ہے؟

Question

Accepted Answer

ڈیفالٹ طور پر، container میں ڈیٹا **ephemeral** ہوتا ہے — جب container کو ہٹایا جاتا ہے تو ضائع ہو جاتا ہے۔ **Volumes** (اور bind mounts) **persistent storage** فراہم کرتے ہیں جو containers سے زیادہ لمبے عرصے تک رہتی ہے، جو databases اور کسی بھی ڈیٹا کے لیے ضروری ہے جو container کی restarts/removals سے زندہ رہنا ضروری ہے۔

## مسئلہ: containers 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** Docker کی طرف سے managed persistent storage ہیں (host پر محفوظ، Docker کے ذریعے manage کیے جاتے ہیں) — ڈیٹا کو persist کرنے کا ترجیحی طریقہ۔ mounted path میں ڈیٹا اس صورت میں بھی زندہ رہتا ہے اگر container کو ہٹایا جاتا ہے۔

## Bind mounts — host directory کو map کریں

```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** host directory کو container میں map کرتے ہیں — development کے لیے مفید (host پر code کو edit کرنا، container میں changes کو live دیکھنا)۔

## Volumes بمقابلہ 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
```

## اہمیت

Volumes کے ساتھ ڈیٹا persistence کو سمجھنا Docker کے ساتھ صحیح طریقے سے استعمال کرنے کے لیے ضروری ہے کسی بھی application کے لیے جس کے پاس ڈیٹا ہے، لہذا یہ اہم عملی علم ہے۔

بنیادی مسئلہ — **containers ephemeral ہیں**، ان کی writable layer کو removal پر delete کیا جاتا ہے، جس کا مطلب ہے **container کے اندر لکھا ہوا ڈیٹا ضائع ہو جاتا ہے** — یہ ایک اہم تصور ہے: containers disposable ہونے کے لیے بنائے گئے ہیں، لہذا اہم ڈیٹا کو ان کے اندر محفوظ کرنا (جیسے ایک database کی files) container کی replacement پر ڈیٹا کے نقصان کا سبب بنتا ہے۔ **Volumes** اس کو حل کرتے ہیں **Docker-managed persistent storage** فراہم کر کے جو container کے lifecycle سے باہر رہتا ہے، لہذا ڈیٹا (databases، uploads، کوئی بھی state) container کی removal اور replacement سے زندہ رہتا ہے — stateful applications کے لیے ضروری۔

**Bind mounts** کو سمجھنا (host directory کو container میں map کرنا) **development** کے لیے اہم ہے (host پر code کو edit کرنا اور container میں changes کو live دیکھنا، ایک بہت عام dev workflow) اور host files کو share کرنے کے لیے۔

**تمیز** کو جاننا — volumes (Docker-managed، portable، persistent application data کے لیے ترجیح، جیسے databases) بمقابلہ bind mounts (host-path-specific، development کے لیے بہترین) — صحیح approach کا انتخاب کرنے میں رہنمائی دیتا ہے۔

چونکہ containers design کے لحاظ سے ephemeral ہیں اور اکثر real applications کے پاس ڈیٹا ہے جو persist ہونا ضروری ہے (خاص طور پر databases)، اور چونکہ volumes persistent storage کا ضروری mechanism ہیں (bind mounts development کے لیے اہم ہیں)، Docker data persistence کو سمجھنا — ephemeral-container مسئلہ، persistent data کے لیے volumes، development کے لیے bind mounts، اور کب ہر ایک کو استعمال کریں — ضروری ہے، عملی طور پر متعلقہ Docker علم، stateful applications کو صحیح طریقے سے چلانے اور disposable containers کے اندر محفوظ شدہ ڈیٹا کے نقصان کی سنگین غلطی سے بچنے کے لیے ضروری۔