กลับไปหน้าบทความ
#Docker#DevOps#คอนเทนเนอร์#การแก้ปัญหา#คู่มือมือใหม่

9 ปัญหา Docker ที่มือใหม่เจอบ่อย พร้อมวิธีเช็กและแก้แบบเร็ว

รวม 9 ปัญหาที่คนเริ่มใช้ Docker มักเจอ ตั้งแต่พอร์ตชน คอนเทนเนอร์เด้ง ไปจนถึง build ช้าและ cache ไม่ทำงาน พร้อมแนวทางไล่เช็กอย่างเป็นระบบและคำสั่งสำคัญที่ควรจำ.

17 มกราคม 2569อ่านประมาณ 3 นาที

แชร์บทความ

9 ปัญหา Docker ที่มือใหม่เจอบ่อย พร้อมวิธีเช็กและแก้แบบเร็ว

Docker ช่วยให้การแพ็กและรันแอปพลิเคชันเป็นมาตรฐานมากขึ้น แต่สำหรับมือใหม่ มักมีปัญหาซ้ำ ๆ ที่ทำให้เสียเวลาโดยไม่จำเป็น บทความนี้รวบรวม 9 ปัญหาที่พบบ่อย พร้อมวิธีไล่เช็กแบบเร็ว เพื่อให้คุณหาต้นตอและแก้ไขได้อย่างเป็นระบบ

1) พอร์ตชน เปิดเว็บไม่ได้ หรือขึ้น bind failed

ปัญหานี้มักเกิดตอนสั่ง docker run หรือ docker compose up แล้วเจอข้อความลักษณะ address already in use หรือเปิด localhost แล้วเข้าไม่ได้

อาการที่พบบ่อย

  • รันคอนเทนเนอร์ไม่ผ่านเพราะพอร์ตถูกใช้งานอยู่แล้ว
  • เปิดหน้าเว็บผ่านพอร์ตที่ตั้งไว้ไม่ได้
  • Docker แจ้ง bind failed

วิธีเช็กเร็ว

  • ใช้ docker ps เพื่อตรวจสอบว่ามีคอนเทนเนอร์ใดกำลังจับพอร์ตนั้นอยู่
  • ใช้ lsof หรือ netstat เพื่อตรวจสอบว่า process ไหนบนเครื่อง host ใช้พอร์ตดังกล่าว

แนวทางแก้ไข

  • เปลี่ยนพอร์ตฝั่ง host เช่นจาก 80:80 เป็น 8080:80
  • หยุด service หรือโปรแกรมที่กำลังใช้พอร์ตชนอยู่
  • หากสื่อสารกันเฉพาะภายในระบบเดียวกัน อาจไม่ต้อง publish port ออกนอกเครื่อง

ข้อแนะนำ ใน Docker Compose หากบริการไม่จำเป็นต้องเข้าจากภายนอก ให้ใช้เฉพาะการสื่อสารภายใน network และหลีกเลี่ยงการเปิดพอร์ตเกินความจำเป็น

2) Image ใหญ่ ดึงช้า ส่งช้า และกินพื้นที่

หลายคนเริ่มต้นจาก image ที่ build ได้ก่อน แล้วค่อยพบทีหลังว่าไฟล์ใหญ่เกินไป ทำให้ build, push และ pull ช้าอย่างชัดเจน

อาการที่พบบ่อย

  • เวลา build นานผิดปกติ
  • push/pull image ใช้เวลามาก
  • พื้นที่ในเครื่องลดลงเร็ว

วิธีเช็กเร็ว

  • ใช้ docker images ดูขนาดของแต่ละ image
  • ตรวจสอบว่ามี tag เก่าค้างอยู่จำนวนมากหรือไม่
  • ใช้ docker history <image> เพื่อดูว่า layer ไหนกินพื้นที่มาก

