บทวิเคราะห์ GitOps สำหรับ Edge Fleet ของโรงงานหลายไซต์: จัดการ Configuration Drift ตามหลักการ OpenGitOps 4 ข้อ
คำถามที่ทุกโรงงานหลายไซต์เจอ: เซิร์ฟเวอร์ Edge 30 เครื่อง เหมือนกันจริงหรือไม่ เมื่อระบบ IIoT ขยายจาก pilot หนึ่งไซต์ไปสู่หลายโรงงาน คำถามที่ตามมาเสมอคือ เราจะมั่นใจได้อย่างไรว่าเซิร์ฟเวอร์ Edge ทุกเครื่องทั่วประเทศรันโค้ดเวอร์ชันเดียวกัน ใช้ค่า config เดียวกัน และติดตั้ง security patch ระดับเดียวกัน ประสบการณ์เดิมของหลายองค์กรคือการ ssh เข้าไปแก้ทีละเครื่อง ซึ่งใช้ได้กับ 3 เครื่อง แต่ไม่ใช่กับ 30 หรือ 300 เครื่อง คำตอบจากโลก software ที่กำลังไหลเข้าสู่โลกโรงงานคือ GitOps ซึ่ง OpenGitOps Working Group แห่ง CNCF ให้นิยามผ่านหลักการ 4 ข้อเวอร์ชัน 1.0.0 ได้แก่ Declarative (สถานะที่ต้องการต้องอธิบายแบบประกาศผล), Versioned and Immutable (เก็บประวัติทุกการเปลี่ยนแปลงแบบย้อนหลังได้), Pulled Automatically (agent ดึงสถานะจาก source เองโดยอัตโนมัติ) และ Continuously Reconciled (agent เฝ้าเทียบสถานะจริงกับที่ต้องการตลอดเวลา แล้วแก้กลับเมื่อพบความคลาดเคลื่อน) GitOps มักถูก implement คู่กับ lightweight Kubernetes บน edge node ของโรงงาน (ภาพ: Honey Corporation) Configuration Drift คือศัตรูที่แท้จริง ปัญหาไม่ใช่การติดตั้งครั้งแรก แต่คือ drift ที่สะสมทีละนิด เวอร์ชันโค้ดต่างกันหนึ่ง release, config ที่วิศวกรแก้ชั่วคราวตอนดึกเพื่อดับไฟปัญหา production แล้วลืมกลับมาเก็บ, patch ที่ติดตั้งบางเครื่องแต่ไม่ติดบางเครื่อง เมื่อเวลาผ่านไปหกเดือน ไม่มีใครกล้ายืนยันว่าทุกเครื่องเหมือนกันจริง และนี่คือจุดกำเนิดของปัญหา "ในเครื่องทดสอบทำงานได้ แต่ใน production ไม่ได้" รวมถึงช่องโหว่ความปลอดภัยที่ค้างอยู่ในเครื่องที่ถูกลืม วิเคราะห์: โมเดล Pull ทำงานกับ Edge ได้ดีอย่างไร จุดเปลี่ยนสำคัญที่ทำให้ GitOps เข้ากันได้กับสภาพแวดล้อมโรงงานคือโมเดล pull-based แทนที่เซิร์ฟเวอร์กลางจะ push การเปลี่ยนแปลงออกไปหา edge (ซึ่งต้องเปิดพอร์ตเข้าแต่ละเครื่องและรู้หมายเลข IP ทุกเครื่อง) ฝั่ง edge เป็นผู้ initiate connection ออกไปดึง desired state จาก Git repository…
