GitOps بـ Argo CD: ليه النشر بالـ Push بيكسر عنقودك والـ Pull بيصلحه

المستوى المطلوب: محترف — الشرح مبني على فرضية إنك بتشغّل خدماتك على Kubernetes، وعارف يعني إيه kubectl apply و CI/CD pipeline. لو لسه في أول الطريق مع الحاويات، جهّز الأساسيات الأول ثم ارجع.

GitOps بـ Argo CD: خلّي Git هو المصدر الوحيد للحقيقة

لو فريقك بيعمل deploy بـ kubectl apply من داخل الـ CI pipeline، انت عمليًا مدّي مفاتيح عنقودك لأي حاجة تقدر تعدّل الـ pipeline. GitOps بيقلب الاتجاه: بدل ما الـ CI يدفع (push) التغييرات جوّه العنقود، وكيل ساكن جوّه العنقود بيـسحب (pull) الحالة المطلوبة من Git ويطبّقها بنفسه. المكسب المباشر: صلاحيات أقل بكتير، سجل تغييرات كامل، وتراجع في ثوانٍ.

المشكلة باختصار

النشر بالـ push بيخلّي أداة الـ CI ماسكة credentials للعنقود بشكل دائم. أي اختراق للـ pipeline بيتحوّل فورًا لاختراق للـ production. والأسوأ: مفيش مصدر واحد بيقول "إيه اللي شغّال دلوقتي فعلاً". أول ما حد يعمل kubectl edit بإيده على السيرفر تحت الضغط، العنقود يبقى مختلف عن الـ repo، ومحدش واخد باله. المشكلة دي ليها اسم: انحراف الإعدادات (configuration drift)، وهي السبب الخفي ورا نُص الحوادث اللي "الكود فيها متغيّرش".

الفكرة بمثال بسيط الأول

تخيّل ترموستات في أوضة. انت بتحدد الحرارة المطلوبة: 22 درجة. الترموستات بيقيس الحرارة الحالية طول الوقت، ولو لقى فرق بيشغّل التكييف لحد ما يوصل للرقم اللي انت طلبته. انت مش بتشغّل التكييف بإيدك؛ انت بس بتعلن الحالة المطلوبة، والجهاز بيقرّب الواقع منها باستمرار.

GitOps بيشتغل بنفس المبدأ بالظبط. الـ Git repo هو "الحرارة المطلوبة" — يعني الحالة المرغوبة. Argo CD هو الترموستات: بيقارن طول الوقت بين اللي مكتوب في Git واللي فعلاً شغّال في العنقود، وأي فرق بيصلحه لوحده.

الشرح العلمي الدقيق

Argo CD بيشغّل حلقة تسوية (reconciliation loop) مستمرة. كل دورة بيعمل أربع خطوات: يجيب الـ manifests من Git (الحالة المرغوبة / desired state)، يقرأ الحالة الفعلية (live state) من الـ Kubernetes API، يحسب الفرق (diff)، ولو فيه اختلاف بيعمل مزامنة (sync). لو فعّلت خاصية selfHeal، أي تعديل يدوي على العنقود بيترجّع تلقائيًا للحالة اللي في Git.

ده بيحقق مبادئ GitOps الأربعة كما عرّفها مشروع OpenGitOps: الحالة معلنة (declarative)، ومحفوظة بإصدارات غير قابلة للتعديل في Git (versioned & immutable)، ومسحوبة تلقائيًا (pulled automatically)، ومسوّاة باستمرار (continuously reconciled).

مثال تنفيذي

ده تعريف تطبيق (Application) كامل بيربط repo فيه manifests بـ namespace في العنقود. حطّه في ملف web-app.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/web-app-config.git
    targetRevision: main
    path: manifests/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # يحذف الموارد اللي اتشالت من Git
      selfHeal: true   # يرجّع أي تعديل يدوي للحالة اللي في Git
    syncOptions:
      - CreateNamespace=true

وده تركيب Argo CD نفسه في العنقود ثم تطبيق التعريف ومراقبة المزامنة:

# 1) ثبّت Argo CD جوّه العنقود
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 2) طبّق تعريف التطبيق
kubectl apply -f web-app.yaml

# 3) راقب حالة المزامنة والصحة
argocd app get web-app
argocd app sync web-app

