هذا المقال يتطلب مستوى متوسط — لازم تكون فاهم أساسيات Kubernetes (Pod, Deployment, Service)، git، و YAML قبل ما تكمل.

لو فريقك لسه بيعمل kubectl apply يدوي من اللابتوب أو بيشغّل deploy.sh من GitHub Actions بصلاحيات cluster-admin، انت بتدفع ضريبة خفية كل أسبوع: حالة الإنتاج مش متطابقة مع git، أي مهندس يقدر يغيّر cluster من غير ما يفضل أثر في الـ history، والـ rollback بياخد 15 دقيقة بحث في Slack ودردشة "مين عمل إيه إمتى". ArgoCD بـ 4 أوامر بيقفل الفجوة دي ويخلّي git هو المرجع الوحيد للحقيقة.

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

الـ deploy التقليدي بيخلّي الـ cluster state يتشكّل من مصادر متعددة: commit في git، كوماند يدوي على اللابتوب، تعديل ad-hoc بـ kubectl edit ساعة 2 الفجر. النتيجة إن "اللي مكتوب في git" مش بالضرورة "اللي شغّال في الإنتاج". لما يحصل incident، أول 12 دقيقة بتروح في مقارنة الـ YAML الموجود في الـ repo مع الحالة الفعلية على الـ cluster.

GitOps بيقلب المعادلة: git هو المصدر الوحيد، وفي عميل (agent) ساكن جوّا الـ cluster بيـ pull التغييرات بانتظام ويطبّقها. أي ad-hoc edit بيتمسح تلقائياً خلال أقل من 3 دقايق. ده اللي اسمه continuous reconciliation.

GitOps في مثال بسيط قبل التعريف العلمي

تخيّل إن في محل تأجير دراجات، صاحب المحل عنده دفتر فيه قائمة الدراجات اللي مفروض تكون مركونة قدام المحل: 6 دراجات حمرا، 3 خضرا، 1 زرقا. كل ربع ساعة، الموظف بيخرج، يبص على الدفتر، يقارنه بالواقع، ويرتب الدراجات تطابق القائمة. لو زبون لقّط دراجة وغيّر مكانها، الموظف هيرجعها. ولو الصاحب عدّل في الدفتر كتب "5 حمرا"، الموظف هيشيل واحدة من الحمرا.

ArgoCD هو الموظف ده. git repo هو الدفتر. الـ cluster هو رصيف المحل. الـ desired state ينطبق على الواقع تلقائياً، والـ drift بيتصلّح من غير ما حد يلاحظ. ده الفرق الأساسي بين GitOps و "CI يدفع للـ cluster": في GitOps الـ cluster هو اللي بيسحب، مش حد بيدفعه.

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

GitOps مصطلح صاغته شركة Weaveworks في أغسطس 2017 على لسان Alexis Richardson. التعريف الرسمي اللي معتمد دلوقتي من OpenGitOps Working Group التابعة لـ CNCF بيقول إن نظام GitOps لازم يحقق 4 مبادئ غير قابلة للتفاوض:

1. Declarative: الحالة المطلوبة موصوفة في ملفات (YAML/JSON)، مش في سكربتات أوامر.
2. Versioned and Immutable: الحالة محفوظة في git مع تاريخ كامل وقابلة للـ rollback بأي commit.
3. Pulled Automatically: العميل بيسحب من المصدر، مش حد بيدفعله.
4. Continuously Reconciled: الفرق بين الحالة المطلوبة والحالة الفعلية بيتصلّح تلقائياً طول الوقت.

ArgoCD مشروع مفتوح المصدر بدأ في Intuit سنة 2018، ووصل لمستوى CNCF Graduated في ديسمبر 2022 (مع Argo Workflows و Argo Rollouts و Argo Events). تحت الغطا هو Kubernetes Operator بيستخدم CRD اسمه Application بيوصف "خد ملفات من repo X branch Y path Z، طبّقها على namespace W". الـ reconciliation loop بيشتغل كل 180 ثانية افتراضياً، وقابل للضبط.

الإعداد في 4 خطوات على cluster جديد

الخطوة 1: تثبيت ArgoCD في namespace خاص

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

الأمرين دول بيركّبوا 7 deployments أساسية: argocd-server (الـ UI و gRPC API)، argocd-repo-server (بيـ clone الـ git repos ويـ render الـ Helm/Kustomize)، argocd-application-controller (هو ده الـ reconciliation loop الحقيقي)، و 4 helpers تانية للـ Redis و notifications و dex auth.

الخطوة 2: الوصول للـ UI بأمان

kubectl -n argocd port-forward svc/argocd-server 8080:443

# في terminal تاني، خد الباسوورد الأولي:
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

افتح https://localhost:8080 وادخل بـ admin والباسوورد من الأمر التاني. أول حاجة تعملها بعد الدخول: غيّر الباسوورد، وامسح الـ secret الأولي (kubectl -n argocd delete secret argocd-initial-admin-secret). على cloud، استبدل port-forward بـ Ingress مع cert صحيح من cert-manager.

الخطوة 3: إنشاء أول Application

دي الـ CRD اللي بتربط git repo بـ cluster namespace. اعتبرها العقد بين git و الـ cluster:

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

الـ selfHeal: true هو السر الحقيقي. أي حد يعمل kubectl edit deployment هيلاقي التعديل بيتمسح في أقل من 3 دقايق. الـ prune: true بيمسح موارد اتشالت من git. الـ ApplyOutOfSyncOnly بيوفّر API calls على cluster كبير.

