Containers เปลี่ยนทุกอย่างได้อย่างไร

กลุ่ม DevOps เติบโตมาพร้อมกับ Automation Tools ทั้งหลายในช่วงที่ผ่านมา ทำให้การพัฒนา Application สมัยใหม่ไม่ใช่แค่นั่งเขียน Code แต่ Developer ยังต้องคำนึงถึงการเลือกใช้ Tools และวิธีทำงานร่วมกันเพื่อสร้าง Application

Container เป็นหนึ่งใน Tools ชิ้นสำคัญสำหรับ Workflow โดยเทคโนโลยี Container อย่าง Docker ทำให้เราสามารถจับเอาพวก Key Service จาก Infrastructure ออกมาใช้งานได้ นับว่าฉีกแนวความคิดเรื่องการ Deploy Application และการใช้ประโยชน์จาก Cloud Infrestructure ไปอย่างสิ้นเชิง

เมื่อ Infrastructure ใหม่ถูก Deploy และทดสอบเรียบร้อยแล้ว แค่เปลี่ยน DNS ก็ย้ายมาใช้งานได้ทันที วิธีการนี้จะทำให้สามารถเก็บ Virtual Infrastructure ตัวเก่าไว้เป็น Backup ได้ในช่วงแรก ก่อนจะลบมันทิ้งในภายหลัง

การสร้าง Complete Infrastructre ขึ้นมาเลยอาจฟังดูแปลก แต่เมื่อคำนึงถึงความคุ้มค่าของ Cloud Deployment แล้วก็ไม่แพงไปกว่าการ Deploy Update เฉพาะ Server หรือ Service ที่อาจจะทำงานแค่ระยะหนึ่งเท่านั้น นอกจากนี้การ Deploy ทั้งระบบยังอาจทำให้ OS หรือ ซอฟต์แวร์ได้รับการอัพเดทโดยอัตโนมัติอีกด้วย

การไม่ต้องลงทุนกับ Hardware เราสามารถใช้ Cloud Platform ตัวเดียวกันนี้ในขั้นตอน Dev, Test, และ Production ได้เลย เพียงแค่มี Virtual Network แยกแต่ละ Environment กับ Access Control ยิ่งไปกว่านั้น เรายังสามารถทำงานกับ Production Data ในขั้นตอน Development ได้ด้วยการ Clone Store เมื่อต้องการ Clean Data

 

Container แหล่งบรรจุทุกอย่าง

การบรรจุ Application ลงใน Docker Container ทำให้จัดการและดึงเอาองค์ประกอบหลักๆ ของ Application จาก Infrastructure มาได้ง่ายขึ้น ทั้งยัง Scale Service ได้อย่างอิสระ

วิธีการนี้นำมาซึ่งรูปแบบใหม่ของ DevOps คือ Idempotent Container โดยแทนที่จะสร้าง Aplication หรือ Service แบบสำเร็จ ก็เปลี่ยนมาเป็นการสร้าง Container ที่เก็บรวม Application, Service, และทุกสิ่งทุกอย่างที่ต้องใช้ในการรัน Application เข้าไว้ด้วยกัน เมื่อไหร่ก็ตามที่นึกอยากจะเปลี่ยนแปลงส่วนใดส่วนหนึ่ง ก็สร้าง Container ขึ้นมาใหม่ ทดสอบ และ Deploy ในฐานะที่เป็นทั้ง Application ไม่ใช่แค่องค์ประกอบชิ้นหนึ่ง การทำแบบนี้ช่วยลดความเสี่ยงของขั้นตอน Development ได้ ต่างจากวิธีการแบบดั้งเดิมที่จะทดสอบแค่ส่วนที่มีการเปลี่ยนแปลง

