ข้อมูลและ Volumes

ทำไมข้อมูลใน container ถึงหายไป

Container มี writable layer อยู่ด้านบนของ image layer ที่เป็น read-only ทุกไฟล์ที่คุณสร้าง แก้ไข หรือลบภายใน container ที่กำลังทำงานอยู่ จะอาศัยอยู่ใน writable layer นั้นเท่านั้น ทันทีที่ container ถูกลบด้วย docker rm layer นั้นก็หายไปอย่างถาวร

นี่เป็นการออกแบบที่ตั้งใจ Container ถูกออกแบบมาให้ไม่มี state (stateless) ใช้แล้วทิ้งได้ และสามารถสร้างขึ้นใหม่ได้เสมอ คุณควรหยุด container ลบทิ้ง แล้วสร้างใหม่จาก image เดิมได้ตลอดเวลา ถ้าข้อมูลของคุณอยู่ภายใน container โมเดลนี้จะล้มเหลว

Image layer (read-only)      ← ฐาน node:22-alpine
Image layer (read-only)      ← COPY ไฟล์แอป
Writable layer (container)   ← เขียนขณะ runtime (หายไปเมื่อ docker rm)

ตัวเลือกการเก็บข้อมูลถาวรทั้งสาม

Docker มีกลไกสามอย่างเพื่อออกจาก writable layer ชั่วคราว:

ตัวเลือก	ข้อมูลอยู่ที่ไหน	จัดการโดย
Named volumes	ไดเรกทอรีที่ Docker จัดการบน host	Docker
Bind mounts	path ใดก็ได้บน filesystem ของ host	คุณ
tmpfs mounts	RAM ของ host เท่านั้น (ไม่เขียนลงดิสก์)	Kernel

แต่ละตัวเลือกมีข้อดีข้อเสียที่แตกต่างกันในเรื่องความสามารถในการพกพา ประสิทธิภาพ และกรณีการใช้งาน โมดูลนี้จะพาคุณผ่านทีละตัวเลือก

สาธิตความชั่วคราวของข้อมูล

ก่อนเรียนรู้วิธีเก็บข้อมูลถาวร ควรเห็นปัญหาด้วยตาตัวเองก่อน snippet ด้านล่างจะสร้างไฟล์ภายใน container ลบ container นั้น แล้วรัน container ใหม่ — ไฟล์หายไปแล้ว

# Run a container and write a file
docker run --name ephemeral-demo alpine sh -c "echo 'hello world' > /data/message.txt && cat /data/message.txt"

# Remove the container
docker rm ephemeral-demo

# Start a brand-new container from the same image
docker run --rm alpine sh -c "cat /data/message.txt 2>/dev/null || echo 'File is gone!'"

เนื้อหาที่ครอบคลุมในโมดูลนี้

บทเรียน	หัวข้อ
Named Volumes	`docker volume create/ls/inspect/rm` การ mount volumes การจัดเก็บที่ Docker จัดการ
Bind Mounts	การ map host paths เข้า container การแก้ไข source code แบบ live
Volumes vs Bind Mounts	ตารางเปรียบเทียบ ความสามารถในการพกพา ประสิทธิภาพ read-only mounts
Backup & Restore	การ archive volumes ด้วย throwaway container การกู้คืน การย้าย