ช่วงหลังเราได้ยินชื่ออย่าง Docker, Container, Kubernetes, Orchestration กันบ่อยขึ้นมาก โดย Blognone เองก็เคยนำเสนอข่าวในหัวข้อเหล่านี้อยู่บ่อยครั้ง แต่ก็ยังมีความสับสนในเรื่องนี้อยู่มาก เพราะเป็นแนวคิดที่ยังค่อนข้างใหม่และมีความแตกต่างจากระบบเซิร์ฟเวอร์แบบเดิมๆ สูง
บทความชุดนี้จึงมีเป้าหมายเพื่ออธิบายและทำความเข้าใจกับแนวคิดเหล่านี้ ใครที่รู้เรื่องนี้ดีอยู่แล้วสามารถข้ามไปได้เลยครับ
Virtualization มีข้อจำกัด
คำว่า "คอนเทนเนอร์" (container) เป็นเทคนิคการจัดการแพ็กเกจซอฟต์แวร์ประเภทหนึ่ง ที่มีความสัมพันธ์กับเทคนิค virtualization ที่อยู่ในโลกองค์กรมานาน ดังนั้นการอธิบายว่าคอนเทนเนอร์คืออะไร จึงมักถูกเปรียบเทียบว่าแตกต่างกับ virtualization อย่างไร
เทคนิค virtualization คือการสร้างคอมพิวเตอร์เสมือน (virtual machine หรือ VM) ที่มีทั้งซีพียู แรม สตอเรจ ระบบปฏิบัติการ ฯลฯ ขึ้นมารันบนคอมพิวเตอร์จริงๆ อีกทีหนึ่ง โดยตัวระบบปฏิบัติการของคอมพิวเตอร์เสมือน (Guest OS) จะไม่รู้ว่าตัวเองรันอยู่บน VM แต่เข้าใจว่ารันอยู่บนฮาร์ดแวร์คอมพิวเตอร์จริงๆ
วิธีการนี้ทำให้เกิดการแยกส่วน (isolation) ระหว่าง VM แต่ละตัวอย่างสมบูรณ์ สามารถรันระบบปฏิบัติการที่แตกต่างกันระหว่าง Guest OS กับ Host OS ได้ แต่ข้อเสียคือใช้ทรัพยากรซ้ำซ้อน ทำงานช้า เปลืองพื้นที่เก็บ OS และซอฟต์แวร์ต่างๆ ที่มักจะใช้เหมือนกันใน VM ทุกตัว
ภาพประกอบจาก Docker
Container สร้างมาเพื่อแก้ไขข้อจำกัดของ Virtualization
คอนเทนเนอร์จึงถูกสร้างขึ้นมาเพื่อแก้ปัญหาข้างต้น โดยมีฮาร์ดแวร์และ OS เพียงชุดเดียวกัน ลดความซ้ำซ้อนของการใช้ทรัพยากรลง ส่วนตัวแอพพลิเคชันและซอฟต์แวร์ซึ่งเป็นจุดที่แตกต่างกันไปก็จะมี "container" (เทียบได้กับ VM) มาครอบเพื่อแบ่งส่วนทรัพยากรไว้ไม่ให้ยุ่งกัน
จุดเด่นของคอนเทนเนอร์จึงเป็นเรื่องการใช้ทรัพยากรที่น้อยกว่า virtualization มาก อิมเมจของคอนเทนเนอร์อาจมีขนาดเพียงกี่ไม่กี่สิบ MB ในขณะที่อิมเมจของ VM ต้องใช้พื้นที่ระดับหลาย GB นอกจากนี้ ระยะเวลาที่ใช้บูต, พลังซีพียูและปริมาณแรมที่ต้องใช้ ก็ลดลงตามไปด้วย ส่งผลให้เซิร์ฟเวอร์หนึ่งเครื่องสามารถยัดคอนเทนเนอร์จำนวนมากกว่าการรัน VM ที่ให้ผลแบบเดียวกันถึง 2-3 เท่าตัว
บางครั้ง คอนเทนเนอร์ถูกเรียกชื่อในทางเทคนิคว่า Operating-system-level virtualization หรือการสร้าง VM ที่ระดับ OS โดยเราไม่ต้องสร้างเครื่องคอมพิวเตอร์เสมือนขึ้นมาทั้งตัว
ข้อเสียของคอนเทนเนอร์ก็ย่อมเป็นความยืดหยุ่นที่น้อยกว่า virtualization แบบดั้งเดิม โดยเฉพาะไม่สามารถใช้ OS ที่แตกต่างกันระหว่าง Guest และ Host ได้ (เพราะจุดเด่นของคอนเทนเนอร์คือการแชร์ OS ก็อปปี้เดียวกัน)
ภาพจาก Docker
ประวัติย่อของ Container
แนวคิดของคอนเทนเนอร์ไม่ใช่เรื่องใหม่ ในโลกของยูนิกซ์เกิดแนวคิดนี้ขึ้นมาตั้งแต่ปี 2000 จากแนวคิด jails ของ FreeBSD จากนั้นในปี 2004 ระบบปฏิบัติการ Solaris ของบริษัท Sun Microsystems ก็มีฟีเจอร์แบบเดียวกันโดยใช้ชื่อว่า Zones (หรือ Solaris Containers) ฝั่งลินุกซ์เองก็นำไอเดียนี้มาสืบสานต่อในโครงการอย่าง OpenVZ หรือ LXC (Linux Containers)
แต่คอนเทนเนอร์กลายมาเป็นเรื่องแพร่หลายในวงกว้างจาก Docker ที่เริ่มต้นในปี 2013 ซึ่งช่วงแรกยังอิงอยู่บนโครงการยุคก่อนหน้าอย่าง LXC หรือ libvirt แต่ภายหลัง Docker ก็พัฒนาส่วนต่างๆ ขึ้นมาเอง (libcontainer) จนสมบูรณ์พร้อมใช้งาน ทำให้แนวคิดคอนเทนเนอร์ "จุดติด" และได้รับการยอมรับในวงการอย่างรวดเร็ว มีตัวอย่างการใช้งานจากบริษัทใหญ่ๆ อย่างกูเกิล ที่เปลี่ยนระบบภายในมาใช้คอนเทนเนอร์เกือบทั้งหมดภายในปี 2014 และพัฒนาฟีเจอร์ของ Google Compute Engine ให้รองรับอย่างรวดเร็ว
ถึงแม้ Docker จะถูกสร้างขึ้นมาเพื่อลินุกซ์ แต่ความนิยมของมันทำให้ระบบปฏิบัติการฝั่งวินโดวส์ ทำให้ไมโครซอฟท์เข้ามาร่วมวงตั้งแต่ปี 2014 และสำเร็จลุล่วงใน Windows Server 2016
ความสำเร็จของ Docker ทำให้เกิดคู่แข่งขึ้นบ้าง เช่น Rocket หรือ rkt ของบริษัท CoreOS (ปัจจุบันถูก Red Hat ซื้อไปแล้ว) ทำให้โลกคอนเทนเนอร์แยกออกเป็นสองส่วน แต่ภายหลังก็หาทางออกได้ ด้วยการออกมาตรฐานกลางภายใต้การดูแลของ Open Container Initiative (OCI) (ภายหลังยังพัฒนาต่อมาเป็นโครงการ containerd และ runc ซึ่งจะไม่กล่าวถึงในที่นี้)
ภาพจาก Docker
ตัวอย่างการใช้งาน Container
รูปแบบการนำคอนเทนเนอร์ไปใช้งานมีหลากหลาย แต่ที่พบบ่อยคือการนำแอพพลิเคชันองค์กรในแบบเดิมๆ (ซึ่งมักเป็นแอพที่เขียนด้วยเทคโนโลยียุคก่อนอย่าง Java, .NET หรือ PHP) มาใส่ไว้ในคอนเทนเนอร์ เพื่อมารันบนโครงสร้างพื้นฐานยุคใหม่ที่เป็นคลาวด์ แทนที่การใช้เซิร์ฟเวอร์แบบดั้งเดิมที่เริ่มล้าสมัย ช่วยให้การย้ายขึ้นคลาวด์ราบรื่นกว่าเดิม
นอกจากนี้ เทคโนโลยีคอนเทนเนอร์ยังช่วยแก้ปัญหาเรื่อง system dependency ระหว่างแอพแต่ละเวอร์ชัน แต่ละสถานะ (เช่น dev/test/production) เพราะทุกอย่างที่จำเป็นถูกรวมมาในอิมเมจให้หมดแล้ว มันจึงมีประโยชน์ในแง่กระบวนการเปลี่ยนโค้ดที่เขียน ไปสู่การดีพลอยใช้งานจริงบนเซิร์ฟเวอร์ปลายทาง หรือที่เราเรียกกันว่า CI/CD อีกด้วย
การใช้งานคอนเทนเนอร์อีกแบบหนึ่งที่พบบ่อยในช่วงหลัง คือการแยกแอพพลิเคชันยุคเดิมที่เขียนมาเป็นก้อนใหญ่ๆ (monolithic) ให้กลายเป็นไมโครเซอร์วิส (microservice) ที่มีขนาดเล็กลง จัดการได้สะดวกขึ้น สามารถสเกลเซอร์วิสบางตัวหากต้องการรับโหลดมากขึ้น
การนำคอนเทนเนอร์ของแอพพลิเคชันที่แยกเป็นไมโครเซอร์วิส ไปรันบนโครงสร้างพื้นฐานยุคคลาวด์ที่สเกลตัวเองได้ง่ายขึ้น จึงมีความซับซ้อนสูงตามไปด้วย และกลายเป็นหน้าที่ของซอฟต์แวร์ที่เรียกว่า orchestration (เหมือนวาทยากรนำวงออเคสตร้า) อย่าง Kubernetes หรือ Apache Mesos ที่จะกล่าวถึงในบทความตอนต่อไป
ข้อมูลอ้างอิงจาก
