แนวคิดของ Containerization
Containerization ไม่ใช่แค่เรื่องของ Docker แต่คือแนวคิดที่เปลี่ยนวิธีที่ทีม Dev และ Ops ทำงานร่วมกัน เข้าใจแนวคิดนี้ให้ถ่องแท้ก่อน แล้วทุกส่วนของ Docker จะเชื่อมกันได้เอง
ภาพจำสำคัญบทนี้
Containerization = แพ็กแอปพร้อมทุกอย่างที่ต้องการ แล้วส่งไปรันที่ไหนก็ได้ โดยไม่ต้องตั้งค่าสภาพแวดล้อมใหม่
ส่วนที่ 1
Containerization คืออะไร และปัญหาที่มันแก้
Containerization คือการแพ็กแอปพลิเคชันพร้อม dependency และ configuration ทั้งหมดให้อยู่ในหน่วยที่รันได้อิสระ เรียกว่า container แนวคิดนี้เกิดขึ้นเพื่อแก้ปัญหาเรื้อรังสามอย่างที่ทีม software เจอซ้ำ ๆ และเป็นปัญหาที่เจ็บปวดมากในยุคก่อนที่จะมี container
ประเด็นที่ 1
"Works on My Machine" — โค้ดรันบนเครื่อง dev ได้ดี แต่พอขึ้น server กลับพัง เพราะ OS, library, หรือ config ต่างกัน
ประเด็นที่ 2
Dependency Conflict — แอปหลายตัวต้องการ library เวอร์ชันต่างกัน ติดตั้งบนเครื่องเดียวกันขัดแย้งกัน แก้ปัญหาหนึ่งทำให้อีกอันพัง
ประเด็นที่ 3
Environment Drift — config บน dev, staging, production ค่อย ๆ แตกต่างกันไปเรื่อย ๆ จนหาต้นเหตุบั๊กไม่เจอ
ส่วนที่ 2
แนวคิดหลักใน Containerization
Containerization มีส่วนประกอบหลักห้าอย่างที่ทำงานร่วมกัน ทำความเข้าใจแต่ละอย่างแยกก่อน แล้วจะเห็นว่ามันเชื่อมต่อกันอย่างไรใน lifecycle ถัดไป
ประเด็นที่ 1
Image — แม่พิมพ์ที่แช่แข็งสถานะของแอปไว้ครบถ้วน สร้างครั้งเดียว แจกจ่ายได้ทุกที่ ไม่เปลี่ยนแปลงหลัง build
ประเด็นที่ 2
Container — instance ที่รันจาก image มีพื้นที่แยกของตัวเอง สร้างและทำลายได้ตามต้องการ
ประเด็นที่ 3
Registry — คลังกลางสำหรับเก็บและแจกจ่าย image เช่น Docker Hub, GitHub Container Registry, AWS ECR
ประเด็นที่ 4
Volume — พื้นที่เก็บข้อมูลถาวรที่แชร์กับ container ข้อมูลไม่หายแม้ container จะถูกหยุดหรือลบ
ประเด็นที่ 5
Network — ช่องทางที่ container ใช้สื่อสารกัน และกับโลกภายนอก กำหนดได้ว่า container ไหนคุยกับใครได้บ้าง
ส่วนที่ 3
Lifecycle: จาก Source Code ถึง Running Container
ภาพด้านล่างแสดง flow ที่เกิดขึ้นจริงในทีม ตั้งแต่เขียนโค้ดจนถึงแอปรันอยู่บน server จำ flow นี้ให้ขึ้นใจ แล้วคุณจะรู้ทันทีว่า docker build, push, pull, และ run เชื่อมกันตรงไหน
ส่วนที่ 4
ประโยชน์ต่อทีม Dev และ Ops
Containerization ไม่ได้แค่แก้ปัญหาเทคนิค แต่เปลี่ยนวิธีที่ทีมทำงานร่วมกัน โดยเฉพาะระหว่าง Developer และ Operations ที่เคยมีปัญหาสื่อสารกันมาตลอด
- Environment สม่ำเสมอ — ทีมทุกคนใช้ container เดียวกัน ไม่มี "แต่บนเครื่องฉันรันได้นะ" อีกต่อไป
- Deploy เร็ว — container เริ่มต้นเป็นวินาที ไม่ต้องรอบูต OS หรือตั้งค่า server ใหม่
- Rollback ง่าย — image มี version ชัดเจน ย้อนกลับเวอร์ชันเก่าได้ทันทีโดยไม่กระทบระบบอื่น
- Scale ได้อัตโนมัติ — Kubernetes รัน container เพิ่มลดตามโหลดได้โดยอัตโนมัติ ไม่ต้องตั้งค่าเอง
- Ops ไม่ต้องรู้รายละเอียดแอป — deploy ผ่าน image เดียว ไม่ต้องติดตั้ง dependency หรือตั้งค่าแอปเอง
- CI/CD เชื่อมได้ง่าย — pipeline build image แล้ว push อัตโนมัติทุกครั้งที่ merge code
ส่วนที่ 5
Use Cases จริงในการทำงาน
Containerization ถูกใช้งานในสถานการณ์จริงหลากหลายรูปแบบ สามตัวอย่างนี้คือที่พบบ่อยที่สุดในทีม software ทั่วไป และเป็นจุดเริ่มต้นที่ดีในการเห็นภาพว่า container ช่วยได้จริงอย่างไร
ประเด็นที่ 1
Web Application Deployment — แพ็กแอปพร้อม web server แล้ว deploy ขึ้น cloud ได้ทุก provider โดยไม่ต้องตั้งค่า server ใหม่
ประเด็นที่ 2
Microservices — แต่ละ service อยู่ใน container แยกกัน scale อิสระ ไม่กระทบกัน ทีมทำงานแยกกันได้
ประเด็นที่ 3
CI/CD Pipeline — GitHub Actions หรือ GitLab CI build และ test ใน container เพื่อให้ environment สม่ำเสมอทุก run