คุณ debug และแก้ปัญหา Docker container อย่างไร?

Question

Accepted Answer

การ debug แอปพลิเคชันแบบ container เกี่ยวข้องกับการตรวจสอบ **logs** การเข้าไปยัง **shell ภายใน container** การตรวจสอบ **configuration และ state** และการวินิจฉัยปัญหาที่พบบ่อย (การ crash เครือข่าย ทรัพยากร) การรู้วิธีแก้ปัญหาเป็นทักษะเชิงปฏิบัติที่จำเป็น ## การตรวจสอบ logs และสถานะ ```bash docker ps -a # see container status (running? exited? exit code?) docker logs # view the container's output (stdout/stderr) — start here docker logs -f --tail 100 # follow live, last 100 lines docker inspect # full config/state as JSON (env, mounts, network, etc.) docker events # stream Docker daemon events ``` `docker logs` มักเป็น **ขั้นตอนแรก** — เพราะแสดง output และ error ของแอปพลิเคชัน ส่วน `docker ps -a` เผยให้เห็นว่า container ได้ exit ไปหรือไม่ (และ exit code ของมัน) ## การเข้าไปภายใน container ```bash # run an interactive shell inside a RUNNING container to investigate docker exec -it bash # or sh (alpine) # → inspect files, run commands, check the environment, test connectivity from inside # if the container won't STAY running, override the entrypoint to get a shell docker run -it --entrypoint sh myimage ``` `docker exec -it ... bash` ให้ shell ภายใน container ที่กำลังรันอยู่ — มีค่ามากสำหรับการตรวจสอบไฟล์ ตรวจสอบ environment และทดสอบการเชื่อมต่อจากมุมมองของ container ## ปัญหาที่พบบ่อยและการวินิจฉัย ```text Container EXITS immediately → check `docker logs`; the main process crashed or finished (a container stops when its main process exits) — check CMD/ENTRYPOINT, errors CAN'T CONNECT between containers → check they're on the same network; use service NAMES (not localhost); verify ports; `docker network inspect` PORT not accessible → check -p mapping; the app must listen on 0.0.0.0 (not 127.0.0.1) OUT OF MEMORY / killed → check `docker stats`, resource limits (OOMKilled in inspect) PERMISSION errors → file ownership/user (non-root user vs mounted volume permissions) IMAGE issues → rebuild without cache (--no-cache); check the build context/.dockerignore ``` ## ทำไมจึงสำคัญ การรู้วิธี debug และแก้ปัญหา Docker container เป็นทักษะเชิงปฏิบัติที่จำเป็น เพราะแอปพลิเคชันแบบ container ย่อมมีปัญหาเกิดขึ้นได้เสมอ (การ crash ปัญหาการเชื่อมต่อ ข้อผิดพลาดด้าน configuration) ที่ต้องวินิจฉัย และสภาพแวดล้อมแบบ container ยังเพิ่มชั้นที่ต้องใช้เทคนิคการ debug เฉพาะ ทักษะพื้นฐาน — การตรวจสอบ **logs** (`docker logs` มักเป็นขั้นตอนแรก แสดง output และ error ของแอป) การตรวจสอบ **สถานะ** (`docker ps -a` เผยให้เห็นว่า container exit หรือไม่และเพราะอะไร รวมถึง exit code) และการตรวจสอบ **configuration/state** (`docker inspect`) — เป็นจุดเริ่มต้นในการวินิจฉัยปัญหาส่วนใหญ่ การเข้าไปยัง **shell ภายใน container** (`docker exec -it ... bash`) เป็นเทคนิคที่มีค่ามากสำหรับการตรวจสอบจากมุมมองของ container — ทั้งตรวจสอบไฟล์ ตรวจสอบ environment และทดสอบการเชื่อมต่อ — และการรู้วิธีเข้าไปยัง shell แม้ในกรณีที่ container ไม่ยอมรันค้างไว้ (โดยการ override entrypoint) ช่วยจัดการกรณียุ่งยากได้ การเข้าใจ **ปัญหาที่พบบ่อยและการวินิจฉัย** มีค่าเป็นพิเศษ ได้แก่ container exit ทันที (main process crash หรือทำงานเสร็จ — ตรวจสอบ logs และ CMD/ENTRYPOINT) ปัญหาการเชื่อมต่อระหว่าง container (การเป็นสมาชิกเครือข่าย การใช้ชื่อ service แทน localhost) port ที่เข้าถึงไม่ได้ (การ mapping และจุดพลาดที่พบบ่อยว่าแอปต้อง listen ที่ 0.0.0.0 ไม่ใช่ 127.0.0.1) การถูก kill เพราะ out-of-memory และ permission errors — เหล่านี้คือปัญหาจริงที่เกิดซ้ำ ๆ ซึ่งการรู้วิธีจดจำและแก้ไขช่วยประหยัดเวลาได้มาก เนื่องจากแอปพลิเคชันแบบ container มีปัญหาที่ต้อง debug และเนื่องจากการแก้ปัญหาอย่างมีประสิทธิภาพ (logs, exec เข้า container, inspect และการจดจำรูปแบบความล้มเหลวที่พบบ่อย) จำเป็นต่อการวินิจฉัยและแก้ไข การรู้วิธี debug Docker container จึงเป็นทักษะเชิงปฏิบัติที่จำเป็นและถูกใช้บ่อยสำหรับทุกคนที่รันแอปพลิเคชันแบบ container เป็นสมรรถนะหลักด้านการปฏิบัติงานที่เปลี่ยนปัญหา container ที่น่าหงุดหงิดให้กลายเป็นเรื่องที่แก้ได้