Docker ทำงานเบื้องหลังอย่างไร?

Question

Accepted Answer

Docker ใช้ฟีเจอร์ของ Linux kernel — **namespaces** (การแยก isolation) **cgroups** (การควบคุมทรัพยากร) และ **union filesystems** (image แบบ layer) — เพื่อสร้าง container ที่เบา การเข้าใจกลไกเบื้องหลังช่วยอธิบายว่า container บรรลุการแยกและความมีประสิทธิภาพได้อย่างไร

## Namespaces — การแยก isolation

```text
Linux NAMESPACES isolate what a process can SEE — giving each container its own view:
  PID namespace     → its own process tree (container sees only its processes)
  NET namespace     → its own network interfaces, IPs, ports
  MNT namespace     → its own filesystem mounts
  UTS namespace     → its own hostname
  IPC, USER namespaces → isolated IPC, user/group ID mapping
→ Namespaces are WHY a container feels like a separate machine (isolated view),
  while actually sharing the host kernel.
```

## cgroups — การควบคุมทรัพยากร

```text
Control Groups (CGROUPS) LIMIT and account for resource usage per container:
  → CPU, memory, disk I/O, network bandwidth
→ cgroups are WHY you can set resource limits (-m, --cpus) — the kernel enforces them.
```

## Union filesystem — image แบบ layer

```text
UNION/OVERLAY filesystems (overlayfs) stack image LAYERS:
  → read-only image layers + a thin writable container layer on top, merged into one view
  → layers are SHARED between images/containers (one copy on disk) → space-efficient
→ This is WHY images are layered, cached, and shareable, and containers are lightweight.
```

## สถาปัตยกรรม

```text
Docker CLI → Docker DAEMON (dockerd) → containerd → runc (creates containers using
  namespaces + cgroups). The daemon manages images, containers, networks, volumes.
→ Containers are just ISOLATED PROCESSES on the host (not VMs) — using kernel features,
  sharing the host kernel → lightweight and fast.
```

## ทำไมจึงสำคัญ

การเข้าใจว่า Docker ทำงานเบื้องหลังอย่างไรเป็นความรู้ระดับ senior ที่มีคุณค่า เพราะช่วย **ถอดความลึกลับของ container** และอธิบายคุณสมบัติสำคัญของมัน (การแยก ความมีประสิทธิภาพ การควบคุมทรัพยากร) ทำให้สามารถใช้เหตุผล กำหนดค่า และแก้ปัญหาระบบแบบ container ได้ลึกซึ้งขึ้น

ข้อค้นพบสำคัญคือ **container ไม่ใช่ VM — แต่เป็น process ที่ถูกแยกอยู่บน host** โดยใช้ฟีเจอร์ของ Linux kernel ซึ่งเป็นเหตุผลที่มันเบาและรวดเร็ว (ใช้ kernel ของ host ร่วมกันแทนที่จะรัน OS แยกต่างหาก)

การเข้าใจ **กลไกหลักสามอย่าง** อธิบายคุณสมบัติเหล่านี้: **namespaces** แยกสิ่งที่ process มองเห็น (process tree, เครือข่าย, filesystem, hostname ของตัวเอง — ซึ่งเป็น *เหตุผล* ที่ container รู้สึกเหมือนเครื่องแยกต่างหากแม้จะใช้ kernel ร่วมกัน) **cgroups** จำกัดและบันทึกการใช้ทรัพยากร (ซึ่งเป็น *เหตุผล* ที่คุณตั้ง limit ของ CPU และ memory ได้ — kernel เป็นผู้บังคับใช้) และ **union/overlay filesystems** ซ้อน image layers (ซึ่งเป็น *เหตุผล* ที่ image เป็นแบบ layer แคชได้ และแชร์ได้ และ container จึงเบา — layer แบบ read-only ที่แชร์กันระหว่าง container พร้อม layer ที่เขียนได้บาง ๆ อยู่ด้านบน)

การเข้าใจ **สถาปัตยกรรม** (CLI → daemon → containerd → runc โดย daemon จัดการทุกอย่าง) ให้ภาพรวมที่สมบูรณ์ของการทำงานของ Docker

ความเข้าใจที่ลึกขึ้นนี้ช่วยในการใช้เหตุผลเกี่ยวกับขอบเขตการแยก (และนัยด้านความปลอดภัยของมัน เพราะ container ใช้ kernel ร่วมกัน) อธิบายลักษณะด้านประสิทธิภาพและความมีประสิทธิภาพ และช่วยในการแก้ปัญหา

เนื่องจากการเข้าใจกลไกเบื้องหลัง (namespaces, cgroups, union filesystems) อธิบาย *เหตุผล* ที่ container มีพฤติกรรมเช่นนั้น — การแยก ความมีประสิทธิภาพ การควบคุมทรัพยากร และข้อเท็จจริงสำคัญที่ว่ามันใช้ kernel ของ host ร่วมกัน (พร้อมนัยด้านความปลอดภัย) — และทำให้สามารถทำงานกับระบบแบบ container ได้อย่างมั่นใจยิ่งขึ้น การเข้าใจว่า Docker ทำงานเบื้องหลังอย่างไรจึงเป็นความรู้ระดับ senior ที่มีคุณค่าซึ่งยกระดับจากการใช้ Docker ไปสู่การเข้าใจมันอย่างแท้จริง เป็นหัวข้อที่สะท้อนความลึกที่คาดหวังจากบทบาทระดับ senior และมีประโยชน์ต่อการใช้เหตุผลเกี่ยวกับพฤติกรรมของ container ขอบเขตความปลอดภัย และประสิทธิภาพ