การ Inspect และตรวจสอบ Docker Image
บทนี้เน้นทักษะระดับกลางในการอ่านข้อมูลเชิงลึกของ image ด้วย docker images, docker inspect, docker history และ filter เพื่อวิเคราะห์ ปรับปรุง และดีบัก image ได้อย่างมั่นใจ
ภาพจำ: เริ่มจาก inventory แล้วค่อย inspect/history/filter เพื่อสรุปว่าจะ cleanup, debug หรือ optimize
ภาพจำสำคัญบทนี้
inspect = ดู config เชิงลึก, history = ไล่ layer ย้อนหลัง, filter = หา image เป้าหมายให้เร็ว
Diagram: Local Images → Inspect/History/Filter → Cleanup/Debug/Optimize
ลำดับคิดแบบมืออาชีพคือเริ่มจาก inventory ก่อน แล้วใช้ inspect/history/filter เพื่อสรุปการตัดสินใจว่าจะ cleanup, debug หรือ optimize image จุดไหน
1. Local Images
ดูรายการและขนาดด้วย docker images
2. Inspect/History
อ่าน config และที่มาของแต่ละ layer
3. Filter
กรองกลุ่ม image เพื่อตรวจเร็วขึ้น
4. Decision
ตัดสินใจ cleanup, debug หรือ optimize
ส่วนที่ 1
Step 1: ดูรายการ image ด้วย docker images
เริ่มจากสำรวจ inventory image ในเครื่องของเรา คำสั่ง docker images จะช่วยบอกว่าเรามี image อะไรบ้าง ขนาดเท่าไร และสร้างเมื่อไร ส่วน -a จะรวม intermediate image ที่ถูกใช้ระหว่าง build ด้วย
ใช้คำสั่งนี้เพื่อดูภาพรวมก่อน clean up หรือก่อนวิเคราะห์ขนาด image
| Column | ความหมาย | Use Case จริง |
|---|---|---|
| REPOSITORY | ชื่อ repository ของ image | เช็กว่า image มาจาก repo ไหน |
| TAG | เวอร์ชันหรือ label ของ image | แยก production/dev หรือรุ่น release |
| IMAGE ID | รหัสเฉพาะของ image | อ้างอิง image แบบไม่พึ่งชื่อ tag |
| CREATED | เวลาที่ image ถูกสร้าง | หา image เก่าที่ควรลบ |
| SIZE | ขนาดรวมของ image | หาต้นเหตุที่ทำให้ deploy/pull ช้า |
ส่วนที่ 2
Step 2: เจาะรายละเอียดด้วย docker inspect <image>
docker inspect คืนค่า JSON ขนาดใหญ่ที่อธิบาย metadata และ config ของ image เช่น environment variables, คำสั่งเริ่มต้น, พอร์ตที่เปิด, working directory รวมถึง RootFS/Layers ที่บอกโครงสร้างไฟล์ระบบของ image
ใช้ --format เพื่อตัดข้อมูลเฉพาะจุด ลดการอ่าน JSON ยาว ๆ
ตัวอย่างย่อเฉพาะจุดที่ต้องอ่านเป็นสำหรับงานตรวจสอบ image
ส่วนที่ 3
Step 3: อ่านประวัติ layer ด้วย docker history <image>
docker history ช่วยให้เห็นลำดับการสร้าง layer และคำสั่งที่ใช้สร้างแต่ละชั้น เหมาะมากเวลาจะวิเคราะห์ว่าทำไม image ใหญ่หรือมี layer ไม่จำเป็น
ใช้ --no-trunc เมื่อต้องการเห็นคำสั่งเต็มที่ถูกใช้สร้าง layer
สังเกต CREATED BY เพื่อย้อนว่า layer นี้มาจากคำสั่ง build ใด
- ถ้า layer ใหญ่ผิดปกติ ให้ย้อนดูคำสั่ง RUN/COPY ในช่วงนั้น
- ใช้ข้อมูล history คู่กับ Dockerfile เพื่อ refactor ให้ image เล็กลง
ส่วนที่ 4
Step 4: กรอง image ด้วย docker image ls --filter
เมื่อ image เยอะขึ้น การกรองช่วยลดเวลาในการหา image เป้าหมาย เช่นหา dangling image เพื่อลบ, หาภาพก่อนหรือหลัง image หนึ่ง, หรือกรองตาม label ที่ทีมกำหนดไว้
แต่ละตัวอย่างด้านล่างจับคู่กับ use case ที่พบบ่อยในงานจริง
| Filter | ใช้เมื่อไร | ผลลัพธ์ที่คาดหวัง |
|---|---|---|
| dangling=true | cleanup หลัง build หลายรอบ | เห็น image ไม่มี tag เพื่อพิจารณาลบ |
| label=stage=prod | แยก image ตาม environment | เห็นเฉพาะ image ที่ติด label ตรงเงื่อนไข |
| before=nginx:latest | ไล่หา image รุ่นเก่า | เห็น image ที่เก่ากว่าเป้าหมาย |
| since=node:20-alpine | ไล่ดู image ใหม่หลังจุดอ้างอิง | เห็น image ที่ใหม่กว่าเป้าหมาย |
ส่วนที่ 5
Step 5: ใช้ dive สำรวจ layer แบบ interactive
dive เป็นเครื่องมือเสริมสำหรับเจาะโครงสร้าง layer แบบ interactive ช่วยดูว่าไฟล์ไหนเพิ่มขนาด image มาก, layer ไหนมีการเปลี่ยนแปลงซ้ำซ้อน และช่วยวิเคราะห์ประสิทธิภาพของ Dockerfile ได้ดีมาก
เลือกวิธีติดตั้งตามระบบปฏิบัติการของคุณ แล้วเปิด dive กับ image ที่ต้องการวิเคราะห์
เปิด dive กับ image เป้าหมาย แล้วดูภาพรวม efficiency score
เลื่อนดูแต่ละ layer เพื่อหาไฟล์ที่เพิ่มขนาดมากผิดปกติ
เทียบผลกับ Dockerfile แล้วปรับ RUN/COPY ให้เหมาะสม
build ใหม่และใช้ dive ตรวจซ้ำเพื่อวัดผลการปรับปรุง