สวัสดีครับ แอดมินเองคนเดิมนะครับ
ช่วงนี้เห็นหลายๆ คนแฮปปี้กับงานดี แต่บางคนก็อาจจะแย่หน่อยเพราะงานต้องปิดภายในสิ้นเดือนหรือศุกร์นี้ คงจะไม่ดีแน่ๆ ถ้าจู่ๆ มี ad-hoc วิ่งเข้ามาขณะที่กำลังเข้าด้ายเข้าเข็มใช่มะ แน่นอนว่าแอดมินเองเป็นหนึ่งในนั้น และบทความนี้ก็เป็น ad-hoc เช่นเคย
หลายเดือนก่อนแอดมินเองได้อ่านข่าวบนเพจเฟสบุ๊คสักเพจ (ไม่ได้แอบเล่นในเวลางานนะ) ที่ลงไว้ว่า kubernetes เป็นที่ยอดนิยมมากขึ้น มันเริ่มทำให้แอดมินเองรู้สึกอยากศึกษาเรื่องนี้จริงๆจังๆเสียที เลยตัดสินใจซื้อ textbook มาอ่านเลย
อ่านไปอ่านมารู้สึกสะดุดใจเรื่อง Linux Container เป็นพิเศษ เพราะเดิมทีใช้ docker container แล้วมัน magic ซะเหลือเกิน เสกของขึ้นมาแล้วไปทำอย่างอื่นต่อได้เลย แต่การที่เราใช้สิ่งๆนึงโดยที่ไม่รู้ว่าข้างในเป็นอะไรมันก็ยังไงอยู่ วันนี้เลยจะขอกล่าวถึงคอนเซ็ป Linux Container แบบฉบับ ad-hoc
In a nutshell โดยปกติ container ถูกออกแบบเพื่อแก้ pain จากการใช้ VM สำหรับงานบางงาน ยกตัวอย่าง VM อาจไม่เหมาะกับงานที่ถูกออกแบบโดยใช้ pattern microservice เท่าที่ควร เนื่องจาก VM มัน overhead ในเรื่องทรัพยากร ที่ส่งผลให้เกิด cost เกินความจำเป็น เพราะงั้น container จึงเป็นพระเอกในเรื่องนี้ เมื่อสร้างบน Linux มันจึงถูกเรียกว่า Linux Container Technologies
โดยปกติ Linux Container ประกอบไปด้วยกลไกพื้นๆ 2 อย่าง
- Linux Namespaces
- Linux Control Groups
Linux Namespaces
เป็นกลุ่มประเภทของ resource ในระบบ ซึ่ง resource เหล่านี้สามารถแบ่งให้กับกลุ่มของ process ใดๆได้ผ่านการเรียกใช้ฟังก์ชั่น system call อย่างเช่น clone, unshare, setns เป็นต้น
ผลลัพธ์จากการใช้ฟังก์ชั่น คือ process จะมองเห็นแค่ resource ที่อยู่ภายใต้ namespace เดียวกันเท่านั้น ขณะที่กลุ่ม process อื่นก็ควรเห็นเฉพาะภายใต้ namespace ตัวเอง ไม่ควรเห็นของ namespace อื่นเช่นกัน
ประเภท Linux Namespaces คร่าวๆ
- Mount (mnt) - แบ่งในระดับระบบไฟล์
- Process ID (pid) - แบ่งในระดับแต่ละ pid
- Network (net) - แบ่งในระดับ network แน่นอนว่าต้องมาตั้งค่าให้ virtual network เพิ่มด้วย
- Inter-process communication (ipc) - แบ่งจากการสื่อสารระหว่าง process ภายใต้ environment นึง
- UTS (UNIX Timesharing System) - แบ่งเป็นหลาย host/domain name ภายใต้ระบบเดียว
- User ID (user) - แบ่งโดยใช้ priviledge เป็นหลัก
จะเห็นได้ว่าเพียงแค่ Linux namespace ก็อาจจะพอเพียงสำหรับการแบ่ง application ในรูป container ใช่มะ แต่สำหรับปัจจุบันการเป็น production ที่ดียังมีอีกหลายสิ่งที่ต้องตระหนักอีกเยอะไม่ว่าจะเป็น
- การบันทึก/คำนวนการใช้งานทรัพยากรตามความเป็นจริง
- การรับมือเมื่อเกิดข้อผิดพลาดที่อาจส่งผลให้ระบบล้มเหลวโดยทรัพยากรในระบบ
- and so on…
ซึ่ง Linux Control Groups จะมีบทบาทในส่วนนี้
Linux Control Groups
ให้ลองนึกภาพดูว่า หาก process/application ภายใต้ namespace ที่ถูกกำหนดเป็นสัดส่วนอย่างดีได้ทำงานผิดพลาด อาทิเช่น เกิด infinite loop ระหว่างการทำงาน สิ่งที่ตามมาคือค่าใช้จ่ายที่แสนจะเปลือง โดยที่เจ้าของ application ไม่ได้คาดหวังว่าจะต้องจ่ายแม้แต่สตางค์เดียว การทำงานผิดพลาดเหล่านี้มีหลายสาเหตุอาจจะเกิดจากบั๊ค หรือ security breach (ที่หลุดมาเพื่อตั้งใจทำให้ระบบล่มหรือแอบหวังผลอะไรซักอย่าง) จึงเป็นเหตุผลที่ว่า container ต้องมีการทำ Control Groups เพื่อติดตามการทำงานและจำกัดทรัพยากรที่ควรใช้ตามที่มันควรจะเป็นจริงๆ
การทำ Control Groups สามารถทำผ่านฟังก์ชั่น cgroups เพื่อกำหนดช่วงเวลาในการใช้ทรัพยากร (period) และ ปริมาณการใช้ทรัพยากร (quota) ให้กับ process/application นั้นๆ ซึ่งจะลงรายละเอียดในบทถัดๆ ไป
สรุป
โดยสรุป Linux container จะทำงานได้เราจำเป็นต้องรู้ว่า container จะต้องใช้ทรัพยากรอะไรบ้าง และใช้ทรัพยากรใน container เท่าไหร่บ้าง ทั้งนี้เป็นเรื่องของการออกแบบระบบของแต่ละโปรเจค/ทีม ที่ต้องกำหนดวัตถุประสงค์ให้แน่ชัดสำหรับการทำงานในโลกของ micro service
แต่ไม่ว่าจะเป็นอะไร อย่าลืมเรื่อง S e c u r i t i e s ด้วยนะอันนี้สำคัญมาก
สัปดาห์นี้แอดมินเองขอตัวไปก่อนเนื่องจาก period และ quota แอดมินเองก็มีจำกัด รอบหน้าจะลงรายละเอียด Linux Namespaces มากกว่านี้ครับ
พบกันรอบหน้า สวัสดีครับ
