การคงอยู่ของข้อมูล (data persistence) ทำงานอย่างไรกับ Docker volume?

Question

Accepted Answer

โดยค่าเริ่มต้น ข้อมูลใน container เป็นแบบ **ชั่วคราว (ephemeral)** — หายไปเมื่อ container ถูก remove **Volume** (และ bind mount) ให้ **พื้นที่จัดเก็บแบบถาวร (persistent storage)** ที่อยู่ได้นานกว่า container ซึ่งจำเป็นสำหรับฐานข้อมูลและข้อมูลใดๆ ที่ต้องอยู่รอดผ่านการ restart/remove ของ container

## ปัญหา: container เป็นแบบชั่วคราว

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

## Volume — พื้นที่จัดเก็บถาวรที่ Docker จัดการ

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

**Volume** คือพื้นที่จัดเก็บถาวรที่ Docker จัดการ (เก็บไว้บน host และจัดการโดย Docker) — เป็นวิธีที่แนะนำในการ persist ข้อมูล ข้อมูลในเส้นทางที่ mount ไว้จะอยู่รอดแม้ว่า container จะถูก remove

## Bind mount — แมป 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 mount** แมป directory ของ host เข้าไปใน container — มีประโยชน์สำหรับการพัฒนา (แก้ไขโค้ดบน host แล้วเห็นการเปลี่ยนแปลงสดๆ ใน container)

## Volume เทียบกับ bind mount

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

## ทำไมจึงสำคัญ

การเข้าใจการคงอยู่ของข้อมูลด้วย volume เป็นสิ่งจำเป็นต่อการใช้ Docker อย่างถูกต้องกับแอปพลิเคชันใดๆ ที่มีข้อมูล จึงเป็นความรู้ปฏิบัติที่สำคัญ

ประเด็นพื้นฐาน — **container เป็นแบบชั่วคราว** โดย writable layer ของมันถูกลบเมื่อ remove หมายความว่า **ข้อมูลที่เขียนภายใน container จะหายไป** — เป็นแนวคิดสำคัญยิ่ง: container ออกแบบมาให้ใช้แล้วทิ้ง ดังนั้นการเก็บข้อมูลสำคัญไว้ภายใน (เช่นไฟล์ของฐานข้อมูล) ทำให้ข้อมูลสูญหายเมื่อ container ถูกแทนที่ **Volume** แก้ปัญหานี้ด้วยการให้ **พื้นที่จัดเก็บถาวรที่ Docker จัดการ** ซึ่งอยู่นอกวงจรชีวิตของ container เพื่อให้ข้อมูล (ฐานข้อมูล, ไฟล์อัปโหลด, state ใดๆ) อยู่รอดผ่านการ remove และแทนที่ container — จำเป็นสำหรับแอปพลิเคชันแบบ stateful

การเข้าใจ **bind mount** (การแมป directory ของ host เข้าไปใน container) สำคัญต่อการ **พัฒนา** (แก้ไขโค้ดบน host แล้วเห็นการเปลี่ยนแปลงสดๆ ใน container ซึ่งเป็นเวิร์กโฟลว์การพัฒนาที่พบบ่อยมาก) และต่อการแชร์ไฟล์ของ host

การรู้ **ความแตกต่าง** — volume (Docker จัดการ, พกพาได้, เป็นตัวเลือกที่แนะนำสำหรับข้อมูลแอปพลิเคชันที่ต้องคงอยู่ถาวรเช่นฐานข้อมูล) เทียบกับ bind mount (อิงเส้นทางของ host, เหมาะกับการพัฒนา) — ช่วยให้เลือกแนวทางที่ถูกต้อง

เนื่องจาก container เป็นแบบชั่วคราวโดยการออกแบบ และแอปพลิเคชันจริงส่วนใหญ่มีข้อมูลที่ต้องคงอยู่ (โดยเฉพาะฐานข้อมูล) และเนื่องจาก volume เป็นกลไกที่จำเป็นสำหรับพื้นที่จัดเก็บถาวร (โดยมี bind mount ที่สำคัญสำหรับการพัฒนา) การเข้าใจการคงอยู่ของข้อมูลใน Docker — ปัญหา container แบบชั่วคราว, volume สำหรับข้อมูลถาวร, bind mount สำหรับการพัฒนา และเมื่อใดควรใช้แบบไหน — จึงเป็นความรู้ Docker ที่จำเป็นและเกี่ยวข้องในทางปฏิบัติ จำเป็นต่อการรันแอปพลิเคชันแบบ stateful อย่างถูกต้องและหลีกเลี่ยงความผิดพลาดร้ายแรงในการสูญเสียข้อมูลที่เก็บไว้ภายใน container ที่ใช้แล้วทิ้ง