แนวทางแก้ไข

  • เลือก base image แบบ slim หรือ alpine เมื่อเหมาะสมกับงาน
  • ลบ package cache หลังติดตั้ง dependencies
  • แยกขั้นตอน build และ runtime ด้วย multi-stage build

ข้อแนะนำ อย่าใส่สิ่งที่ไม่จำเป็นต่อการรันจริง เช่นไฟล์ build ชั่วคราว เครื่องมือคอมไพล์ หรือไฟล์แคช ลงไปใน image สุดท้าย

3) คอนเทนเนอร์เด้ง รีสตาร์ทวน หรือหายไปทันที

คอนเทนเนอร์ที่ขึ้นมาแค่ชั่วครู่แล้วหาย มักทำให้สับสน โดยเฉพาะเมื่อ docker ps แทบไม่ทันเห็น

อาการที่พบบ่อย

  • คอนเทนเนอร์ขึ้นมาแล้วหายไปทันที
  • สถานะเป็น restarting
  • แอปไม่พร้อมใช้งานแม้คำสั่งรันดูเหมือนปกติ

วิธีเช็กเร็ว

  • ใช้ docker logs <container> เพื่อดูบรรทัดท้าย ๆ ของการทำงาน
  • ใช้ docker inspect <container> เพื่อตรวจสอบ exit code และ command ที่ถูกเรียก

สาเหตุที่พบได้บ่อย

  • แอปทำงานเสร็จแล้วจบ process หลัก
  • ตัวแปร environment ไม่ครบ
  • เชื่อมต่อฐานข้อมูลหรือ service อื่นไม่ได้

แนวทางแก้ไข

  • ตรวจสอบว่ามี process หลักที่รันค้างไว้จริง
  • เช็กค่า env ให้ครบและถูกต้อง
  • ทดสอบการเชื่อมต่อไปยัง DB หรือ service ปลายทาง

ข้อแนะนำ ตอนดีบักควรรันแบบ interactive หรือเข้า shell ในคอนเทนเนอร์เพื่อสำรวจไฟล์ พาธ และค่าคอนฟิกโดยตรง

4) Disk เต็ม ทั้งที่ไม่ได้ติดตั้งอะไรเพิ่ม

Docker สามารถสะสม image, volume, build cache และ logs ได้มากกว่าที่คิด จนสุดท้ายพื้นที่หมดแบบไม่รู้ตัว

อาการที่พบบ่อย

  • ขึ้น no space left on device
  • build ไม่ผ่านเพราะพื้นที่ไม่พอ
  • ฐานข้อมูลหรือแอปในคอนเทนเนอร์เขียนข้อมูลไม่ได้

วิธีเช็กเร็ว

  • ใช้ docker system df เพื่อดูว่าพื้นที่ไปอยู่ในส่วนใดบ้าง เช่น images, containers, volumes หรือ build cache

แนวทางแก้ไข

  • ใช้ docker system prune เพื่อล้างทรัพยากรที่ไม่ได้ใช้งาน
  • ตรวจสอบ volume เก่าที่ไม่จำเป็น
  • ลด build cache ที่สะสมเกินจำเป็น
  • ตั้งค่า log rotation เพื่อไม่ให้ log โตจนกิน disk

ข้อควรระวัง การล้างข้อมูลด้วยคำสั่ง prune อาจกระทบข้อมูลสำคัญ ควรตรวจสอบให้ชัดก่อนทุกครั้ง

5) ปัญหา Permission โดยเฉพาะบน Linux และตอนใช้ Volume

ปัญหา permission เป็นเรื่องที่เจอบ่อยมากเมื่อ mount โฟลเดอร์จาก host เข้า container โดยเฉพาะในงานพัฒนา

อาการที่พบบ่อย

  • permission denied ตอนเขียนไฟล์
  • สร้าง node_modules หรือ virtual environment ไม่ได้
  • การตั้งต้นฐานข้อมูลล้มเหลว

