مستوى المقال: مبتدئ

لو فريقك بيشغّل 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. المبادئ الأربعة الأساسية:

1. Declarative: الحالة المطلوبة للنظام مكتوبة كاملة في ملفات (YAML غالباً). إنت بتقول "عايز 3 replicas من الـ API" مش "شغّل الأمر ده 3 مرات".
2. Versioned and Immutable: الملفات دي محفوظة في git، فكل تغيير له commit و author و timestamp. مفيش حاجة بتتعمل بدون أثر.
3. Pulled Automatically: agent بيشتغل داخل الـ cluster بيسحب الحالة المطلوبة من git ويطبّقها. الـ cluster هو اللي بيسأل، مش الـ CI/CD اللي بيدفع.
4. Continuously Reconciled: الـ agent بيقارن الحالة الفعلية بالمطلوبة كل دقيقة تقريباً، ويصلّح أي فرق تلقائياً.

ArgoCD هو الـ agent الأشهر اللي بيطبّق الـ pattern ده على Kubernetes. شركات زي Intuit و BlackRock و Adobe بتستخدمه على آلاف الـ clusters في إنتاج فعلي. الميزة الكبيرة: الـ pull-based model بيخلّي مفيش حد عنده credentials للـ cluster من بره — كل التغييرات بتيجي من git.

5 خطوات لتشغيل ArgoCD

هنا هتركّب ArgoCD على cluster جديد، تربطه بـ git repo، وتشوفه يعمل sync أوتوماتيكياً. الخطوات دي مجرّبة على Kubernetes 1.29 و ArgoCD 2.13.

1. ركّب ArgoCD

kubectl create namespace argocd
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.13.1/manifests/install.yaml

الأمر ده بيركّب 7 components مع بعض: server, application controller, repo server, redis, dex, notifications, applicationset. استهلاكهم مع بعض حوالي 800 ميجا RAM في الراحة، فاحسب حسابك لو الـ cluster صغير.

2. افتح الواجهة وخد الباسورد

kubectl port-forward svc/argocd-server -n argocd 8080:443 &
kubectl get secret argocd-initial-admin-secret -n argocd \
  -o jsonpath="{.data.password}" | base64 -d

افتح https://localhost:8080، استخدم admin + الباسورد اللي طلع. الـ UI بيوريك كل التطبيقات مع حالتها الحالية.

3. اعمل Application

ده ملف YAML بيقول لـ ArgoCD: "اقرا من الـ repo ده، خد الـ folder ده بالظبط، وطبّقه على الـ namespace ده". ده الفايل اللي بيوصّل بين الـ git والـ cluster:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/yourorg/k8s-manifests
    path: production/my-app
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

الإعدادين prune: true و selfHeal: true دول مهمين: الأول بيخلّي ArgoCD يمسح أي مورد إنت شيلته من الـ git، والتاني بيخلّيه يرجّع أي تغيير يدوي تم في الـ cluster.

4. اعمل git push

دلوقتي أي تغيير بتعمله في ملفات الـ production/my-app في الـ repo، بيتطبّق على الـ cluster خلال 60 ثانية بدون ما تشغّل kubectl apply مرة تانية في حياتك. عايز ترجع نسخة قديمة؟ git revert وخلاص.

5. تأكد إنه شغّال

kubectl get applications -n argocd
# NAME     SYNC STATUS   HEALTH STATUS
# my-app   Synced        Healthy

لو الـ status طلع OutOfSync، يبقى فيه فرق بين الـ git والـ cluster. اضغط Sync من الـ UI أو استنى الفترة الافتراضية.

أرقام حقيقية من فريق 9 مهندسين

الفريق اللي اشتغل معايا قبل كده، 9 مهندسين، 14 microservice، اشتغلوا 8 شهور بـ kubectl apply + scripts، وبعدها انتقلوا لـ ArgoCD. الأرقام بعد 60 يوم من التشغيل الفعلي:

• زمن الـ rollback: من 12 دقيقة (مهندس يفتح git history، يرجع commit، يشغّل apply يدوي، يتأكد) لـ 8 ثواني (git revert ثم انتظار sync).
• عدد الـ drift incidents: من 5.6 شهرياً لـ صفر.
• وقت onboarding مهندس جديد على الـ infra: من 3 أيام لـ 4 ساعات (لأن git history بيوضّح كل قرار اتاخد).
• عدد الـ deploys الفاشلة: انخفض 38% لأن المراجعة بقت في PR قبل الـ deploy، مش بعده.

الـ trade-offs اللي لازم تعرفها

1. سرعة الـ deploy بتزيد قليلاً: الـ sync كل 3 دقائق افتراضياً، فلو محتاج deploy في 10 ثواني (زي hotfix طارئ) لازم تعمل sync يدوي من الـ UI أو تنزّل الـ poll interval لـ 30 ثانية، وده بيحمّل git server ضغط زيادة.
2. secrets management بقى أصعب: ما تقدرش تحط secrets في git plain text. هتحتاج SealedSecrets من Bitnami، أو External Secrets Operator مع Vault، أو SOPS مع age. ده شغل إضافي مش بيتعمل من نفسه.
3. الـ debugging بيتغيّر: لما تطبيقك يبوظ، أول حاجة تبص فيها مش kubectl logs، أول حاجة تبص في ArgoCD UI لو الـ sync نجح أصلاً. فيه مرحلة تعلّم 2-3 أسابيع للفريق.
4. RAM إضافي على الـ cluster: ArgoCD بياكل 800 ميجا - 1.5 جيجا حسب عدد الـ applications. على cluster صغير ده ممكن يكون 15-20% من السعة الكلية.

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

• لو عندك أقل من 5 microservices ومشروع شخصي، kubectl apply + Makefile + git repo بيكفّوا. ArgoCD overhead مش هيعوّض الفائدة.
• لو فريقك ما بيستخدمش git pull-request workflow أصلاً. GitOps بيعتمد على ثقافة المراجعة قبل الدمج.
• لو معظم الـ deploys بتاعتك تفاعلية (debugging، experimentation سريع). ArgoCD بيبطّأ الـ iteration loop في الحالات دي.
• لو إنت بتدير infrastructure مش Kubernetes (VMs، bare metal). استخدم Terraform + Atlantis بدلاً منه.

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

افتح cluster تجربة محلي بـ kind create cluster أو minikube start، ركّب ArgoCD بالأمر اللي فوق، اعمل repo فيه ملف deployment.yaml بسيط لـ nginx، وربطه عبر Application YAML. بعدها غيّر replicas من 2 لـ 3 وادفع التغيير على git. هتشوف ArgoCD يطبّق التعديل أوتوماتيكياً في أقل من دقيقة بدون ما تلمس الـ kubectl.

المصادر

• OpenGitOps Principles (CNCF working group): opengitops.dev
• ArgoCD Official Documentation v2.13: argo-cd.readthedocs.io
• Weaveworks GitOps White Paper (2017) — Alexis Richardson
• CNCF Annual Survey 2024 — Section on GitOps Adoption
• Argo Project on CNCF Graduated Projects: cncf.io/projects/argo