เมื่อ Container ถูกสร้างและ Deploy ขึ้นมาแล้ว จะไม่มีการเปลี่ยนแปลงอะไรจนกว่า Container อันใหม่จะถูก Deploy เพราะ Container เองก็เป็น Sandbox อย่างหนึ่ง การจะเข้าถึงและจัดการ Content ภายในจึงต้องทำผ่าน API เท่านั้น ส่วนในกรณีของ End-User ก็ต้องใช้บริการ UI ทำให้ Container เป็นรูปแบบในอุดมคติสำหรับ Microservice ที่ใช้ API เป็นแค่สื่อกลางการใช้งาน และด้วยบทบาทของ API ซึ่งเป็นเหมือนข้อตกลงระหว่างทีม DevOps ดังนั้น Container ที่รันบน Server Instance ขนาดเล็ก เช่น CoreOS หรือ Nano Server ของ Microsoft ก็จะกลายมาเป็น Block หนึ่งของ Infrastructure

 

เป็นไปตามกระแส

ไม่น่าแปลกใจเลยที่ Jenkins กลายเป็น Tool มาตรฐานในขั้นตอนการ Build ได้สร้าง Pipeline Tool ที่รองรับ Docker เพิ่มเข้ามา ลักษณะโครงสร้างที่ปรับแต่งได้ ทำให้สามารถปรับเข้ากับแต่ละ Workflow และทำงานร่วมกับ Source Control Tool รวมทั้ง Development และ Test Platform ได้ง่ายๆ

Kohsuke Kawaguchi ผู้เป็น CTO ของ Cloudbees และ Project Founder ของ Jenkins กล่าวถึงการเพิ่ม Support ของ Docker ว่า “มันช่วยผลักดันความต้องการใช้งาน Jenkins โดยมี Docker ในฐานะ Executable Package Format ให้ Compile และ Package ลงไปใน Binary Blob ที่สามารถนำไปใช้งานได้ทันที และลบทิ้งได้เมื่อไม่ต้องการแล้ว”

เห็นได้ชัดว่า Docker และ Container Format อื่นๆ เข้ากันได้ดีกับวิสัยทัศน์ของ Cloudbee ที่มีต่อ Jenkins “ผู้ใช้สามารถใช้มันสำหรับการ Test หรือ Production ได้ และถ้าล้มเหลว ก็สร้างขึ้นมาใหม่ สามารถ Compile Code ลงใน Module เหมือนกับ Ruby Gem แล้วใส่ลง Container ก่อนจะส่งไปยัง Puppet เพื่ือ Deployment”

ในขณะที่ Docker File Format อยู่ในฐานะภาษาสากลสำหรับโลก Container ทางด้าน Linux Foundation ก็กำลังสนับสนุนการพัฒนา “Open Container Format” ที่มีลักษณะเป็น Common Format ร่วม ดึงเอาเหล่า Container Developer และตัวแทนผู้ให้บริการทั้งหลายมารวมกัน กระทั่งบริษัทอย่าง Microsoft ก็เข้าร่วมด้วย ซึ่ง Common Container Format นี้จะช่วยกระจายการใช้ Container ในกลุ่มผู้ให้บริการ Cloud ทั้ง Public และ Private ให้กว้างขวางยิ่งขึ้น

อย่างไรก็ดี การมี Common Format ของ Container ไม่ได้ช่วยขจัดปัญหาด้านการจัดการ Cloud Infrastructure ที่แตกต่างกันได้ทั้งหมด แต่อย่างน้อยมันก็พอจะช่วยให้การย้าย Service ระหว่าง Cloud สะดวกขึ้น เช่น การย้ายจาก Azure ไปยัง AWS หรือ จาก OpenStack ไปยัง Google Cloud เป็นต้น ส่วน Infrasturcture ที่ถูกจัดการด้วย Puppet หรือ Chef ในระบบคลังของ Git ก็ช่วยให้พัฒนา Translation Layer ที่ใช้ Generic VM และ Network Description สำหรับ Application ได้ และมี Orchestration ที่เหมาะสม ไม่ว่าจะใช้บริการ Cloud แบบไหนอยู่ก็ตาม