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 แบบไหนอยู่ก็ตาม

Mirantis OpenStack ร่วมกับ Apcera สร้างความปลอดภัยให้ Open Source

ในปัจจุบัน Open Source ได้กลายเป็น Software ตัวเลือกแรกที่หลายองค์กรนำไปใช้ในการปฏิบัติการทางคอมพิวเตอร์ เพราะช่วยทำให้ธุรกิจมีความคล่องตัวสูงขึ้นจากการตอบโจทย์ด้าน IT ได้อย่างรวดเร็ว และยังมีค่าใช้จ่ายที่คุ้มค่ามากกว่า Commercial Software แต่ทั้งนี้ Open Source Solution ก็ถูกวิพากษ์วิจารณ์ในเรื่องความปลอดภัยที่ไม่เป็นไปตามข้อเสนอเชิงพาณิชย์ที่เป็นกรรมสิทธิ์

        ดังนั้นเพื่ออุดช่องว่างนี้ บริษัท Apcera ซึ่งเป็นหนึ่งในผู้สนับสนุน Open Source Solution จึงมุ่งหวังที่จะหาข้อแก้ไขด้วยการพัฒนาระบบคลาวด์ให้มีประสิทธิภาพมากขึ้น จนในที่สุดในงาน OpenStack Summit 2015 ณ. เมือง Vancouver ประเทศแคนาดา บริษัท Apcera ได้ประกาศวางจำหน่าย Hybrid Cloud Operating System สำหรับผู้ใช้ Mirantis OpenStack อย่างเป็นทางการ

        โดย Hybrid Cloud Operating System คือ ระบบที่เกิดจากการร่วมมือระหว่าง Apcera กับ Mirantis ที่เป็นผู้เชี่ยวชาญด้าน Cloud OpenStack ผลิตโครงสร้างพื้นฐานแบบ Open Source ให้แก่องค์กรกว่า 200 แห่ง ซึ่งโดย Hybrid Cloud Operating System จะช่วยให้ผู้ใช้ OpenStack ไม่เพียงแต่สามารถเชื่อมต่อกับ Private Cloud ได้เท่านั้น แต่ยังสามารถเชื่อมต่อกับ Public Cloud อื่นๆ อาทิ Amazon Web Services (AWS), Google Compute Engine (GCE), VMware vSphere ได้อย่างปลอดภัยตามนโยบายชอง Apcera

        และข้อดีของระบบนี้นอกจากจะทำให้ผู้ใช้ควบคุมทรัพยากรทั้งได้ดีขึ้น มองเห็นการโต้ตอบของทรัพยากรได้ชัดเจนขึ้น และที่สำคัญคือมีความปลอดภัยในทุกสภาพแวดล้อม ไม่ว่าจะเชื่อต่อกับ Private Cloud หรือ Public Cloud

อ้างอิง : https://www.apcera.com/blog/bringing-security-open-source

สอบ OpenStack Certificate Administrator คืออะไร? ทำไม OpenStacker ต้องสอบ

เรามั่นใจว่าความฝันสูงสุดของ OpenStack Admin หลายคน คือ การมี OpenStack Certificate Administrator หรือที่รู้จักกันในชื่อภาษาไทยว่า “ใบรับรองความสามารถด้านการดูแลระบบ OpenStack” ไว้ในครอบครอง เพราะมันเป็นเสมือนใบเบิกทางที่จะนำพาตัวเองไปสู่หนทางที่ไกลกว่า ซึ่งหลายคนคงรู้วิธีการสมัครสอบ OpenStack Certificate  Administrator  กันอยู่แล้ว ว่าสามารถสมัครสอบได้ที่นี่ และมีค่าใช้จ่ายอยู่ที่ราคา $300 สามารถสอบได้ภายใน 12 เดือนหลังการชำระเงิน ฉะนั้นวันนี้เราจึงจะพาย้อนความกลับไปดูว่าเจ้าใบรับรองที่ใครๆ ก็อยากได้นี่มีความเป็นมาอย่างไร แล้วเมื่อได้มาสามารถนำไปทำอะไรได้บ้าง

ตามเดิม OpenStack Certificate (ใบรับรอง OpenStack) เริ่มต้นมาจากบริษัทยักษ์ใหญ่ อย่าง Mirantis, Red Hat และ Linux ฯลฯ ได้ทำการเปิดคอร์สสอนอบรมความรู้เรื่องการใช้ระบบ OpenStack ขึ้นมาให้บุคคลทั่วไปตลอดจนแอดมินที่ดูแลระบบได้เข้ามาลงทะเบียนเรียนและสอบเอาใบรับรองความเชี่ยวชาญด้าน OpenStack นี้กลับไป แต่มันกลับกลายเป็นมีข้อจำกัดอยู่ตรงที่ว่า เนื้อหาส่วนใหญ่ที่บริษัทเหล่านี้เอามาสอนครอบคลุมอยู่แค่ Platform ของบริษัทนั้นๆ มิใช่แบบ Open Source เพียวๆ ดังนั้นองค์กร OpenStack Foundation ซึ่งเป็นองค์กรหลักผู้พัฒนาซอฟต์แวร์ Cloud Opensource จึงประกาศกลางงาน OpenStack Summit 2016 ณ เมือง Austin นครรัฐ Texas ในเดือนเมษายน ปี 2016 ว่า จะมีการสอบ OpenStack Certificate ของ OpenStack เองอย่างเป็นทางการภายใต้ชื่อ Certified OpenStack Administrator (COA) ด้วยความเล็งเห็นว่า ในปัจจุบันทักษะ OpenStack กำลังเป็นที่ต้องการสูง

“COA is the first professional certification offered by the OpenStack Foundation. It’s designed to help companies identify top talent in the industry, and help job seekers demonstrate their skills.” – (Openstack.org, n.d.)

(COA คือ ครั้งแรกของการรับรองความเป็นผู้เชี่ยวชาญที่ OpenStack Foundation ออกแบบมาเพื่อช่วยให้บริษัทสามารถระบุความสามารถระดับสูงในแวดวงอุตสาหกรรม และช่วยให้ผู้ที่กำลังมองหางานด้าน OpenStack สามารถโชว์ทักษะของตนได้)

นั่นจึงหมายความว่าบุคคลทั่วไปที่สอบ OpenStack Certificate ผ่านจะได้รับรองความเป็นผู้เชี่ยวชาญด้าน OpenStack สามารถนำใบรับรองความสามารถด้านการดูแลระบบ OpenStack นี้ไปใช้ในการสมัครงานตำแหน่งระดับสูงได้ และในทางเดียวกันหาก OpenStack Admin ที่ทำงานอยู่ในองค์กรใดองค์หนึ่งถือครอง OpenStack Certificate Administrator ก็จะช่วยเพิ่มความน่าเชื่อถือให้กับลูกค้าและเป็นตัวการันตีว่าทีมงานมีคุณภาพตามมาตรฐาน ซึ่งการวัดผลคะแนนผ่านหรือไม่ผ่านนั้น ทาง COA ได้กำหนดไว้ในระเบียบการว่า “passing score of 76 or higher” หมายถึงผู้สอบ OpenStack Certificate Administrator  ต้องทำคะแนนให้ได้มากกว่าหรือเท่า 76 คะแนน