GitOps مع ArgoCD وFlux

بنية ArgoCD والإعداد

18 دقيقة الدرس 3 من 30

بنية ArgoCD والإعداد

ArgoCD هو مشغّل GitOps الأكثر انتشاراً في الصناعة. قبل تثبيته، يجب أن تفهم آلياته الداخلية — وإلا فإن كل حادثة إنتاجية ستبدو كصندوق أسود. يتكون ArgoCD من ثلاثة مكونات رئيسية: Application Controller، وRepo Server، وAPI Server (إضافةً إلى واجهة المستخدم وـ Dex لإدارة SSO). لكل مكوّن مسؤولية محددة في حلقة المصالحة التي تُبقي الكتلة متزامنةً مع Git.

المكوّن الأول: Repo Server

Repo Server هو قارئ المصدر الحقيقي في ArgoCD. مسؤوليته هي استنساخ مستودعات Git، وتصيير المانيفستات باستخدام أي محرك قوالب تستخدمه التطبيقات (YAML خام، أو Helm، أو Kustomize، أو Jsonnet، أو مكوّنات مخصصة)، وإعادة كائنات Kubernetes المُصيَّرة كقائمة. وهو مُصمَّم عن قصد ليكون عديم الحالة (stateless) — لا يحتفظ ببيانات اعتماد الكتلة ولا يتحدث مباشرةً مع Kubernetes API. هذا العزل هو حاجز أمني: Repo Server المخترَق لا يستطيع بشكل مباشر تعديل الكتلة.

يُخزّن Repo Server المانيفستات المُصيَّرة في ذاكرة تخزين مؤقت محلية. عند تشغيل تحديث، يُعيد Repo Server استنساخ أو جلب آخر commit، ثم يُعيد التصيير ويُسلّم النتيجة إلى Application Controller. يمكنك تشغيل نسخ متعددة من Repo Server لتحقيق التوافر العالي — كل نسخة عديمة الحالة، لذا يُعدّ توسيعها آمناً.

نصيحة احترافية — تحديد موارد Repo Server: تصيير مخططات Helm مكثّفٌ على المعالج (CPU). على نطاق واسع (مئات التطبيقات)، يُصبح Repo Server هو نقطة الاختناق. حدّد طلبات وحدود CPU بوضوح، وشغّل نسختين على الأقل. تُشغّل شركات كـ Google وـ Stripe مجمّعات Repo Server مخصصة لتثبيتات ArgoCD الكبيرة متعددة المستأجرين.

المكوّن الثاني: Application Controller

Application Controller هو قلب ArgoCD. إنه كنترولر Kubernetes — يُشغّل حلقة مصالحة، تماماً مثل كنترولر Deployment الذي تعرفه. كل N ثانية (القيمة الافتراضية: 3 دقائق، يمكن ضبطها عبر --app-resync-period)، يقوم بما يلي:

قراءة الحالة المطلوبة من Repo Server (المانيفستات المُصيَّرة من Git).
قراءة الحالة الحية من الكتلة (عبر Kubernetes API).
مقارنة الحالتين.
إذا كانت syncPolicy.automated مُفعَّلة، يُطبّق الفرق. وإلا، يُصنّف التطبيق بـOutOfSync وينتظر إجراءً بشرياً أو استجابةً من CI.

يُقيّم Application Controller أيضاً حالة الصحة. يعرف كيف يقيّم صحة أنواع موارد Kubernetes المضمّنة (Deployment وStatefulSet وDaemonSet وService وIngress)، ويسمح لك بتعريف فحوصات صحة مخصصة بـ Lua لموارد CRD. لا يُعتبر التطبيق Healthy إلا عندما يكون كل مورد فرعي سليماً.

فكرة محورية — التجزيء عند التوسع: بشكل افتراضي، يُدير pod واحد من Application Controller جميع التطبيقات. عند الوصول إلى مئات التطبيقات، يصبح الكنترولر الواحد عنق زجاجة. يدعم ArgoCD controller sharding عبر متغير البيئة ARGOCD_CONTROLLER_REPLICAS — تمتلك كل شريحة قسماً من مجموعة التطبيقات. هكذا تُشغّل شركات مثل Intuit (مؤلفة ArgoCD الأصلية) آلاف التطبيقات على مستوى تحكم واحد.

المكوّن الثالث: API Server وـ Application CRD

يكشف API Server عن واجهة REST وـ gRPC التي تستخدمها أداة CLI وواجهة المستخدم وأنظمة CI الخارجية. يتولى المصادقة (المستخدمون المحليون، OIDC/Dex، LDAP)، وتطبيق RBAC عبر سياسات AppProject، وتوجيه الأوامر (sync، rollback، refresh) إلى Application Controller عبر نموذج Redis المشترك.

Application CRD هو وحدة العمل التعريفية في ArgoCD. كل تطبيق ArgoCD هو مورد Kubernetes مخصص من نوع Application في مجموعة API argoproj.io/v1alpha1. تحتوي مواصفاته على ثلاثة أقسام إلزامية:

source — مستودع Git، والمراجعة (فرع/وسم/SHA)، والمسار (أو اسم المخطط + الإصدار لمستودعات Helm).
destination — الكتلة المستهدفة (عبر URL أو داخل الكتلة) والـ namespace المُستهدف.
project — AppProject الذي يتحكم في RBAC والكتل والمستودعات المسموح بها لهذا التطبيق.

تدفق مصالحة ArgoCD: يُصيّر Repo Server المانيفستات من Git، ويُطبّق Application Controller الفروقات على الكتلة المستهدفة، وتظل Application CRD في etcd المصدر الوحيد لحالة مستوى التحكم.