วิธีเช็กเร็ว

  • ตรวจสอบว่าคอนเทนเนอร์รันด้วย user อะไร
  • ตรวจสอบว่าไฟล์หรือโฟลเดอร์บน host เป็นของ user/group ใด
  • เข้าไปดู uid/gid ภายในคอนเทนเนอร์

แนวทางแก้ไข

  • ปรับ owner ของโฟลเดอร์บน host ให้ตรงกับ uid ที่ใช้งานในคอนเทนเนอร์
  • กำหนด user ให้เหมาะสมแทนการใช้ root ตลอดเวลา

ข้อแนะนำ การรันด้วย root อาจสะดวกในช่วงแรก แต่ในงานทีมมักทำให้ permission บน host เพี้ยนและสร้างปัญหาตามมาในระยะยาว

6) Volume สับสน ข้อมูลหาย หรือหายเพราะ mount ผิด

ข้อมูลที่ดูเหมือนหายไป บางครั้งไม่ได้หายจริง แต่เกิดจาก mount คนละ path หรือใช้ volume คนละชนิด

อาการที่พบบ่อย

  • rebuild แล้วข้อมูลไม่อยู่
  • ลบคอนเทนเนอร์แล้วข้อมูลหาย
  • mount path ผิดจนไม่เจอไฟล์ที่ต้องการ

วิธีเช็กเร็ว

  • ใช้ docker volume ls ดูรายการ volumes
  • ใช้ docker volume inspect เพื่อตรวจสอบว่า volume ถูก mount ไปที่ไหน

จุดพลาดยอดนิยม

  • สลับระหว่าง bind mount กับ named volume
  • mount ไปทับโฟลเดอร์ที่มีข้อมูลอยู่ใน image

แนวทางแก้ไข

  • แยก path สำหรับเก็บ data ให้ชัดเจน
  • กำหนด path ให้ตรงกันทุก environment
  • หากต้อง seed ข้อมูลเริ่มต้น ควรทำใน entrypoint และตรวจสอบก่อนว่ามีข้อมูลอยู่แล้วหรือไม่

7) Network ติดต่อกันไม่ได้ ทั้งที่อยู่ใน Compose เดียวกัน

แม้อยู่ในโปรเจกต์เดียวกัน แต่คอนเทนเนอร์ก็อาจคุยกันไม่ได้หากอ้างอิงชื่อผิดหรือไม่ได้อยู่ใน network เดียวกัน

อาการที่พบบ่อย

  • container A หา container B ไม่เจอ
  • ขึ้น connection refused
  • ขึ้น DNS not found

วิธีเช็กเร็ว

  • ใน Compose ให้เรียกกันด้วยชื่อ service ไม่ใช่ localhost
  • ใช้ docker network ls และ docker network inspect ตรวจสอบว่าอยู่เครือข่ายเดียวกันหรือไม่

แนวทางแก้ไข

  • เปิด port เฉพาะบริการที่ต้องเข้าจากภายนอก
  • สำหรับการสื่อสารภายใน ให้ใช้ชื่อ service และ network ภายใน
  • ทดสอบจากในคอนเทนเนอร์ด้วย ping หรือ curl เพื่อแยกว่าเป็นปัญหา DNS, port หรือแอปพลิเคชัน

8) Build ช้า เพราะ context ใหญ่และใช้ cache ไม่คุ้ม

ปัญหานี้เกิดบ่อยมากในโปรเจกต์ที่ส่งไฟล์จำนวนมากเข้า Docker build โดยไม่จำเป็น

อาการที่พบบ่อย

  • แก้โค้ดเพียงเล็กน้อย แต่ build ใหม่เกือบทั้งหมด
  • build ใช้เวลานานทั้งที่ไม่ได้เปลี่ยน dependencies

วิธีเช็กเร็ว

  • ดูบรรทัด Sending build context หากขนาดใหญ่มาก มักเป็นสัญญาณว่ามีไฟล์เกินจำเป็นถูกส่งเข้าไป

