Docker คืออะไร และสถาปัตยกรรมของ Docker
Docker เกิดขึ้นในปี 2013 และเปลี่ยนวิธีที่ทีม software พัฒนา ทดสอบ และ deploy แอปไปตลอดกาล การเข้าใจสถาปัตยกรรมภายในของ Docker จะทำให้คุณใช้งานได้อย่างมีประสิทธิภาพมากขึ้น และแก้ปัญหาได้เมื่อสิ่งต่าง ๆ ไม่เป็นไปตามที่คาด
ภาพจำสำคัญบทนี้
Docker = Client-Server: Client รับคำสั่งจากคุณ → ส่งผ่าน REST API → Daemon จัดการจริง → ดึง/ส่ง image กับ Registry
ส่วนที่ 1
ประวัติ Docker และทำไมมันถึงเปลี่ยนวงการ
Docker เริ่มต้นจากบริษัท dotCloud (ต่อมาเปลี่ยนชื่อเป็น Docker Inc.) และเปิดตัวต่อสาธารณะครั้งแรกในงาน PyCon 2013 โดย Solomon Hykes ในช่วงแรก Docker สร้างขึ้นมาบน LXC (Linux Containers) แต่ต่อมาพัฒนา container runtime ของตัวเองที่ชื่อ libcontainer ก่อนที่ Docker จะเกิดขึ้น การ deploy แอปหมายถึงการตั้งค่า server ด้วยมือ เขียน shell script ที่บอบบาง และหวังว่าสภาพแวดล้อมจะเหมือนกัน Docker เปลี่ยนทั้งหมดนั้นด้วยแนวคิดเดียว คือแพ็กทุกอย่างที่แอปต้องการลงใน image แล้วรันมันเป็น container ได้ทุกที่
- 2013 — Docker เปิดตัวที่ PyCon บน Linux ใช้ LXC เป็น runtime เบื้องหลัง
- 2014 — Docker 1.0 ออก เริ่มใช้ libcontainer แทน LXC เป็น default
- 2015 — Docker Compose และ Docker Swarm เปิดตัว ทีมสามารถ orchestrate multi-container แอปได้
- 2017 — Kubernetes กลายเป็นมาตรฐาน orchestration ที่ Docker รองรับ
- ปัจจุบัน — Docker Desktop กลายเป็นเครื่องมือหลักของนักพัฒนาทั่วโลก
ส่วนที่ 2
Docker Architecture: ภาพรวมทั้งระบบ
Docker ใช้สถาปัตยกรรมแบบ client-server ซึ่งหมายความว่ามีสองส่วนหลักที่ทำงานร่วมกัน คือ Docker Client ที่รับคำสั่งจากผู้ใช้ และ Docker Daemon ที่ทำงานจริง ทั้งสองสื่อสารกันผ่าน REST API โดยอาจอยู่บนเครื่องเดียวกัน (ผ่าน UNIX socket) หรือต่างเครื่องกันผ่าน network ก็ได้ ดู diagram ด้านล่างเพื่อเห็นภาพรวมของทั้งระบบ
Docker Client
คำสั่งที่ผู้ใช้รัน (CLI / Desktop)
- docker build
- docker pull
- docker run
- docker ps
- docker stop
DOCKER_HOST
Docker Daemon (dockerd) จัดการทุกอย่าง
- Docker Daemon
- Images (cached locally)
- Containers (running / stopped)
- Networks & Volumes
Registry
คลังเก็บ Image (Docker Hub / Private)
- Official Images (nginx, node, postgres...)
- Community Images
- Private / Enterprise Images
ส่วนที่ 3
Docker Client: ด่านหน้าที่ผู้ใช้คุยด้วย
Docker Client คือส่วนที่ผู้ใช้โต้ตอบด้วยโดยตรง ไม่ว่าจะเป็น Terminal ที่พิมพ์คำสั่ง docker หรือ Docker Desktop ที่มี GUI เมื่อคุณพิมพ์คำสั่ง docker build หรือ docker run Client จะแปลงคำสั่งนั้นเป็น HTTP request แล้วส่งไปให้ Docker Daemon จัดการ Client ไม่ได้ทำงานเองแต่ทำหน้าที่เป็นล่ามระหว่างผู้ใช้กับ Daemon
ประเด็นที่ 1
docker build — ส่งคำสั่งให้ Daemon อ่าน Dockerfile แล้วสร้าง image ทีละ layer
ประเด็นที่ 2
docker pull — สั่งให้ Daemon ดึง image จาก Registry มาเก็บใน cache ในเครื่อง
ประเด็นที่ 3
docker run — สั่งให้ Daemon สร้าง container จาก image แล้วเริ่มรัน process
ส่วนที่ 4
Docker Daemon (dockerd): หัวใจของทั้งระบบ
Docker Daemon หรือ dockerd คือ background process ที่รับคำสั่งจาก Client แล้วดำเนินการจริง Daemon รับผิดชอบทุกอย่าง ตั้งแต่การ build image, จัดการ container lifecycle, สร้าง network, จัดการ volume จนถึงการดึงและ push image กับ Registry Daemon ฟัง REST API request อยู่ที่ UNIX socket /var/run/docker.sock โดย default ซึ่ง Client ใช้เชื่อมต่อ
- รับ REST API request จาก Docker Client และ execute ตามคำสั่ง
- จัดการ container lifecycle: create, start, stop, restart, remove
- build image จาก Dockerfile ทีละ layer และ cache ไว้เพื่อ reuse
- สื่อสารกับ Registry เพื่อ push และ pull image
- จัดการ network: สร้าง virtual network, กำหนด IP, routing ระหว่าง container
- จัดการ volume: เชื่อมต่อพื้นที่เก็บข้อมูลถาวรกับ container
ส่วนที่ 5
Objects ใน Docker ที่ต้องรู้จัก
Docker มี objects หลายประเภทที่ Daemon จัดการ แต่ละอย่างมีบทบาทชัดเจนในระบบ ทำความเข้าใจทั้ง 5 อย่างนี้แล้วคุณจะเห็นภาพว่า Docker ประกอบกันอย่างไร
ประเด็นที่ 1
Image — blueprint ที่ไม่เปลี่ยนแปลง สร้างจาก Dockerfile ใช้สร้าง container ได้ไม่จำกัดครั้ง
ประเด็นที่ 2
Container — instance ที่รันจาก image มี writable layer เป็นของตัวเอง แยกจาก container อื่น
ประเด็นที่ 3
Network — virtual network ที่ container ใช้สื่อสารกัน รองรับหลาย driver เช่น bridge, host, overlay
ประเด็นที่ 4
Volume — พื้นที่เก็บข้อมูลถาวรที่ Docker จัดการ แยกออกจาก container filesystem ข้อมูลไม่หายเมื่อ container ถูกลบ
ประเด็นที่ 5
Plugin — ส่วนขยายที่เพิ่มความสามารถให้ Docker เช่น storage driver, network plugin สำหรับ environment พิเศษ
ส่วนที่ 6
Docker Hub: คลังกลาง Official Images
Docker Hub คือ Registry สาธารณะที่ใหญ่ที่สุดในโลก เก็บ image ไว้มากกว่า 8 ล้าน image Docker Hub มี "Official Images" ที่ดูแลโดย Docker และชุมชน ซึ่งผ่านการตรวจสอบความปลอดภัยและมีการอัปเดตสม่ำเสมอ เมื่อคุณพิมพ์ docker pull nginx Docker จะดึง Official Image ของ nginx มาจาก Docker Hub โดยอัตโนมัติ
ประเด็นที่ 1
Official Images — node, nginx, postgres, redis, python, ubuntu ดูแลโดย Docker และ vendor โดยตรง
ประเด็นที่ 2
Verified Publishers — image จากบริษัทที่ Docker รับรอง เช่น Microsoft, AWS, Google
ประเด็นที่ 3
Community Images — image จาก developer ทั่วโลก ต้องตรวจสอบก่อนใช้ใน production
ส่วนที่ 7
เปรียบเทียบ Docker กับ Container Tools อื่น
Docker ไม่ใช่เครื่องมือเดียวในโลก container แต่เป็นที่นิยมและมี ecosystem ใหญ่ที่สุด ตารางนี้ช่วยให้คุณเข้าใจความต่างระหว่าง Docker กับเครื่องมืออื่นเพื่อเลือกใช้ได้เหมาะสม
| หัวข้อ | Docker | Podman | containerd |
|---|---|---|---|
| Architecture | Client-Server (Daemon) | Daemonless (fork/exec) | Low-level runtime ไม่มี CLI |
| Root privilege | Daemon ต้องการ root | Rootless ได้โดย default | ขึ้นอยู่กับ config |
| Docker CLI compat | Native | Compatible (drop-in replacement) | ไม่มี CLI ของตัวเอง |
| Use case หลัก | Dev environment, CI/CD | Security-conscious deployments | Kubernetes runtime (CRI) |
| Compose support | Native Docker Compose | Podman Compose (community) | ไม่รองรับ |
| ความนิยม | สูงมาก ecosystem ใหญ่ | กำลังเติบโต โดยเฉพาะ RHEL | ใช้เบื้องหลัง K8s เป็นหลัก |