ยกระดับศักยภาพทาง DevOps ของเราไปอีกขั้นด้วย GitOps

ช่วงนี้เป็นช่วงที่โครงการ FluxCD ซึ่งเป็น GitOps operator สำหรับ Kubernetes จากเดิมที่เป็นโครงการระดับ Sandbox นั้น FluxCD ได้รับมติเสียงข้างมากจาก TOC ของ CNCF (Cloud Native Computing Foundation) ให้ขยับขึ้นไปเป็นโครงการระดับ Incubation (ซึ่งแปลว่าอีกระดับเดียวจะถึงระดับ Graduation แบบเดียวกับ Kubernetes หรือ Prometheus แล้ว)

ผมเลยจะถือโอกาสนี้ขีด ๆ เขียน ๆ เล่าให้ฟังว่า FluxCD และ GitOps สำคัญยังไงและสามารถใช้ยกระดับศักยภาพทางด้าน DevOps เพื่อเพิ่มโอกาสต่าง ๆ ของเราได้อย่างไร

ก่อนอื่นก็มาทำความรู้จักกับ GitOps operator กันก่อน

GitOps Operator

ในโลกของ Kubernetes มีระบบจัดการ GitOps หรือที่เรียกกันว่า GitOps operator ที่เป็นไปตามหลักการของ GitOps จริง ๆ อยู่ 2 ตัว นั่นคือ FluxCD กับ ArgoCD

การเป็น GitOps operator ที่รันอยู่ภายใน Kubernetes นั้นเป็นการทำงานในลักษณะที่ใช้ “pull model” คือตัว GitOps operator จะทำการดึง YAML files เข้ามา deploy ให้ในตัว Kubernetes ซึ่งวิธีนี้จะตรงข้ามกับ “push model” ที่ให้ CI/CD pipeline ทำการ apply YAMLs เข้า Kubernetes จากด้านนอก

เหตุผลหลักๆ ที่ pull model ดีกว่าก็คือเรื่องของ security เพราะลักษณะการทำงานแบบที่ GitOps operator ใช้นั้นตัว credentials ของ cluster ไม่ได้ถูกนำออกมาจากตัว cluster แต่ถ้าเปลี่ยนเป็น push model เมื่อไหร่ เราก็จะต้องนำ credentials ของ cluster ไปใส่ไว้ในที่ต่าง ๆ ที่มีหน้าที่ในการ apply YAMLs ให้เรา โดยทั้ง FluxCD และ ArgoCD ต่างก็ใช้ pull model

GitOps Toolkit

หลักจาก FluxCD ถูกสร้างมาได้ระยะนึงก็ได้เข้ามาเป็นโครงการระดับ Sandbox ของ CNCF ระหว่างนั้นทีมพัฒนาของ Flux ก็ได้เรียนรู้ข้อจำกัด รวมทั้งข้อผิดพลาดในเชิงการออกแบบ จากทั้ง Flux รุ่นแรก (ต่อไปผมจะเรียก Flux รุ่นแรกว่า Flux v1 นะครับ) และ ทั้ง ArgoCD เมื่อมีโอกาส ทีมพัฒนาของ Flux ก็ได้ทำการสร้าง operator ใหม่ขึ้นมาชุดนึงโดยรอบนี้ใช้สถาปัตยกรรมแบบ Microservices โดย operator เหล่านั้นเรียกรวม ๆ กันว่า GitOps Toolkit (GOTK)

ใน GitOps Toolkit จะประกอบไปด้วย operator หลาย ๆ ตัวเช่น Source controller, Kustomization controller และ controller อื่น ๆ ที่ทำงานร่วมกันแล้วจะได้ความสามารถในลักษณะเดียวกันกับ Flux v1 และเมื่อเริ่มได้ฟีเจอร์ที่ครบถ้วนขึ้นเรื่อย ๆ ในทีมพัฒนาก็มีการคุยกันว่า Flux รุ่นใหม่สามารถสร้างขึ้นมาได้จากการใช้ชิ้นส่วนของ GOTK เหล่านี้ ทีมพัฒนา Flux เลยสร้าง Flux v2 ขึ้นมาจากชิ้นส่วนของ GOTK และพัฒนาความสามารถขึ้นมาเรื่อย ๆ จนถึง Flux v2 0.8 และประกาศให้ รุ่น 0.8 เป็นรุ่น Feature Parity (ดูเอกสารประกอบ) คือมีความสามารถเทียบเท่า Flux v1 แล้ว