แนวทางแก้ไข

  • สร้างไฟล์ .dockerignore เพื่อกันไฟล์ที่ไม่จำเป็น เช่น node_modules, dist, .git, logs
  • จัดลำดับ Dockerfile ให้สิ่งที่เปลี่ยนบ่อยอยู่ท้าย ๆ เช่น copy source code หลังขั้นตอนติดตั้ง dependencies

ข้อแนะนำ การลด build context มักให้ผลลัพธ์ชัดเจนทั้งเรื่องความเร็วและความเสถียรของ cache

9) Cache ไม่ทำงาน หรือเหมือนถูกล้างทุกครั้ง

หากทุกครั้งที่ build ต้องติดตั้ง dependency ใหม่ทั้งหมด แสดงว่าชั้น cache ถูก invalidate บ่อยเกินไป

อาการที่พบบ่อย

  • ทุก build ดูเหมือนเริ่มจากศูนย์
  • ติดตั้ง package ซ้ำตลอด
  • ไม่เห็นข้อความ CACHED ใน log

วิธีเช็กเร็ว

  • ตรวจดู log ของการ build ว่าขั้นตอนไหนถูก reuse cache
  • พิจารณาว่าคำสั่งใดทำให้ layer เปลี่ยนทุกครั้ง

จุดพลาดยอดนิยม

  • ใช้ COPY . . เร็วเกินไป ทำให้เมื่อไฟล์เล็ก ๆ เปลี่ยน cache ทั้งชั้นก็พังตาม

แนวทางแก้ไข

  • COPY เฉพาะไฟล์ lock ก่อน เช่น package-lock.json หรือ poetry.lock
  • ติดตั้ง dependencies ก่อน แล้วค่อย COPY source code ส่วนที่เปลี่ยนบ่อยตามหลัง
  • ใช้ BuildKit และ cache mount สำหรับ package manager เพื่อเร่งความเร็วในการ build

ชุดคำสั่งเช็กเร็วที่ควรจำ

คำสั่งต่อไปนี้เป็นเหมือนชุดพื้นฐานสำหรับไล่ปัญหา Docker ได้แทบทุกวัน

docker ps
docker logs <name>
docker inspect <name>
docker images
docker system df
docker volume ls
docker network ls

แนวทางคิดเวลาเจอปัญหา Docker

เวลาปัญหาเกิดขึ้น ไม่จำเป็นต้องเดาสุ่ม ให้เริ่มจากคำถามพื้นฐานดังนี้

  • ถ้าเข้าแอปไม่ได้ ให้เช็กพอร์ตก่อน
  • ถ้าคอนเทนเนอร์หาย ให้เช็ก logs และ exit code
  • ถ้าพื้นที่หมด ให้ดู docker system df
  • ถ้าเขียนไฟล์ไม่ได้ ให้ดู user, uid/gid และ path ที่ mount
  • ถ้าคุยกันไม่ได้ ให้ตรวจชื่อ service และ network
  • ถ้า build ช้า ให้เช็ก build context และลำดับคำสั่งใน Dockerfile
  • ถ้า cache ไม่มา ให้ดูว่ามีคำสั่งไหน invalidate layer บ่อยเกินไป

สรุป

ปัญหา Docker ที่มือใหม่เจอบ่อย ส่วนใหญ่ไม่ได้ซับซ้อนเกินแก้ แต่ต้องเริ่มจากการเช็กให้ถูกจุด พอร์ตชนต้องไล่จากฝั่ง host คอนเทนเนอร์เด้งต้องดู logs และ exit code พื้นที่เต็มต้องดูการใช้ disk ของ Docker ส่วน permission, volume และ network ต้องระวังเรื่อง path, user และชื่อ service ให้มาก

เมื่อเข้าใจรูปแบบปัญหาเหล่านี้แล้ว การดีบัก Docker จะเร็วขึ้นมาก และช่วยให้คุณทำงานกับคอนเทนเนอร์ได้มั่นใจขึ้นในระยะยาว