Exec และ Logs

การเปิด shell ใน container ที่กำลังทำงาน

docker exec รัน process ใหม่ ภายใน container ที่กำลังทำงานอยู่ การใช้งานที่พบบ่อยที่สุดคือการเปิด interactive shell:

docker exec -it <container> sh

-i เปิด stdin ไว้ (interactive)
-t จัดสรร pseudo-TTY (เพื่อให้ได้ terminal prompt ที่ใช้งานได้จริง)
sh คือคำสั่งที่จะรัน (ใช้ bash ถ้า image มีติดตั้งมา)

ภายใน shell คุณสามารถตรวจสอบไฟล์, รันคำสั่ง, และ debug ปัญหา — เหมือนกับว่าคุณอยู่บนเครื่อง host

# ตัวอย่าง session
docker run -d --name webserver nginx:alpine
docker exec -it webserver sh

# ภายใน container:
# / # cat /etc/os-release
# / # ls /usr/share/nginx/html
# / # exit

การดู log ของ container

container ทุกตัวเขียน stdout/stderr ไปยัง log ที่ Docker จัดการ:

# แสดง log ทั้งหมดจนถึงปัจจุบัน
docker logs webserver

# ติดตาม (stream) บรรทัด log ใหม่แบบ real time — เหมือน tail -f
docker logs -f webserver

# แสดง 20 บรรทัดล่าสุด
docker logs --tail 20 webserver

# เพิ่ม timestamp
docker logs -t webserver

Log เป็นสิ่งแรกที่ควรดูเมื่อ container ทำงานผิดปกติ ถ้า container รีสตาร์ทซ้ำๆ docker logs <name> มักบอกสาเหตุได้ทันที

การตรวจสอบ process ด้วย `docker top`

docker top แสดงรายการ process ที่กำลังทำงานภายใน container — โดยไม่ต้องเข้าไปข้างใน:

docker top webserver

UID    PID    PPID   C  STIME  TTY  TIME      CMD
root   12345  12300  0  10:00  ?    00:00:00  nginx: master process nginx -g daemon off;
101    12346  12345  0  10:00  ?    00:00:00  nginx: worker process

การรันคำสั่งแบบ one-off

ไม่จำเป็นต้องเปิด shell เต็มรูปแบบเสมอไป docker exec สามารถรันคำสั่งใดก็ได้โดยตรง:

# ตรวจสอบ config ของ nginx
docker exec webserver nginx -t

# ดูไฟล์
docker exec webserver cat /etc/nginx/nginx.conf

# 1. Start nginx in the background
docker run -d --name webserver nginx:alpine

# 2. Check its logs
docker logs webserver

# 3. Run a one-off command inside it
docker exec webserver nginx -t

# 4. Open an interactive shell
#    (type 'exit' when done)
docker exec -it webserver sh

# 5. Watch processes
docker top webserver

# 6. Follow logs in real time (Ctrl+C to stop)
docker logs -f webserver

ข้อแลกเปลี่ยน

ตัวเลือก	Benefit	Cost
`docker exec -it` เข้าไป debug สด	เห็นสถานะจริงทันที แก้ปัญหาเฉพาะหน้าได้เร็ว	ไม่ persist ไม่มี audit trail และลืมง่ายว่าแก้อะไรไปบ้าง
`docker logs` + centralized logging	มี history ย้อนหลัง ค้นหาและแชร์ให้ทีมดูได้	ต้องตั้งค่า logging driver หรือ log aggregator เพิ่ม

ข้อผิดพลาดที่พบบ่อย

ใช้ docker exec เข้าไปแก้ไฟล์ใน container สดๆ แทนที่จะแก้ที่ image หรือ Dockerfile แล้ว build ใหม่ ทำให้การเปลี่ยนแปลงหายไปเมื่อ container ถูกลบ
รีบ docker exec เข้าไป debug ทั้งที่ยังไม่ได้เช็ค docker logs ก่อน ทั้งที่ log มักบอกสาเหตุตรงๆ อยู่แล้ว
พึ่ง docker exec เป็นเครื่องมือ debug หลักแทนการทำ logging/monitoring ที่เหมาะสม ทำให้ debug ได้เฉพาะตอน container ยังไม่ตาย — container ที่ crash แล้วจะ exec เข้าไปไม่ได้อีกต่อไป

💡 ตัวอย่างจากของจริง

kubectl logs และ kubectl exec ของ Kubernetes ทำงานบนแนวคิดเดียวกับ docker logs/docker exec เป๊ะๆ เพียงแต่ orchestrate ระดับ cluster ทีม SRE ที่ debug production มักเริ่มจาก kubectl logs เสมอ แล้วค่อย exec เข้าไปดูเป็นทางเลือกสุดท้าย