تثبيت ArgoCD — إعداد جاهز للإنتاج

مانيفست التثبيت الرسمي هو نقطة بداية جيدة، لكن عمليات النشر الإنتاجية تحتاج بعض التعديلات قبل أن تكون جاهزة. فيما يلي تسلسل التثبيت القياسي متبوعاً بخطوات الضبط ما بعد التثبيت التي يتجاهلها معظم المبتدئين.

# 1. إنشاء الـ namespace
kubectl create namespace argocd

# 2. تطبيق مانيفست التثبيت الثابت (حدّد إصداراً بعينه — لا تستخدم latest في الإنتاج)
kubectl apply -n argocd -f \
  https://raw.githubusercontent.com/argoproj/argo-cd/v2.11.3/manifests/install.yaml

# 3. انتظار حتى تصبح جميع المكونات جاهزة
kubectl -n argocd rollout status deploy/argocd-server
kubectl -n argocd rollout status deploy/argocd-repo-server
kubectl -n argocd rollout status deploy/argocd-application-controller

# 4. استرجاع كلمة المرور الأولية (مُولَّدة تلقائياً ومُخزَّنة في Secret)
kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d; echo

# 5. إعادة توجيه المنفذ للوصول الأولي
kubectl -n argocd port-forward svc/argocd-server 8080:443 &

# 6. تسجيل الدخول عبر ArgoCD CLI
argocd login localhost:8080 --username admin --insecure

# 7. تغيير كلمة المرور فوراً (يجب حذف الـ Secret الأولي بعد ذلك)
argocd account update-password

# 8. حذف الـ Secret الأولي — لم يعد مطلوباً
kubectl -n argocd delete secret argocd-initial-admin-secret

خطأ إنتاجي شائع — لا تُعرّض argocd-server عبر نوع LoadBalancer قبل تفعيل TLS. التثبيت الافتراضي يعمل بدون TLS. تعريضه علناً (حتى لفترة قصيرة) يُسرّب بيانات اعتماد كتلتك لأي شخص يستطيع الوصول إليه. استخدم Ingress مع cert-manager، أو ALB داخلي، وفعّل OIDC SSO قبل الترقية للإنتاج.

أول Application CRD

بمجرد تثبيت ArgoCD، تُعرّف التطبيقات كـ YAML. المانيفست التالي يُوزّع مخططاً Helm من مستودع Git على namespace باسم staging، مع تفعيل المزامنة التلقائية والإصلاح الذاتي:

# file: apps/staging/payments.yaml
# طبّق بـ: kubectl apply -f apps/staging/payments.yaml -n argocd
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-staging
  namespace: argocd
  # يضمن Finalizer أن ArgoCD يحذف جميع الموارد الفرعية عند حذف التطبيق
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://github.com/example-org/platform-gitops
    targetRevision: HEAD        # تتبّع الفرع الرئيسي؛ استخدم SHA أو وسماً للنشرات الإنتاجية الثابتة
    path: helm/payments
    helm:
      valueFiles:
        - values.yaml
        - values-staging.yaml   # طبقة البيئة
  destination:
    server: https://kubernetes.default.svc   # نشر داخل الكتلة
    namespace: staging
  syncPolicy:
    automated:
      prune: true       # احذف الموارد المحذوفة من Git
      selfHeal: true    # أعد المزامنة إذا عدّل أحدهم الكتلة يدوياً
    syncOptions:
      - CreateNamespace=true
      - PrunePropagationPolicy=foreground
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

فكرة محورية — prune: true وselfHeal: true معاً يُطبّقان GitOps الصارم. بدون prune، تبقى الموارد المحذوفة من Git موجودةً في الكتلة. وبدون selfHeal، سيُنشئ تطبيق يدوي عبر kubectl apply أو helm upgrade من لابتوب المطوّر انحرافاً لا تُصلحه ArgoCD أبداً. كلا الخيارين مُعطَّلان افتراضياً — فعّلهما في بيئات غير الإنتاج أولاً، راقب السلوك، ثم فعّلهما في الإنتاج.

فحص حالة التطبيق عبر CLI

أداة argocd CLI هي الأداة الرئيسية لتشخيص الأعطال. هذه الأوامر تغطي أكثر الاستعلامات الإنتاجية شيوعاً:

# عرض جميع التطبيقات وحالة المزامنة والصحة
argocd app list

# عرض التفاصيل الكاملة: حالة المزامنة، الصحة، وقت آخر مزامنة، الصور المُوزَّعة
argocd app get payments-staging

# إجبار تحديث فوري من Git (يتجاوز cache فترة إعادة المزامنة)
argocd app get payments-staging --refresh

# تشغيل مزامنة يدوية
argocd app sync payments-staging

# عرض ما سيُغيّره ArgoCD قبل المزامنة (فرق جاف)
argocd app diff payments-staging

# التراجع إلى المراجعة المُزامَنة السابقة
argocd app rollback payments-staging 0   # 0 = خطوة واحدة للخلف؛ استخدم المعرّف من السجل
argocd app history payments-staging      # قائمة بأهداف التراجع المتاحة

# مراقبة تقدم المزامنة في الوقت الحقيقي
argocd app wait payments-staging --sync --health --timeout 120

فهم سير العمل البنية → الإعداد → الفحص هو الأساس لكل موضوعات ArgoCD المتقدمة: إدارة متعددة الكتل، وApp-of-Apps، وApplicationSets، وإدارة الأسرار. المكونات التي تعلّمتها هنا — Repo Server، وApplication Controller، وAPI Server، وApplication CRD — تُعيَّن مباشرةً على أنماط الأعطال التي ستُشخّصها في حوادث الإنتاج.