รูปปกบทความ

1. 🎯 ตอนที่ 2: สถาปัตยกรรมของ Docker ทำงานอย่างไร?

สวัสดีครับน้องๆ กลับมาจิบกาแฟคุยเรื่องระบบ Infra กันต่อกับซีรีส์ Docker หลังจากตอนที่แล้วเราเห็นภาพรวมกันไปแล้วว่า Docker เข้ามาช่วยแก้ปัญหา “It works on my machine” ได้ยังไง วันนี้พี่จะพามาเจาะลึกถึง “เครื่องใน” ของมันกันบ้างครับ

2. 📖 เปิดฉาก (The Hook)

เคยสงสัยไหมครับว่า เวลาที่เราพิมพ์คำสั่งวิเศษอย่าง docker run ลงไปใน Terminal แล้วจู่ๆ แอปพลิเคชันของเราก็เด้งขึ้นมาทำงานได้เลยในเสี้ยววินาที… เบื้องหลังมันเกิดอะไรขึ้นบ้าง? มันมีเวทมนตร์อะไรซ่อนอยู่?

ความจริงแล้วมันไม่ใช่เวทมนตร์หรอกครับ แต่เป็นสถาปัตยกรรมซอฟต์แวร์แบบ Client-Server Architecture ที่ถูกออกแบบมาอย่างแยบยลและชาญฉลาดมาก การเข้าใจกลไกนี้จะเปลี่ยนมุมมองของเราจากการเป็นแค่ “ผู้ใช้งาน” (User) ให้กลายเป็น “ผู้ควบคุมระบบ” (Architect) ที่สามารถแก้ปัญหาเวลาเซิร์ฟเวอร์ดื้อรั้นได้อย่างตรงจุดครับ!

3. 🧠 แก่นวิชา (Core Concepts)

เพื่อให้เห็นภาพง่ายที่สุด พี่ขอเปรียบเทียบสถาปัตยกรรมของ Docker เป็น “ร้านอาหารระดับมิชลินสตาร์” ก็แล้วกันครับ โดยมีองค์ประกอบหลัก 4 ส่วนที่ทำงานประสานกันดังนี้:

  • 1. Docker Client (พนักงานรับออเดอร์): นี่คือส่วนที่เราโต้ตอบด้วยโดยตรงครับ เมื่อเราพิมพ์คำสั่ง (เช่น docker build, docker pull, docker run) ลงใน Terminal ตัว Client จะทำหน้าที่รับคำสั่งเหล่านั้น แล้วส่งต่อไปยังหลังร้านผ่านช่องทางที่เรียกว่า REST API
  • 2. Docker Daemon (พ่อครัวใหญ่ในห้องครัว): หรือบางครั้งเราเรียกว่า Docker Engine (ตัวเซิร์ฟเวอร์ dockerd) ทำหน้าที่รับออเดอร์จาก Client แล้วลงมือทำอาหารครับ Daemon เป็นโปรเซสที่รันอยู่เป็น Background มีหน้าที่จัดการของหนักๆ ทั้งหมด ไม่ว่าจะเป็นการสร้าง Image, การรัน Container, การจัดการ Network, หรือการจอง Volume เพื่อเก็บข้อมูล
  • 3. Docker Registry (ตลาดสดค้าส่ง / ซัพพลายเออร์): เวลาที่พ่อครัว (Daemon) จะทำอาหารแต่พบว่า “วัตถุดิบไม่มีในตู้เย็น” (ไม่มี Image ในเครื่อง) เขาจะวิ่งไปหาซัพพลายเออร์เพื่อดาวน์โหลดวัตถุดิบนั้นมา ซึ่งก็คือ Docker Registry นั่นเองครับ ตัวที่ดังที่สุดและเป็นค่าเริ่มต้นคือ Docker Hub ที่เปรียบเสมือนตลาดสดสาธารณะขนาดใหญ่ที่มี Image พร้อมใช้งานนับล้านตัว (เราสามารถทำ Private Registry ใช้เองในบริษัทได้ด้วยนะ)
  • 4. Docker Desktop (ร้านอาหารแฟรนไชส์แบบพร้อมเปิด): เนื่องจาก Docker Daemon ต้องอาศัยฟีเจอร์เฉพาะของ Linux Kernel (เช่น Namespaces และ Cgroups) ในการสร้าง Container แต่สำหรับคนที่ใช้ Mac หรือ Windows ทาง Docker จึงสร้าง “Docker Desktop” ขึ้นมา ซึ่งมันจะแอบจำลอง Linux Virtual Machine (VM) ขนาดเล็กจิ๋วไว้หลังบ้านให้เราอัตโนมัติ ทำให้เราสามารถรัน Linux Container บนเครื่อง Mac/Windows ของเราได้อย่างแนบเนียน และมีหน้าตา GUI (Dashboard) สวยๆ ให้คลิกจัดการได้ง่ายๆ ครับ

