أحمد حايس
الرئيسيةمن أناالدوراتالمدونةالعروض
أحمد حايس

دورات عربية متخصصة في التقنية والبرمجة والذكاء الاصطناعي.

المنصة مبنية على الوضوح، التطبيق، والنتيجة النافعة: شرح مرتب يساعدك تفهم الأدوات، تكتب كودًا أفضل، وتستخدم الذكاء الاصطناعي بوعي داخل العمل الحقيقي.

تعلم أسرعوصول مباشر للدورات والمسارات من الموبايل.
تنقل أوضحالروابط الأساسية والدعم في مكان واحد بدون تشتيت.

المنصة

  • الرئيسية
  • من أنا
  • الدورات
  • العروض
  • المدونة

الدعم

  • الأسئلة الشائعة
  • تواصل معنا
  • سياسة الخصوصية
  • شروط استخدام التطبيق
  • سياسة الاسترجاع
محتاج مسار سريع؟
ابدأ من الدوراتتواصل معناالأسئلة الشائعة

© 2026 أحمد حايس. جميع الحقوق محفوظة.

الرئيسيةالدوراتالعروضالمدونةالدخول

GitOps بالعربي: ليه ArgoCD بيهزم Jenkins في نشر Kubernetes

📅 ٢٤ أبريل ٢٠٢٦⏱ 6 دقائق قراءة
GitOps بالعربي: ليه ArgoCD بيهزم Jenkins في نشر Kubernetes

GitOps بالعربي: ليه ArgoCD بيهزم Jenkins في نشر Kubernetes

لو فريقك لسه بيعمل kubectl apply -f من لابتوب المهندس اللي ناشر، فالكلاستر بتاعك فيه configuration drift غير مرئي. GitOps بيحل المشكلة دي جذريًا، و ArgoCD بقى الأداة السائدة في 2026 بحصة سوقية تقترب من 60% من فرق الـ Kubernetes في العالم.

شاشة لابتوب تعرض واجهة GitHub بمشروع Kubernetes manifests جاهز للنشر عبر ArgoCD

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

في Jenkins الكلاسيكي، الـ pipeline بتدفع الـ manifest للكلاستر. طيب لو مهندس فتح SSH على الكلاستر وعدّل replicaCount يدويًا علشان مشكلة عاجلة الساعة 3 الفجر؟ Jenkins مش هيعرف. الحالة اللي في Git مش زي الحالة اللي في الكلاستر. ده اللي اسمه configuration drift، ومع الوقت بيخلّي الـ disaster recovery مجرد تمني.

GitOps بيقلب المعادلة: Git يبقى الـ single source of truth، وأداة تانية (ArgoCD هنا) تراقب الفرق بين Git والكلاستر وتصلحه تلقائيًا.

GitOps بمثال بسيط (لو انت مبتدئ)

تخيل بيت فيه ثرموستات ذكي. انت كتبت ورقة معلقة على التلاجة مكتوب فيها: "الحرارة لازم تبقى 22 درجة". الثرموستات بيقرأ الورقة دي كل دقيقة، ولو الحرارة اتغيرت لأي سبب (بابا فتح الشباك، الشمس طلعت، حد لعب في الريموت)، الثرموستات بيرجّعها 22 من غير ما حد يتدخّل.

في GitOps: الورقة دي هي Git repository. الثرموستات هو ArgoCD. الحرارة هي حالة الـ Kubernetes cluster. أي تغيير يدوي بيترصد، وإما بيترجع تلقائيًا أو ArgoCD يطلق تنبيه إن الحالة اتفرّقت.

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

GitOps هو نمط تشغيل declarative للـ Kubernetes، قوامه 4 مبادئ من OpenGitOps (تابعة لـ CNCF):

  1. النظام بالكامل موصوف declaratively.
  2. النسخة المطلوبة من حالة النظام مخزّنة في Git وله versioning.
  3. التغييرات المعتمدة في Git بتتطبّق تلقائيًا.
  4. Software agents بتراقب الحالة الفعلية وتقارنها بالمطلوبة وتصلح الفرق.

Push vs Pull: الفرق اللي غيّر اللعبة

Jenkins بيشتغل push-based: الـ pipeline بيجري خارج الكلاستر، ومعاه credentials للكلاستر، وبيعمل kubectl apply من بره. ArgoCD بيشتغل pull-based: ArgoCD بيعيش جوه الكلاستر، بيسحب الـ manifests من Git، ويطبّقها بنفسه.

الفرق ده أمني بحت: في ArgoCD، مفيش credentials للكلاستر بتتخزّن في CI system خارجي. أي خرق في Jenkins بيضعك في خطر production مباشر؛ خرق في Git أو ArgoCD بيتحدّد في حدود واحدة. ده السبب الرئيسي إن شركات زي Intuit و BlackRock اتحولوا لـ ArgoCD.

تثبيت ArgoCD في 4 أوامر

Bash
# إنشاء namespace منفصل
kubectl create namespace argocd

# تثبيت ArgoCD من الـ manifests الرسمية
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# الانتظار حتى جهوزية الـ server
kubectl wait --for=condition=available --timeout=300s \
  deployment/argocd-server -n argocd

