المستوى: مبتدئ — يكفي إنك فاهم إيه هو الـ Pod والـ Deployment، وعملت kubectl apply مرة أو اتنين قبل كده. مش محتاج خبرة سابقة في ArgoCD.

بعد ما تخلّص المقال ده، هتعرف تخلّي أي تعديل على الـ cluster يتسجّل في Git أولاً، ويترجع لحالته الصح لوحده في ثوانٍ لو حد عبث فيه يدوي. ده اللي بيسمّوه GitOps، والأداة اللي هننفّذ بيها اسمها ArgoCD.

GitOps و ArgoCD: الـ cluster اللي بيصلّح نفسه من Git

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

الطريقة الشائعة في فِرَق كتير: كل مهندس بيعمل kubectl apply أو kubectl edit على الـ cluster من جهازه. الطريقة دي بتفشل في حالتين. الأولى: محدّش يعرف الحالة الحقيقية للإنتاج دلوقتي، لأن آخر تعديل اتعمل في تيرمينال حد ومارَاحش لأي مكان. الثانية: لو حد عمل scale يدوي وقت ضغط، التعديل ده بيفضل موجود أسابيع من غير ما حد ياخد باله، وده اسمه configuration drift — فرق بين اللي مكتوب عندك واللي شغّال فعلاً.

افهمها بمثال: الترموستات

تخيّل ترموستات التكييف في البيت. انت مش بتقوله "اشتغل دقيقتين وبعدين قِف". انت بتقوله "خلّي الأوضة 24 درجة". ده كل اللي بتعمله. بعد كده الترموستات بيقيس الحرارة الحقيقية كل شوية، ولو لقاها 27 يشغّل التبريد لحد ما توصل 24، ولو حد فتح الشباك وسخّنت تاني، بيرجّع يبرّد لوحده. انت حدّدت الحالة المطلوبة بس، والجهاز هو اللي بيقارن ويصلّح باستمرار.

GitOps بيشتغل بنفس المنطق بالظبط. انت بتكتب الحالة المطلوبة للـ cluster (كام نسخة من الخدمة، أنهي إصدار، أنهي إعدادات) في ملفات YAML داخل Git. وبعدين فيه "ترموستات" اسمه ArgoCD قاعد جوّه الـ cluster، بيقارن اللي في Git باللي شغّال فعلاً، ولو لقى اختلاف بيصلّحه. علمياً: GitOps هو نموذج تشغيل بيخزّن الحالة المطلوبة للنظام بشكل تصريحي (declarative) في مستودع نسخ (Git)، وبيستخدم وكيلًا (agent) بيقارن الحالة الفعلية بالمطلوبة بشكل مستمر ويقرّبها منها — وده اللي اسمه reconciliation loop.

المبادئ الأربعة اللي لازم تفهمها

مبادرة OpenGitOps (تحت مظلة CNCF) بتلخّص GitOps في 4 مبادئ. لو حلّك كسر أي واحد منهم، انت لسه بتنشر سوفتوير، بس مش بتاخد فايدة GitOps الحقيقية:

1. تصريحي (Declarative): الحالة المطلوبة مكتوبة كـ "بيانات" مش كأوامر متسلسلة. بتقول "عايز 3 نسخ" مش "شغّل نسخة 3 مرات".
2. مُؤرشف وثابت (Versioned & Immutable): الحالة محفوظة في Git، فكل تغيير له تاريخ وصاحب وإمكانية رجوع بـ git revert.
3. يُسحب تلقائيًا (Pulled automatically): وكيل جوّه الـ cluster بيسحب الحالة من Git؛ محدّش بيعمل SSH وينشر بإيده.
4. مُصالَح باستمرار (Continuously reconciled): الوكيل بيقارن الفعلي بالمطلوب في حلقة دائمة، ويصلّح أو يقولك ليه مش قادر.

الخطوات: نركّب ArgoCD ونربطه بـ repo

هذا الشرح مبني على فرضية إن عندك cluster Kubernetes شغّال (1.28+) و repo فيه ملفات الـ YAML بتاعتك. التركيب نفسه أمرين:

# 1) اعمل namespace لـ ArgoCD وركّبه
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 2) استنى الـ pods تشتغل
kubectl wait --for=condition=available --timeout=300s \
  deployment/argocd-server -n argocd