السطرين المهمين هما prune: true وselfHeal: true. الأول بيخلّي حذف مورد من Git يحذفه فعلًا من العنقود. الثاني هو اللي بيقتل الـ drift: أي kubectl scale أو kubectl edit يدوي بيترجّع تلقائيًا. من غيرهم انت عندك مزامنة مرة واحدة، مش GitOps حقيقي.

سيناريو واقعي بالأرقام

خُد فريق عنده 12 خدمة على عنقود إنتاج، وكل الـ deploy بيتم بـ kubectl apply من الـ CI. عدد الجهات اللي ماسكة credentials للعنقود بيوصل بسهولة لـ 15 (كل واحد له صلاحية على الـ CI). بعد التحويل لـ GitOps، الرقم ده بينزل لـ 3 تقريبًا (الـ Argo CD controller نفسه + أدمن أو اتنين). دي أرقام تقديرية لكنها واقعية لفريق بالحجم ده.

الأهم: بعد كل نشر بـ push كنت لو عايز تراجع لازم تفتكر الحالة القديمة وتكتبها بإيدك تحت الضغط — عملية بتاخد دقائق ومعرّضة للغلط. مع GitOps التراجع هو git revert لآخر commit، وArgo بيزامن الحالة القديمة لوحده. زمن التعافي (MTTR) بينزل من حدود 8 دقائق يدوي لأقل من دقيقة. وبالنسبة لسرعة النشر: Argo CD بيعمل تسوية دورية كل 180 ثانية افتراضيًا (timeout.reconciliation: 180s)، ولو ربطته بـ webhook من مستودعك بيزامن التغيير في ثوانٍ بدل ما يستنى الدورة التالية.

الـ trade-offs: بتكسب إيه وبتخسر إيه

• بتكسب: أقل صلاحيات (العنقود بيسحب، والـ CI مش ماسك مفاتيحه)، سجل تدقيق كامل من تاريخ Git، تراجع فوري، وتصحيح تلقائي لأي انحراف.
• بتخسر: طبقة أدوات جديدة تتعلمها وتشغّلها وتراقبها. وإدارة الأسرار بتبقى أصعب — ممنوع تحط secrets خام في Git، فمحتاج حل زي Sealed Secrets أو External Secrets Operator أو SOPS. والتصحيح بقى غير مباشر شوية: بتبص في واجهة Argo وسجلاته، مش في kubectl على طول.

الافتراض هنا إن عندك أكتر من بيئة أو أكتر من خدمة يستاهلوا التنظيم ده. لو الصورة أبسط من كده بكتير، اقرأ القسم اللي بعده.

متى لا تستخدم هذه الطريقة

متدخلش في GitOps لو مالكش Kubernetes أصلًا — الأداة كلها مبنية حواليه. وكمان لو عندك عنقود واحد وخدمة أو اتنين وعمليات نشر نادرة، الـ overhead بتاع تركيب Argo وصيانته وفصل الأسرار مش هيستاهل. في الحالات دي، pipeline بسيط بـ push وسكربت تراجع مكتوب كويس بيكفّي ويوفّر عليك تعقيد مالوش لازمة.

الخطوة التالية

ثبّت Argo CD على عنقود تجريبي، اعمل repo فيه manifest واحد لخدمة صغيرة، وفعّل selfHeal: true. بعدها اعمل kubectl scale deployment web-app --replicas=5 بإيدك وراقب. لو Argo رجّع عدد الـ replicas للرقم اللي في Git خلال أقل من 3 دقائق من غير ما تلمس حاجة، يبقى الـ reconciliation شغّال صح — وانت جاهز تنقل خدمة حقيقية.

المصادر

• توثيق Argo CD الرسمي — المزامنة، الـ self-heal، وفاصل التسوية الافتراضي (timeout.reconciliation): argo-cd.readthedocs.io
• مبادئ GitOps الأربعة من مشروع OpenGitOps التابع لـ CNCF: opengitops.dev
• Argo CD كمشروع متخرّج (Graduated) في مؤسسة CNCF: cncf.io/projects/argo
• مفهوم الـ Controllers وحلقة التسوية في توثيق Kubernetes: kubernetes.io/docs/concepts/architecture/controller