รูปแบบ GitOps สำหรับรีลีสของ Helm

ด้วย GitOps คลัง Git ของคุณคือ source เดียวที่เป็นแหล่งอ้างอิงหลัก และเอเจนต์ในคลัสเตอร์จะทำให้สภาพจริงตรงกับสิ่งที่คอมมิตไว้ 🔁

แทนที่จะเรียกใช้ helm install ด้วยตนเอง คุณจะ ประกาศ รีลีสที่ต้องการไว้ใน Git คอนโทรลเลอร์จะอ่านข้อมูลนั้นและนำการเปลี่ยนแปลงไปใช้ให้คุณ

คอนโทรลเลอร์ GitOps ทำงานด้วยลูป การปรับให้สอดคล้อง อย่างต่อเนื่อง โดยเปรียบเทียบคลัสเตอร์จริงกับ Git แล้วดำเนินการเพื่อปิดช่องว่างที่พบ

รีลีสของ Helm เป็นเพียงสถานะที่ต้องการ ซึ่งประกอบด้วยชาร์ต เวอร์ชัน และค่า จึงเหมาะอย่าง ยิ่ง กับเวิร์กโฟลว์ GitOps

CI แบบดั้งเดิมส่งข้อมูลจากภายนอกคลัสเตอร์ ส่วนคอนโทรลเลอร์ GitOps ดึง ข้อมูลจาก Git ภายในคลัสเตอร์ ทำให้ข้อมูลรับรองไม่ต้องออกจากคลัสเตอร์

การเปลี่ยนแปลงทุกครั้งคือคอมมิต Git ดังนั้นประวัติรีลีสของคุณจึงกลายเป็น ร่องรอยการตรวจสอบที่สมบูรณ์ ซึ่งคุณสามารถทบทวน ระบุผู้แก้ไข และย้อนกลับได้ด้วยเครื่องมือ Git ตามปกติ

ระบบ GitOps ชั้นนำสองระบบสำหรับ Helm คือ Argo CD และ Flux ทั้งคู่จะปรับคลัสเตอร์ให้สอดคล้องกับ Git แต่มีรูปแบบการทำงานต่างกัน

คุณไม่ต้องคอมมิตแม니เฟสต์ที่เรนเดอร์แล้ว แต่ให้คอมมิตสเปกขนาดเล็กที่ระบุ ชาร์ต คลังต้นทางของชาร์ต เวอร์ชัน และค่าที่คุณกำหนดทับ

หากมีผู้แก้ไขคลัสเตอร์ด้วยตนเอง คอนโทรลเลอร์จะเห็น ความคลาดเคลื่อนจาก Git และสามารถแจ้งเตือนคุณหรือยกเลิกการเปลี่ยนแปลงนั้นโดยอัตโนมัติ

หากต้องการย้อนกลับรีลีส เพียงใช้ git revert กับคอมมิตที่มีปัญหา คอนโทรลเลอร์จะตรวจพบและปรับคลัสเตอร์ให้กลับไปเป็นสถานะก่อนหน้า

คุณยังใช้ Helm สำหรับการแพ็กเกจและสร้างแม่แบบ แล้วเพิ่ม GitOps สำหรับการส่งมอบ คอนโทรลเลอร์จะเรียกใช้ Helm ส่วนคุณจัดการเพียง คอมมิต เท่านั้น

คุณคอมมิตรีลีส Helm ที่ต้องการไว้ใน Git แล้วคอนโทรลเลอร์จะ ปรับให้สอดคล้องกับคลัสเตอร์ Audit การย้อนกลับ และการควบคุมความคลาดเคลื่อนมีมาให้ในตัว 🎯