ตอนเริ่มใช้ Argo CD เราอาจตรวจความต่างแล้วกด sync เองเพื่อให้เห็นว่าระบบกำลังนำอะไรไปเปลี่ยน พอรูปแบบเริ่มนิ่ง ก็อยากให้มันตาม Git โดยอัตโนมัติเพื่อลดขั้นตอนที่คนต้องคอยกดซ้ำ
แต่คำว่าอัตโนมัติมีหลายพฤติกรรมซ่อนอยู่ครับ การนำค่าจาก Git ไปใช้ การลบ resource ที่หายจาก Git และการแก้สิ่งที่มีคนเปลี่ยนตรงใน cluster เป็นงานคนละแบบ จึงควรเลือกจากหน้าที่ที่ต้องการให้ controller ทำจริง
การแยกตัวเลือกก่อนเปิดช่วยให้ทีมรู้ว่าการแก้แบบใดจะเกิดขึ้นเอง และในช่วงตรวจปัญหาต้องไปเปลี่ยนแหล่งข้อมูลที่ใด เพื่อไม่ให้คนกับ controller พยายามรักษาคนละสถานะอยู่พร้อมกัน
เมื่อใช้ automated sync Argo CD สามารถนำ desired manifests ที่ติดตามไปปรับกับ live state เมื่อมีเงื่อนไขตามการทำงานของมัน การเปลี่ยนใน Git จึงอาจเป็นจุดเริ่ม deploy โดยไม่ต้องให้ CI เรียก API เพื่อกด sync อีกครั้งทุกงาน
นั่นทำให้เรื่องผู้มีสิทธิ์แก้ branch เส้นทางที่ติดตาม และวิธี review มีความหมายมากขึ้น ต้องรู้ว่า commit ใดพร้อมเป็น desired state ไม่ชี้ production ไป branch ที่ยังใช้ลอง config แบบไม่มีขอบเขตเพียงเพราะเปิด auto sync ได้ง่าย
ก่อนเปิดให้ตรวจว่า Application กำลังอ่าน repository path และ revision ที่ตั้งใจ รวมถึงปลายทาง cluster กับ namespace เพราะ controller จะทำงานตามข้อมูลที่กำหนด การทำอัตโนมัติไม่ช่วยแก้ความตั้งใจที่ชี้ผิดตั้งแต่ต้น
ตัวอย่างส่วนตั้งสมมติที่เปิด sync อัตโนมัติแต่ยังไม่เปิด prune กับ self-heal:
spec:
syncPolicy:
automated:
prune: false
selfHeal: false
นี่เป็นเพียงส่วนหนึ่งของ Application ต้องตรวจ manifest เต็มกับรุ่นที่ใช้ก่อนนำไปใช้ และยังไม่ได้บอกว่างานทั้งหมดไม่มีผลกับ resource เดิม เพราะการ sync ยังมีหน้าที่ปรับสถานะตามที่กำหนดอยู่
ตามค่าเริ่มต้นที่เอกสารอธิบาย automated sync ไม่ลบ resource เพียงเพราะมันหายจาก Git หากต้องการให้การลบเกิดอัตโนมัติจึงค่อยเปิด prune โดยต้องอ่านขอบเขตการติดตาม resource ของ Application นั้นร่วมด้วย
การลบไฟล์หรือเปลี่ยนการ generate manifest จึงไม่ใช่เพียงงานจัดโครง repo ถ้าเปิด prune ผลที่ได้อาจทำให้ resource บางตัวไม่มีใน desired set และเข้าสู่การจัดการตามนโยบายลบที่ตั้งไว้
ควรตรวจ diff จากผลที่ generate จริง ไม่อ่านเฉพาะไฟล์ต้นฉบับที่เปลี่ยน เพราะการแก้ value หรือ path อาจมีผลกับหลาย resource ที่ไม่ได้เห็นชื่ออยู่ในบรรทัดที่แก้โดยตรง โดยเฉพาะ chart หรือชุดที่ใช้ร่วมหลาย environment
ส่วน allowEmpty เป็นการอนุญาตกรณี desired resources ว่างตามเงื่อนไขของนโยบาย จึงเป็นอีกการตัดสินใจหนึ่ง ไม่ควรเปิดตามตัวอย่างเพื่อให้ทุกช่องเป็น true โดยยังไม่รู้ว่าถ้า render ออกมาว่างจะต้องการให้เกิดอะไร
หากมีคนแก้ live resource นอก Git แล้วอยากให้ระบบกลับมาตาม desired state พฤติกรรม self-heal เป็นส่วนที่ต้องดู การเปิดตัวเลือกนี้จึงควรอยู่กับข้อตกลงว่าจุดแก้ถาวรคือที่ใดและการเปลี่ยนเฉพาะหน้าจะถูกจัดการอย่างไร
ถ้าคนแก้ replica ตรงเพื่อทดลองแล้ว controller นำค่ากลับตาม Git การกดแก้ซ้ำโดยไม่ดูนโยบายจะทำให้ตามเหตุยากขึ้น ทีมควรมีขั้นรับมือที่ระบุแหล่งกำหนดกับระยะเวลาของการเปลี่ยน ไม่ให้การแก้ปัญหากลายเป็นงานแข่งกันเขียนค่า
ในทางกลับกัน การปิด self-heal ไม่ใช่คำรับรองว่า live change จะไม่มีวันถูกเขียนทับ เพราะการ sync ที่เกิดจากการเปลี่ยน source อื่นยังอาจนำ desired state กลับมาได้ ต้องดูจังหวะ reconcile และชนิด Application ร่วมกัน โดยเฉพาะงานหลาย source
หาก Application ถูกสร้างจาก ApplicationSet การแก้ลูกตรงๆ อาจไม่ใช่จุดควบคุมที่มีผลตามที่คาด ควรตามไปยังแหล่งที่สร้างมันและวิธีหยุดหรือปรับนโยบายที่รองรับ ไม่แก้ค่าที่จะถูก parent สร้างทับกลับมาแล้วสรุปว่าระบบไม่ยอมรับการตั้ง
สถานะ sync ช่วยบอกความสัมพันธ์ของ desired กับ live state ส่วน health มีวิธีประเมินตาม resource และการตั้งที่เกี่ยวข้อง แม้ทั้งสองมุมดูดี ก็ยังต้องมีการตรวจหน้าที่ของบริการตามสิ่งที่ทีมต้องการใช้งานจริง
ตัวอย่างเช่น manifest ตรงกันไม่ได้ยืนยันว่าข้อมูลถูกชุดหรือ API ทำงานกับ dependency ภายนอกครบ จึงควรมีจุดตรวจหลังปล่อยที่สัมพันธ์กับ release ไม่ใช้เพียงสีสถานะหนึ่งตัวเป็นข้อสรุปของธุรกรรมทั้งหมด
เมื่อ sync ล้มเหลว ให้ดูข้อความ ผลที่เกิดไปแล้ว และกติกาการลองใหม่ของรุ่นที่ใช้ ไม่คิดว่า controller จะลองทุก failure จนสำเร็จโดยไม่มีเงื่อนไข หรือคิดว่าการทำบางขั้นผ่านหมายถึงทุก resource ย้อนคืนเองแล้ว
การกลับรุ่นควรถูกวางกับ desired state และการเปลี่ยนข้อมูลด้วย หากยังเปิด auto sync แต่พยายามเปลี่ยนปลายทางให้ต่างจาก Git โดยไม่ปรับนโยบาย การแก้อาจถูกตามกลับ ควรมีขั้นที่ทีมรู้ว่าจะคืนแหล่งกำหนดให้ตรงกันอย่างไร
ก่อนใช้กับงานที่มีข้อมูลสำคัญ ลองกับ Application และ namespace ทดลองที่ไม่มีทรัพยากรของระบบจริง เลือกเหตุการณ์ทีละแบบ เช่น เปลี่ยนค่าใน Git ถอด resource ออกจากผล generate หรือแก้ live value แล้วดูว่าแต่ละนโยบายตอบอย่างไร
บันทึกทั้งตัวเลือก รุ่น และผล diff ที่เกี่ยวข้อง โดยยังแยกภาพสาธิตจากผลระบบจริง ภาพในบทนี้อธิบายหน้าที่ของนโยบาย ไม่ได้เป็นหลักฐานว่าทดลองกับ cluster ของเจ้าของเว็บแล้ว
เมื่อความหมายตรงกัน จึงเลือกเปิดตามลักษณะงานพร้อมสิทธิ์แก้ source และทางรับมือที่ชัด ไม่จำเป็นต้องทำทุก Application เหมือนกันหากทรัพยากร ความเสี่ยงการลบ และวิธีดูแลต่างกันจริง
Auto sync, prune และ self-heal เป็นการเลือกพฤติกรรมคนละส่วน ควรรู้ว่า source กับปลายทางถูกต้องและทีมแก้ desired state ที่ใด ก่อนให้ระบบนำไปใช้ ลบ หรือคืน live change อัตโนมัติ พร้อมตรวจ health และหน้าที่บริการหลังปล่อย เมื่อทดลองความหมายของตัวเลือกในขอบเขตที่ควบคุมได้ เราจะลดงานกดซ้ำโดยยังรู้ว่าการเปลี่ยนแต่ละแบบจะถูกใครนำไปทำต่อครับ