هذا المقال يتطلب مستوى متوسط — يفترض أن لديك معرفة بأساسيات Kubernetes، وكتابة YAML manifests، و Git workflow. لو لسه بتتعلم Kubernetes ابدأ بمقال الـ Probes الأول قبل ده.

لو فريقك بيـ deploy على cluster Kubernetes بـ kubectl apply يدوي، فيه يوم هيحصل فيه drift صامت بين الـ Git والـ cluster. حد عمل تعديل سريع مباشرة على الـ cluster ونسي يحطّه في Git، أو الـ pipeline بتاع CI خبط في النص ومحدش ركّز. بعد شهرين، اللي شغّال على production مش بالظبط اللي في الريبو. ArgoCD بيقفل الباب ده نهائياً.

ArgoCD وفكرة GitOps في cluster واحد

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

الـ deployment اليدوي بيخلّي الـ cluster يبعد عن الـ Git مع الوقت. Source of truth بيبقى ملفوف بين tribal knowledge وملاحظات في Slack وملفات على لاب توب أحد المهندسين. النتيجة: rollback صعب، audit مستحيل، و onboarding للناس الجديدة بياخد أسابيع.

المشكلة دي مش نظرية. تقرير CNCF Annual Survey 2024 بيقول إن 41% من فرق الـ DevOps اللي اعتمدت على kubectl apply يدوي مرّوا بحالة rollback اضطروا فيها يعملوا git revert على شيء مش موجود في Git أصلاً. ده فقد ثقة، مش بس فقد وقت.

GitOps بمثال للمبتدئ: السكرتير اللي بيتابع جدولك

تخيّل إن عندك سكرتير شاطر جداً. بدل ما يستنى منك أوامر، عنده نسخة من جدولك المثالي مكتوبة على ورقة مقفولة في الدرج. كل 3 دقائق، بيقارن جدولك الفعلي بالورقة. لو لاقى اختلاف — اجتماع زيادة، ميعاد اتشال، شغل اتنسى — بيرجّع جدولك للورقة من غير ما يسألك.

الورقة دي = Git repo. الجدول الفعلي = الـ Kubernetes cluster. السكرتير = ArgoCD.

المثال ده بيوضح فكرتين أساسيتين: الـ desired state موصوف ومحفوظ في مكان واحد، والتطبيق الفعلي بيلحق الـ desired state تلقائياً. لو فهمت دول، فهمت GitOps.

التعريف العلمي الدقيق

ArgoCD هو continuous delivery operator يعمل داخل Kubernetes ويطبّق نمط GitOps المُعرَّف في OpenGitOps Principles v1.0 الصادرة من CNCF. النمط مبني على 4 شروط متلازمة:

1. Declarative: الـ desired state موصوف بـ YAML أو Helm أو Kustomize، مش سكربتات إجرائية.
2. Versioned and Immutable: الـ state محفوظ في Git مع history كامل وكل تغيير عليه commit موقّع.
3. Pulled Automatically: agent جوّا الـ cluster بيسحب التغييرات (مش push من خارج). ده فرق أمني جوهري عن CI/CD التقليدي.
4. Continuously Reconciled: الـ agent بيقارن actual vs desired باستمرار ويصلّح الفرق.

تقنياً، ArgoCD بيستخدم Kubernetes controller pattern. بيعمل polling على الـ Git repo كل 3 دقائق default (أو فوري عبر webhook)، ويحلّ Helm/Kustomize محلياً، ويقارن الناتج بالـ live state عبر Kubernetes API. لو فيه فرق، بيطبّقه. الـ loop ده اسمه reconciliation loop وهو نفس المبدأ اللي بيشتغل بيه الـ Deployment Controller الأصلي في Kubernetes.

تطبيق عملي: انشر nginx من Git في 6 خطوات

السيناريو: عندك cluster Kubernetes جاهز (Minikube، k3s، أو cluster سحابي)، و repo Git فاضي على GitHub. عايز تـ deploy nginx فيه 3 replicas من غير ما تشغّل kubectl apply لأي manifest يدوياً بعد التثبيت الأولي.

1. ثبّت ArgoCD في الـ cluster:
   Bashنسخ الكود

   kubectl create namespace argocd
   kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.13.0/manifests/install.yaml
   kubectl wait --for=condition=available --timeout=300s deployment/argocd-server -n argocd

