Rollback ใน GitOps ด้วย Argo CD ควรทำอย่างไร

การย้อนเวอร์ชันใน GitOps ต้องทำให้สถานะใน Git ตรงกับเวอร์ชันที่ต้องการ เหมาะกับการแก้ release ผิดพลาดโดย revert commit หรือเปลี่ยน revision ที่ประกาศไว้ บทความนี้สรุปแนวคิดจากเอกสารทางการของ Argo CD และจุดที่ควรตรวจเมื่อนำไปใช้จริง

ภาพรวม

Argo CD เปรียบเทียบสถานะใน Git กับ resource ที่ทำงานใน Kubernetes ทีมต้องระบุว่าใครแก้ Git และสั่ง sync ได้ รวมทั้งวิธีตรวจสุขภาพแอปหลัง deploy

หัวข้อนี้ตอบโจทย์เฉพาะเรื่อง: การย้อนเวอร์ชันใน GitOps ต้องทำให้สถานะใน Git ตรงกับเวอร์ชันที่ต้องการ จึงควรเริ่มจากปัญหาที่ต้องแก้และผลลัพธ์ที่คาดหวัง ไม่ใช่เพียงเปิดฟีเจอร์เพราะมีอยู่ในเครื่องมือ

หลักการทำงาน

Argo CD อาจ sync กลับไปยัง commit ล่าสุดหากย้อนเฉพาะ live resource แต่ Git ยังชี้ค่าปัจจุบัน

ให้ตรวจทั้งสถานะที่เครื่องมือรายงานและผลลัพธ์ปลายทางที่ผู้ใช้หรือระบบอื่นได้รับ หากสองส่วนไม่ตรงกัน ควรกลับไปตรวจค่าตั้งต้นและขอบเขตที่ฟีเจอร์นี้รับผิดชอบก่อนเปลี่ยนค่าเพิ่มเติม

เหมาะกับงานแบบไหน

เหมาะกับการแก้ release ผิดพลาดโดย revert commit หรือเปลี่ยน revision ที่ประกาศไว้

ก่อนทดลอง ให้ระบุสิ่งที่จะใช้วัดผล เช่น เวลาตอบสนอง ความพร้อมใช้งาน ความถูกต้องของข้อมูล หรือภาระการดูแล แล้วเทียบกับสภาพเดิม วิธีนี้ช่วยให้รู้ว่าฟีเจอร์แก้ปัญหาจริงหรือย้ายภาระไปอีกจุดหนึ่ง

ขั้นตอนนำไปใช้

1. ตรวจ repository, revision, namespace และ AppProject
2. อ่าน diff ก่อน sync และดูทั้งสถานะ Synced กับ Healthy
3. เตรียม commit สำหรับย้อนการเปลี่ยนและวิธีกู้ข้อมูล

เริ่มจากขอบเขตเล็กและเก็บผลทดสอบไว้กับการเปลี่ยนแปลง หากจะใช้ใน production ให้กำหนดผู้ติดตามผลและเงื่อนไขที่จะหยุดการขยายการใช้งาน

ข้อควรระวัง

เตรียมขั้นตอนย้อนฐานข้อมูลและข้อมูลผู้ใช้แยกจากการย้อน manifest

แปลงข้อควรระวังนี้เป็นรายการตรวจในการทบทวนงาน เพราะปัญหาจากค่าตั้งต้นอาจไม่แสดงทันทีในสภาพแวดล้อมทดสอบ

สรุป

การย้อนเวอร์ชันใน GitOps ต้องทำให้สถานะใน Git ตรงกับเวอร์ชันที่ต้องการ เหมาะกับการแก้ release ผิดพลาดโดย revert commit หรือเปลี่ยน revision ที่ประกาศไว้ ก่อนนำไปใช้กับงานหลัก ควรตรวจผลตามขั้นตอนข้างต้นและทบทวนข้อจำกัดของระบบที่มีอยู่

อ่านเพิ่มเติม: เอกสารทางการของ Argo CD