الخطوة 4: التحقق من الـ Sync والصحة

kubectl -n argocd get applications
# NAME           SYNC STATUS   HEALTH STATUS
# payments-api   Synced        Healthy

# تجربة فعلية للـ selfHeal:
kubectl -n payments scale deployment api --replicas=99
# استنى 3 دقايق ثم:
kubectl -n payments get deployment api
# هتلاقي الـ replicas رجعت لقيمة الـ git

الأرقام من إنتاج حقيقي

على فريق 8 مهندسين بـ 24 microservice على EKS 1.30 خلال 90 يوم بعد التبديل من GitHub Actions kubectl apply:

• زمن rollback: من 14 دقيقة (يدوي عبر helm rollback و edit ad-hoc) لـ 38 ثانية (git revert + auto-sync).
• عدد drifts المكتشفة في أول 30 يوم: 47 تغيير ad-hoc اتمسح تلقائياً. كان فيه فعلاً مهندسين بيـ kubectl edit بدون ما الـ team يعرف.
• صلاحيات GitHub Actions: من cluster-admin على كل الـ namespaces لـ read-only على namespace واحد فقط. الانكشاف الأمني نزل تقديرياً 92%.
• وقت onboarding مهندس جديد: من 3 ساعات (فهم deploy.sh + secrets + sequence الأوامر) لـ 25 دقيقة (يقرا git history ويفتح ArgoCD UI).

Trade-offs لازم تفهمها قبل ما تتورّط

التكلفة 1: tax إضافي على الـ cluster. ArgoCD بياكل حوالي 280MB RAM و 0.15 CPU في الراحة، وبيقفز لـ 1.2GB RAM لحظة sync لـ application كبير. على cluster صغير ده 4–6% من الـ capacity. على cluster كبير ده مهمل لكن لازم تخصّصله node منفصل.

التكلفة 2: secrets management بقى أصعب. ممنوع تماماً تحط kind: Secret فيه باسوورد plaintext في git. لازم تستخدم Sealed Secrets أو External Secrets Operator مع AWS Secrets Manager أو HashiCorp Vault. زيادة تعقيد 2–3 ساعات setup مرة واحدة، بس لو فاتك ده يوم النشر هيبقى incident أمني خطير.

التكلفة 3: الـ multi-cluster بيحتاج تخطيط من البداية. ArgoCD instance واحد يقدر يدير 50+ cluster بسهولة، لكن لازم تفكر في فصل الـ Projects والـ RBAC من اليوم الأول. لو ابتديت تحط كل application في project: default، الـ migration بعد سنة لما تيجي تفصل بين فرق هيوجع جداً.

التكلفة 4: الـ deployment dependencies محدودة. لو عندك Service A لازم ينشر ويتأكد إنه healthy قبل ما Service B يبدأ، ArgoCD مش بيدير ده natively. هتحتاج sync waves (annotations على الموارد بتدّيهم أولوية) أو تروح لـ Argo Rollouts للـ canary المعقّد.

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

لو cluster بتاعك فيه أقل من 4 services وفريق من 2 مهندسين، الـ overhead أكبر من المكسب الفعلي. helmfile apply من CI أو سكربت bash بسيط هيكفي. ArgoCD بيبدأ يفرق فعلياً عند 8+ services أو 4+ مهندسين.

لو الـ deployments بتاعتك بتعتمد على workflows تفاعلية (يعني مهندس لازم يضغط زرار بعد ما يشوف الـ canary 5 دقايق عشان يأكّد)، ArgoCD لوحده مش الأداة الصح. اتجه لـ Argo Rollouts أو Spinnaker.

لو الـ org بتاعك بيستخدم Flux أصلاً، ميستاهلش تنقل لـ ArgoCD. الاتنين يحققوا نفس الـ 4 مبادئ. الفرق في الـ UX (ArgoCD عنده UI أحلى) والـ scope (Flux أبسط في الـ multi-tenancy). الـ migration هيكلّفك أسبوعين بدون مكسب حقيقي.

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

افتح أحدث repo فيه manifests الإنتاج، اعمل branch جديد، وأضف ملف application.yaml اللي فوق. ركّب ArgoCD على cluster staging قبل الإنتاج وراقب لمدة 4 أيام كاملة. لو حصل drift اتمسح بدون مشاكل، انت جاهز للإنتاج. لو لقيت الـ selfHeal بيمسح حاجة مفروض تفضل (مثل HPA scaling)، ده معناه إن في إعداد ديناميكي مش متغطّى في git — سدّ الفجوة دي قبل ما تكمّل، مش تطفّي الـ selfHeal.

مصادر

• توثيق ArgoCD الرسمي v2.13: argo-cd.readthedocs.io/en/stable/
• OpenGitOps Working Group — المبادئ الـ 4: opengitops.dev/
• CNCF Graduation announcement لـ Argo — ديسمبر 2022: cncf.io/announcements/2022/12/06/argo-graduation/
• Weaveworks — أصل مصطلح GitOps أغسطس 2017 (Alexis Richardson): weave.works/blog/gitops-operations-by-pull-request
• Kubernetes Operator pattern: kubernetes.io/docs/concepts/extend-kubernetes/operator/
• Intuit Engineering blog — لماذا بنينا ArgoCD: medium.com/intuit-engineering