2. افتح الواجهة على لوكال:
   Bashنسخ الكود

   kubectl port-forward svc/argocd-server -n argocd 8080:443
   # الـ password الافتراضي:
   kubectl -n argocd get secret argocd-initial-admin-secret \
     -o jsonpath="{.data.password}" | base64 -d

3. حضّر Git repo فيه manifest بسيط — أنشئ ملف manifests/nginx.yaml:
   YAMLنسخ الكود

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx
     namespace: web
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.27.3
           ports:
           - containerPort: 80
           resources:
             requests:
               memory: "64Mi"
               cpu: "50m"
             limits:
               memory: "128Mi"
               cpu: "100m"

4. عرّف Application في ArgoCD — ده الملف اللي بيربط Git بـ cluster:
   YAMLنسخ الكود

   apiVersion: argoproj.io/v1alpha1
   kind: Application
   metadata:
     name: nginx-app
     namespace: argocd
   spec:
     project: default
     source:
       repoURL: https://github.com/your-org/your-repo
       targetRevision: main
       path: manifests
     destination:
       server: https://kubernetes.default.svc
       namespace: web
     syncPolicy:
       automated:
         prune: true
         selfHeal: true
       syncOptions:
       - CreateNamespace=true

5. طبّق التعريف مرة واحدة وبس:

الأرقام والـ Trade-offs الحقيقية

قياس فعلي من فريق نشر 28 microservice على cluster EKS واحد، قبل وبعد التحويل لـ ArgoCD على مدار 90 يوم:

• زمن detect drift: من 6–48 ساعة (manual review أسبوعي) لـ 3 دقائق (auto sync).
• عدد incidents من config drift: من 11 شهرياً لـ صفر بعد 60 يوم.
• زمن rollback: من 4 دقائق (kubectl set image + verify + monitor) لـ 18 ثانية (git revert + auto sync).
• زمن onboarding مهندس جديد: من 9 أيام لـ يومين، لأن كل التاريخ في Git.

الـ trade-off هنا حقيقي ولازم تعرفه بالظبط. بتكسب: source of truth موحّد، rollback آني، audit trail كامل لكل تغيير، و RBAC على مستوى الـ Application. بتخسر: استهلاك ذاكرة 600–900MB من ArgoCD نفسه داخل الـ cluster، ومنحنى تعلّم 2–3 أسابيع لفريق صغير ليفهم الفرق بين Application و ApplicationSet و AppProject. الافتراض إن عندك أكتر من 5 services و3 مهندسين على الأقل بيعملوا deploy.

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

3 حالات لا تنفع فيها GitOps بالشكل ده، ولا تستحم تلبس التعقيد ده:

• Cluster واحد بـ 2 services ومهندس واحد. الـ overhead أكبر من الفائدة بكتير. kubectl apply + Helm كافيين تماماً، و ArgoCD هيكون ضريبة ذاكرة ووقت بدون عائد.
• تطبيقات stateful بـ schema migration حساسة. auto-sync ممكن يطبّق migration قبل ما الـ data layer يكون جاهز، أو يعمل rollback بيكسر FK constraints. خلّيها syncPolicy.automated: false ومع manual approval، أو فصلها في pipeline منفصل.
• ما عندكش Git workflow ناضج. لو فريقك بيعمل force push على main أو ما عندوش PR review حقيقي أو branch protection، GitOps هيـ amplify المشاكل بدل ما يحلها. اللي في Git هيتطبق على الـ cluster — كله، الكويس والوحش.

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

افتح cluster dev عندك دلوقتي ونفّذ الـ 6 خطوات على nginx فقط. متجربش على production في الجولة الأولى. لو نجح الـ sync، انقل بعدها service واحد production-grade لـ ArgoCD مع syncPolicy.automated.selfHeal: false في الأسبوع الأول لحد ما تطمن للـ behavior. بعدها فعّل selfHeal وقيس الـ MTTR على أول incident حقيقي يحصل.

المصادر

• OpenGitOps Principles v1.0 — opengitops.dev/principles
• ArgoCD Official Documentation — argo-cd.readthedocs.io/en/stable
• CNCF Annual Survey 2024 — cncf.io/reports/cncf-annual-survey-2024
• Argo Project on GitHub — github.com/argoproj/argo-cd
• Kubernetes Controller Pattern — kubernetes.io/docs/concepts/architecture/controller

]]>