نموذج GitOps لإصدارات Helm

مع GitOps، يكون مستودع Git هو المصدر الوحيد للحقيقة، ويجعل عامل داخل العنقود الواقع مطابقًا لما تم الالتزام به. 🔁

بدلًا من تشغيل helm install يدويًا، تُصرّح بالإصدار المطلوب في Git. ويقرأه المتحكم ويطبّق التغيير نيابةً عنك.

يشغّل متحكم GitOps حلقة المطابقة باستمرار: يقارن العنقود الفعلي بما هو موجود في Git، ويتصرف لسد أي فجوة يجدها.

إصدار Helm ليس سوى حالة مطلوبة: مخطط وإصدار وقيم. وهذا يجعله مناسبًا تمامًا لسير عمل GitOps.

يدفع CI التقليدي التغييرات من خارج العنقود. أما متحكمات GitOps فتسحب التغييرات من Git من داخل العنقود، ولذلك لا تغادر بيانات الاعتماد نطاقه.

كل تغيير هو commit في Git، لذا يصبح سجل إصداراتك مسار تدقيق كاملًا يمكنك مراجعته وتحديد المسؤول عن تغييراته والتراجع عنها باستخدام أدوات Git المعتادة.

محركا GitOps الرائدان لاستخدام Helm هما Argo CD وFlux. يطابق كلاهما العناقيد مع Git، لكن بأسلوب مختلف.

لا تلتزم بملفات manifests الناتجة. بل تلتزم بمواصفة صغيرة تحدد المخطط ومستودع مصدره وإصداره وتجاوزات القيم الخاصة بك.

إذا عدّل شخص ما العنقود يدويًا، يكتشف المتحكم الانحراف عن Git، ويمكنه تحذيرك أو التراجع عنه تلقائيًا.

للتراجع عن إصدار، ما عليك سوى تنفيذ git revert على commit الخاطئ. يلاحظ المتحكم ذلك ويعيد العنقود إلى الحالة السابقة.

تحتفظ بـ Helm للتغليف وإنشاء القوالب، وتضيف GitOps للتسليم. يستدعي المتحكم Helm، بينما تدير أنت commits فقط.

ما الذي يؤدي دور مصدر الحقيقة في GitOps؟

تلتزم بإصدار Helm المطلوب في Git، ويقوم المتحكم بمطابقة العنقود معه. يأتي التدقيق والتراجع والتحكم في الانحراف مضمّنةً. 🎯