Volumes และ Networking
เก็บข้อมูลไม่ให้หาย และให้คอนเทนเนอร์คุยกัน/เข้าถึงจากภายนอก
ปูพื้นฐาน: Container ถูกออกแบบมาให้ "ลบและสร้างใหม่ได้ตลอดเวลา" แปลว่าถ้าคุณเซฟไฟล์ไว้ใน Container แล้วลบ Container ไฟล์นั้นก็จะหายวับไปกับตา! เราจึงต้องมี Volume มาช่วยเซฟไฟล์ไว้ข้างนอก
ไฟล์ในตัว container เหมือนกระดาษทดที่ฉีกทิ้งเมื่อ container ถูกลบ · Volume เหมือนลิ้นชักถาวรที่ต่อเข้ากับ container ข้อมูลอยู่รอด · network เหมือนสายโทรศัพท์ให้ container คุยกัน
Volumes — เก็บข้อมูลถาวร
ข้อมูลอยู่รอดแม้ลบ container ด้วย volume
ไม่มี volume = ข้อมูลในตัว container หายเมื่อลบ
# named volume — Docker เก็บให้ (เหมาะข้อมูล production เช่น DB)
docker volume create pgdata
docker run -d -v pgdata:/var/lib/postgresql/data postgres
# bind mount — map โฟลเดอร์จากเครื่องเรา (เหมาะ dev แก้โค้ดแล้วเห็นทันที)
docker run -d -v $(pwd)/site:/usr/share/nginx/html nginxNetworking — พอร์ตและการคุยกัน
docker network create appnet # สร้าง network
docker run -d --name db --network appnet postgres
docker run -d --name api --network appnet myapi
# ภายใน appnet: container "api" เรียก "db" ด้วยชื่อ host "db" ได้เลยสรุป Key Takeaways
- ไม่มี volume = ข้อมูลหายเมื่อลบ container · named volume (จริง) vs bind mount (dev)
- -p host:container เปิดพอร์ตสู่ภายนอก · ไม่ใส่ = เข้าจากนอกไม่ได้
- container ใน network เดียวกันเรียกกันด้วยชื่อได้
คำถามที่พบบ่อย
Named volume กับ bind mount เลือกใช้ยังไง
Bind mount (แม็ปโฟลเดอร์เครื่องเรา) = เหมาะกับ dev — แก้โค้ดเห็นผลใน container ทันที ส่วน named volume (Docker จัดการเอง) = เหมาะกับข้อมูลจริงอย่างฐานข้อมูล — performance ดีกว่าและไม่ผูกกับ path ของเครื่องใคร
Container สองตัวคุยกันยังไง
สร้าง network เอง (docker network create mynet) แล้วรันทั้งคู่ด้วย --network mynet จากนั้นเรียกกันด้วย "ชื่อ container" ได้เลย (Docker มี DNS ภายใน) — network default (bridge) ไม่มี DNS ชื่อ จึงควรสร้าง network เองเสมอ — นี่คือสิ่งที่ docker compose ทำให้อัตโนมัติ