دلوقتي بدل ما تعمل kubectl apply بإيدك، بتعرّف للـ ArgoCD مورد اسمه Application. ده بيقوله: "اسحب من الـ repo ده، من المسار ده، وطبّقه على الـ namespace ده، وصلّحه لوحدك". خلّي بالك من سطرَي selfHeal وprune، دول قلب الموضوع:

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

# طبّق تعريف الـ Application نفسه (آخر مرة تستخدم apply يدوي)
kubectl apply -f store-api-app.yaml

# اتابع حالة المزامنة
argocd app get store-api

الجزء اللي بيبهر: self-heal ضد الـ drift

سيبك من الكلام، نجرّبه. افرض عندك replicas: 2 في Git، وحد دخل وقت ضغط وعمل:

kubectl scale deployment store-api --replicas=5 -n store

من غير ArgoCD، الـ 5 نسخ دول هيفضلوا شغّالين أيام، والفرق بين Git والإنتاج هيكبر بهدوء. اللي بيحصل فعلاً مع selfHeal: true: ArgoCD بيقارن، بيلاقي الحالة OutOfSync، ويرجّع الـ Deployment لـ 2 نسخة لوحده. في التجارب العملية المنشورة سنة 2026، التعديل اليدوي اترجّع في حدود 5 ثوانٍ، والنسخ الزيادة ما كمّلتش تشتغل أصلاً.

مهم تفهم رقمين: المهلة الافتراضية للمصالحة الدورية في ArgoCD حوالي 3 دقائق، ومهلة إعادة محاولة الـ self-heal الافتراضية حوالي 5 ثوانٍ. يعني حتى من غير ما حد يلاحظ، الفرق بيتقفل في ثوانٍ بدل أيام. للمقارنة، فريق بيكتشف الـ drift يدويًا ممكن ياخد أيام — رقم تقديري شائع حوالي 4 إلى 5 أيام لحد ما حد ياخد باله.

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

• بتكسب: سجل كامل (audit) لكل تغيير، ورجوع فوري بـ git revert بدل ما تفتكر إيه اللي اتعمل، وإصلاح تلقائي للـ drift.
• بتخسر: كل تغيير لازم يعدّي على Git و PR. ده أبطأ في الطوارئ من تعديل سريع بإيدك.
• منحنى تعلّم: الفريق لازم يتعوّد إن "السيرفر مش بيتعدّل بإيد" خالص.
• الـ Secrets: ما ينفعش تحط passwords خام في Git. محتاج حل زي Sealed Secrets أو SOPS، وده شغل إضافي.

متى لا تستخدم GitOps

لو عندك cluster واحد صغير، وتغييراتك نادرة، ولسه مفيش عندك أي CI، الـ overhead بتاع ArgoCD مش هيستاهل دلوقتي — ابدأ بـ pipeline بسيط الأول. كمان لو شغلك بيتطلب تدخلات يدوية سريعة جدًا وقت الحوادث، خلّي بالك إن selfHeal: true ممكن يقاوم تعديلك ويرجّعه؛ في الحالة دي عطّل الـ self-heal مؤقتًا للخدمة دي وقت الحادث بدل ما تتفاجئ.

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

ركّب ArgoCD على cluster تجريبي (minikube أو kind يكفي)، اربطه بـ repo فيه Deployment واحد بـ replicas: 2، فعّل selfHeal: true، وبعدين اعمل kubectl scale --replicas=5 بإيدك. لو رجع لـ 2 لوحده في ثوانٍ، يبقى فهمت GitOps عمليًا. لو ما رجعش، اتأكد إن الـ automated policy متفعّلة في تعريف الـ Application.

المصادر

• OpenGitOps — المبادئ الأربعة الرسمية: opengitops.dev وopen-gitops/documents (PRINCIPLES.md)
• توثيق Argo CD الرسمي حول Automated Sync و Self-Heal: argo-cd.readthedocs.io
• أرقام self-heal والمصالحة (2026): How to Implement Self-Healing Applications in ArgoCD — OneUptime وHow Configuration Drift Detection Works in GitOps — OneUptime
• الفرق بين GitOps والـ CI/CD التقليدي: Understanding the 4 Core GitOps Principles — Akuity