ในขณะที่เขียนบทความนี้อยู่ Flux v2 ก็อยู่ในช่วงของรุ่น 0.9 ซึ่งกำลังแก้ bug เพื่อเพิ่มเสถียรภาพและรับ feedback จากผู้ใช้เพื่อนำไปปรับปรุงหรือเพิ่มเติมความสามารถที่ตกหล่นไป และก็เป็นช่วงเวลาเดียวกันกับที่ Flux v2 ได้รับการยกระดับให้เป็นโครงการระดับ Incubation ของ CNCF อย่างที่เกริ่นไว้

เสริมความแกร่งให้ DevOps ด้วย GitOps

หลาย ๆ ท่านอาจจะทำ DevOps อยู่แล้วโดยการใช้ CI/CD pipeline เช่น ใช้ Jenkins, GitHub Actions หรือ Tekton ในการ build โปรแกรม, test โปรแกรม เมื่อ test ผ่านแล้วก็ pack ให้เป็น container จากนั้นก็ push ขึ้น container registry เช่น Docker Hub หรือ ECR แล้วก็ให้ pipeline ทำการ deploy ขั้นสุดท้ายเข้า Kubernetes cluster ด้วยการ apply YAMLs

บางคนอาจจะส่งสัยว่า CI/CD แบบนี้มันก็ดีอยู่แล้ว จะให้ทำอะไรกับมันอีก

ลองนึกดูดี ๆ ครับว่า CI/CD pipeline ที่เราสร้างไว้นั้น จะสามารถช่วยอะไรได้บ้างเมื่ออยู่ดี ๆ cluster ของเราหายไป ต้องสร้างขึ้นมาใหม่ แล้วต้องทำให้ application กลับมารันให้ได้ภายใน SLA ที่กำหนด

ในส่วนนี้ผมจะเล่าวิธีการของ GitOps รูปแบบนึง (ในหลาย ๆ รูปแบบที่สามารถทำได้) ที่จะนำมาเสริม CI/CD pipeline ให้ทรงพลังมากขึ้น เราทำการปรับจาก pipeline เดิมที่มีเพียงเล็กน้อย ไม่ยากเลย

โดยเราจะทำการสร้าง Git repo ขึ้นมาอีก 1 repo เพื่อเก็บ YAML ไฟล์ที่ต้องการ deploy ลง cluster และ YAML ทุกอย่างที่เราเตรียมเพื่อใช้ deploy ลง cluster นั้นก็ให้เก็บเข้า Git repo ตัวนี้ก่อน เราจะเรียก Git repo ตัวนี้ว่า GitOps config repo

ส่วนเจ้า CI/CD pipeline ที่ใช้ build, test, push image และ apply YAML เราก็ปรับให้ขั้นตอนสุดท้ายแทนที่จะ apply YAML ก็ให้นำ YAML ที่ต้องการ apply นั้นไปใส่ไว้ใน GitOps config โดยการ git commit และ git push ไปยัง GitOps config repo

เพื่อให้ GitOps ทำงาน เราก็ต้องติดตั้ง GitOps operator เช่น Flux ลงใน Kubernetes cluster ของเรา และให้มันอ่าน YAML จาก GitOps config repo เช่นอาจจะทุก ๆ 1 หรือ 5 นาที

เมื่อ Cluster พัง

ถ้าถึงคราว Cluster พัง สิ่งที่เราต้องทำก็เพียงแค่การสร้าง cluster เปล่าขึ้นมาใหม่ จากนั้นติดตั้ง Flux อีกครั้งด้วยคำสั่ง flux bootstrap command แล้วชี้ไปหา GitOps config repo ที่มันเก็บ YAML ของเราไว้ จากนั้น application ที่เคยรันได้ด้วย YAML ชุดนั้นก็จะกลับขึ้นมาทำงานให้เราได้เหมือนเดิม

GitOps for the Win

จะเห็นได้ว่าแนวคิดที่ทรงพลังแต่เรียบง่ายอย่าง GitOps สามารถนำมาใช้เสริมทักษะ DevOps ที่เรามีให้การจัดการ Kubernetes กลายเป็นเรื่องที่ง่ายขึ้น ล่มแล้วกู้กลับมาง่ายขึ้น ลด mean-time-to-recovery ลงได้อย่างชัดเจน และจะทำให้ศักยภาพทาง DevOps ของเราขยับขึ้นไปอีกขั้นอย่างแน่นอนครับ