สรุป Flow การทำงาน (The Lifecycle): เมื่อเราสั่ง docker run ubuntu -> Client รับคำสั่ง -> ส่ง API ไปหา Daemon -> Daemon เช็กว่ามี Image ชื่อ ubuntu ในเครื่องไหม? -> ถ้าไม่มี จะไปดาวน์โหลด (Pull) มาจาก Docker Hub -> จากนั้น Daemon จะนำ Image นั้นมาติดเครื่องยนต์และรันขึ้นมาเป็น Container ให้เราครับ

รูปประกอบ Architecture ของ Docker

4. 💻 ร่ายมนต์คำสั่ง (Show me the Code/Commands)

เรามาดูคำสั่งที่ใช้ตรวจสอบ “เครื่องใน” ของ Docker กันครับ ลองเปิด Terminal แล้วพิมพ์คำสั่งนี้ดู:

# ตรวจสอบเวอร์ชันและส่วนประกอบของ Docker ที่ติดตั้งอยู่
docker version

อธิบายคอมเมนต์สไตล์พี่สอนน้อง: เวลาเรารันคำสั่งนี้ สังเกตดีๆ นะครับว่าผลลัพธ์มันจะแบ่งออกเป็น 2 ก้อนหลักๆ คือ Client และ Server

Client: Docker Engine - Community
 Version:           24.0.5     <-- นี่คือเวอร์ชันของพนักงานรับออเดอร์ (CLI)
 API version:       1.43
 ...

Server: Docker Desktop         <-- นี่คือเวอร์ชันของพ่อครัว (Daemon/Engine)
 Engine:
  Version:          24.0.5
  API version:      1.43 (minimum version 1.12)
  OS/Arch:          linux/amd64 <-- สังเกตตรงนี้! แม้พี่จะรันบน Mac/Windows แต่มันรันเซิร์ฟเวอร์บน Linux VM ครับ

ถ้าใครรันแล้วเจอก้อน Client แต่ก้อน Server ฟ้องว่า Cannot connect to the Docker daemon… แปลว่าพ่อครัวยังไม่มาทำงาน (ลืมเปิดโปรแกรม Docker Desktop หรือ Service Docker ดับอยู่) นั่นเองครับ!

5. 🛡️ เคล็ดลับจากคัมภีร์ลับ (Under the Hood / Pro-Tips)

พอเราเข้าใจสถาปัตยกรรมแบบ Client-Server แล้ว พี่มีข้อควรระวังระดับ Pro-Tip มาฝากครับ:

  • ระวังช่องโหว่ความปลอดภัย (Docker Socket Exposure): ตัว Docker Daemon มักจะต้องการสิทธิ์ระดับ root ในการทำงาน และมันสื่อสารกับ Client ผ่าน UNIX Socket ที่ชื่อว่า /var/run/docker.sock … ในการทำ CI/CD เรามักจะเผลอ Mount ไฟล์ Socket ตัวนี้เข้าไปใน Container (เพื่อให้รัน Docker-in-Docker ได้) ซึ่งอันตรายมาก! เพราะถ้าแฮกเกอร์เจาะ Container นั้นได้ เขาจะสามารถสั่งงาน Docker Daemon ตัวหลักที่รันด้วยสิทธิ์ root บน Host ได้เลย (Privilege Escalation) ต้องระวังเรื่อง Permission ให้ดีครับ
  • Daemonless (ความรู้ระดับลึก): ในเวอร์ชันใหม่ๆ สถาปัตยกรรมของ Docker ถูกหั่นให้แยกส่วนกันมากขึ้น (Modular) โดย Daemon จะโยนงานการสร้างและคุม Container ไปให้เครื่องมือย่อยอย่าง containerd และ runc ทำแทน ประโยชน์คือ ต่อให้ตัว Docker Daemon ดับหรือต้อง Restart อัปเดตแพตช์… Container ของเราที่รันอยู่ก็จะไม่ดับตามไปด้วยครับ!

6. 🏁 บทสรุป (To be continued…)

การเข้าใจว่า Docker แยกส่วน Client, Daemon และ Registry ออกจากกันอย่างชัดเจน จะช่วยให้เราออกแบบระบบ CI/CD Pipelines หรือสั่งการข้ามเซิร์ฟเวอร์ (Remote Management) ได้อย่างถูกต้องครับ เราสามารถใช้ Client จากโน้ตบุ๊กเรา ไปสั่ง Daemon ที่อยู่บน Cloud Server ให้รันงานได้สบายๆ

ในตอนต่อไป เราจะมาเจาะลึกสิ่งที่เปรียบเสมือน “พิมพ์เขียว” หรือ “สูตรอาหาร” ในการสร้าง Container นั่นคือโลกของ Docker Image และการเขียน Dockerfile ติดตามความสนุกกันต่อใน EP หน้านะครับ!

ต้องการที่ปรึกษาด้านการวางระบบ Infrastructure, DevOps และ CI/CD ให้กับองค์กรของคุณ? ทีมงาน WP Solution พร้อมให้บริการออกแบบและวางระบบ Server/Cloud แบบครบวงจร ดูรายละเอียดบริการของเราได้ที่: www.wpsolution2017.com หรือพูดคุยปรึกษาเบื้องต้นได้ที่ Line: wisit.p