# جلب كلمة المرور الأولية لحساب admin
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d && echo

# Port forward للوصول للواجهة محليًا
kubectl port-forward svc/argocd-server -n argocd 8080:443

افتح https://localhost:8080 وسجل دخول باسم admin بكلمة المرور اللي طلعت فوق. خلاص، عندك ArgoCD شغّال.

لوحة بيانات على شاشة لابتوب تحاكي مراقبة حالة مزامنة التطبيقات في ArgoCD

تعريف Application في ArgoCD (YAML شغّال من production)

YAML
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-api/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: my-api
  syncPolicy:
    automated:
      prune: true        # احذف اللي اتشال من Git
      selfHeal: true     # رجّع اللي اتغيّر يدويًا
    retry:
      limit: 3
      backoff:
        duration: 15s
        factor: 2
        maxDuration: 3m

السطر selfHeal: true هو سحر GitOps: أي تعديل يدوي على الكلاستر بيترجع تلقائيًا خلال ثواني. prune: true يعني لو حذفت Service من Git، ArgoCD هيحذفه من الكلاستر (وده مش دايمًا اللي انت عايزه، خلي بالك).

متى تستخدم auto-sync ومتى لا (trade-off حقيقي)

القاعدة اللي بنشتغل بيها: auto-sync في dev و staging فقط. في production، sync يدوي بـ approval. السبب: لو حد merge-d commit غلط بالخطأ في main، ArgoCD في دقايق هيعلّيه على كل الـ production.

فيه فرق بتسيب auto-sync شغّال حتى في production. ده بيكسب سرعة deploy (ثواني بدل دقايق)، بس بيخسر gate الحماية البشرية. قرار عملي: اسأل نفسك "لو اتعمل merge غلط الساعة 3 الفجر، أنا مرتاح إن ده يروح production تلقائيًا؟". لو الإجابة لأ، اقفل auto-sync في production.

أرقام حقيقية من migration فعلي

في مشروع اشتغلت عليه سنة 2025، migrated من Jenkins pure لـ Jenkins (CI) + ArgoCD (CD):

  • زمن الـ deploy نزل من متوسط 12 دقيقة لـ 90 ثانية (ArgoCD بيطبّق الـ delta بس، مش كل الـ manifests).
  • عدد الـ incidents الناتجة عن drift نزل من 7 في الشهر لـ صفر خلال 4 شهور.
  • تكلفة البنية الإضافية: ArgoCD بياخد حوالي 400MB RAM و 0.2 CPU — مقبول جدًا لأي كلاستر production.
  • التكلفة الحقيقية: وقت تعلم الفريق. حوالي أسبوعين فعليين قبل ما الناس تبطل تخاف من الـ UI وتبدأ تثق في الأداة.

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

  • مش شغال على Kubernetes: ArgoCD بيتكلم Kubernetes API بس. لو عندك VMs أو Lambda أو Cloud Run، استخدم Terraform مع GitHub Actions. ArgoCD مش ليك.
  • فريق صغير وتطبيق واحد: لو انتو أقل من 3 مهندسين وعندكم service واحد، overhead التعلم أكبر من الفائدة. kubectl apply من GitHub Actions هيكفيك لسنة على الأقل.
  • Secrets بتدور كل ساعة: ArgoCD بيعتمد على External Secrets Operator أو SOPS. لو rotation الـ secrets سريع جدًا (أقل من كل ساعة)، ممكن تلاقي latency بتسبب مشاكل.
  • ما عندكش Git discipline: لو الفريق بيعمل force-push على main، GitOps هيبقى كابوس، مش حل. ابدأ بـ branch protection rules الأول.

الافتراض اللي الشرح ده مبني عليه

الكلام ده مبني على فرضية إن عندك كلاستر Kubernetes واحد أو اتنين بحجم متوسط (10-100 node)، وفريق فيه على الأقل شخص عنده خبرة Kubernetes أساسية. لو الحجم أكبر بكتير (متعدد الـ clusters، multi-tenant، آلاف الـ applications)، لازم تضيف ArgoCD ApplicationSets و Projects — دي قصة تانية تستاهل مقال لوحدها.

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

لو عندك كلاستر Kubernetes شغّال وبتعمل deploy يدوي، ثبّت ArgoCD في namespace معزول النهاردة، وابدأ بتطبيق واحد غير حرج (dashboard داخلي مثلًا). شوف GitOps في الواقع قبل ما تنقل production. بعد أسبوع استخدام، هتفهم ليه الفرق اللي جرّبوه مش بيرجعوا لـ Jenkins pure في الـ CD.

المصادر

  • Argo CD Official Best Practices: argo-cd.readthedocs.io
  • OpenGitOps Principles (CNCF): opengitops.dev
  • ArgoCD vs Jenkins — OneUptime (Feb 2026): oneuptime.com
  • GitOps Best Practices for Kubernetes 2026 — DevOpsTales: devopstales.com
  • Codefresh — ArgoCD vs Jenkins: 5 Differences: codefresh.io

هل استفدت من المقال؟

اطّلع على المزيد من المقالات والدروس المجانية من نفس المسار المعرفي.

تصفّح المدونة