مستوى المقال: مبتدئ
لو فريقك بيشغّل kubectl apply 30 مرة في اليوم على الـ cluster، وفي يوم جالك OutOfMemory ومحدش عارف مين عمل آخر تعديل ولا فين الـ YAML الصح، إنت محتاج GitOps. الفكرة بسيطة: الـ git repo بيبقى المصدر الوحيد للحقيقة، و ArgoCD بيشتغل لوحده يطابق الـ cluster مع الـ repo. النتيجة المقاسة من فريق إنتاج: زمن الـ rollback من 12 دقيقة لـ 8 ثواني، وصفر تغييرات يدوية مفقودة في الـ audit log.
GitOps مع ArgoCD للمبتدئ: انشر تطبيقك بـ git push بدل kubectl apply
المشكلة باختصار
الطريقة التقليدية بتشتغل كده: مهندس بيكتب YAML، يعمل kubectl apply -f deployment.yaml، التطبيق بيشتغل، الكل سعيد. بعد شهر، الـ cluster فيه 200 مورد (resource)، 40 منهم مفيش لهم نسخة في الـ git، و3 ملفات في الـ repo اتغيّروا بدون ما حد يطبّقهم. اللي بيحصل فعلاً: الـ cluster الفعلي مش مطابق للـ git، ومحدش يقدر يجاوب على سؤال بسيط — "إيه اللي شغّال دلوقتي بالظبط؟"
المشكلة دي اسمها Configuration Drift. حسب CNCF Annual Survey 2024، حوالي 47% من فرق الـ DevOps بيتعاملوا مع drift بشكل شهري، ومتوسط الوقت لاكتشاف المشكلة بيوصل لـ 4.2 ساعة بعد أول incident.
تخيّل معاك أمين مكتبة دقيق
قبل ما ندخل في التعريف العلمي، خد المثال ده: تخيل مكتبة فيها 200 كتاب، وفيه فهرس مكتوب على الكمبيوتر بيقول كل كتاب مكانه فين بالظبط. لو حد جه أخد كتاب من على الرف بدون ما يحدّث الفهرس، هتتفاجأ بكتاب ناقص لما تدوّر بالفهرس بكره. الحل التقليدي: لازم كل واحد بياخد كتاب يفتكر يحدّث الفهرس يدوياً — وده اللي بيفشل دايماً مع الفرق الكبيرة.
دلوقتي تخيل لو فيه أمين مكتبة بيقعد طول اليوم يبص على الفهرس، يقارنه بالأرفف، ولو لقى فرق يرجّع كل كتاب لمكانه الصح أوتوماتيكياً. الفهرس بقى المصدر الوحيد للحقيقة، والأرفف بتطابق الفهرس دايماً. ده بالظبط اللي بيعمله ArgoCD مع الـ Kubernetes cluster: الـ git repo هو الفهرس، والـ cluster هو الأرفف، و ArgoCD هو أمين المكتبة الدقيق اللي مبيتعبش.
تعريف GitOps علمياً
بعد ما فهمنا الفكرة بالمثال، خلينا نتكلم بدقة. GitOps هو نمط تشغيلي عرّفه فريق Weaveworks في 2017، وحالياً عنده مواصفة رسمية من CNCF اسمها OpenGitOps. المبادئ الأربعة الأساسية:
- Declarative: الحالة المطلوبة للنظام مكتوبة كاملة في ملفات (YAML غالباً). إنت بتقول "عايز 3 replicas من الـ API" مش "شغّل الأمر ده 3 مرات".
- Versioned and Immutable: الملفات دي محفوظة في git، فكل تغيير له commit و author و timestamp. مفيش حاجة بتتعمل بدون أثر.
- Pulled Automatically: agent بيشتغل داخل الـ cluster بيسحب الحالة المطلوبة من git ويطبّقها. الـ cluster هو اللي بيسأل، مش الـ CI/CD اللي بيدفع.
- Continuously Reconciled: الـ agent بيقارن الحالة الفعلية بالمطلوبة كل دقيقة تقريباً، ويصلّح أي فرق تلقائياً.
ArgoCD هو الـ agent الأشهر اللي بيطبّق الـ pattern ده على Kubernetes. شركات زي Intuit و BlackRock و Adobe بتستخدمه على آلاف الـ clusters في إنتاج فعلي. الميزة الكبيرة: الـ pull-based model بيخلّي مفيش حد عنده credentials للـ cluster من بره — كل التغييرات بتيجي من git.
