التسليم المستمر لـ Kubernetes: خطوط أنابيب GitOps مع ArgoCD وFlux

لقد تطور التسليم المستمر على Kubernetes إلى ما هو أبعد من البساطة kubectl apply الأوامر. تتبنى الفرق الحديثة GitOps، وهو نموذج يستخدم Git كمصدر وحيد للحقيقة للبنية التحتية التعريفية وتكوين التطبيقات. من خلال الجمع بين مبادئ GitOps وأدوات مثل ArgoCD وFlux CD، يمكن للمؤسسات تحقيق خطوط نشر موثوقة وقابلة للتدقيق ومؤتمتة تتوسع عبر المجموعات والبيئات.

يغطي هذا الدليل البنية والإعداد وأفضل الممارسات لبناء خطوط أنابيب التسليم المستمر على مستوى الإنتاج على Kubernetes باستخدام نهج GitOps.

مبادئ GitOps

تم بناء GitOps على أربعة مبادئ أساسية تغير بشكل أساسي كيفية إدارة الفرق لعمليات النشر:

• التكوين التصريحي - يتم وصف الحالة المرغوبة بالكامل لنظامك بشكل صريح. بالنسبة إلى Kubernetes، يعني هذا بيانات YAML، أو مخططات Helm، أو تراكبات Kustomize المخزنة في Git.
• النسخة التي تسيطر عليها - Git بمثابة المصدر الوحيد للحقيقة. يمر كل تغيير عبر طلب سحب، مما يوفر مسارًا كاملاً للتدقيق ويتيح إمكانية التراجع بسهولة عن طريق التراجع عن الالتزامات.
• التسوية الآلية - يقوم الوكيل الذي يعمل في المجموعة بمقارنة الحالة المطلوبة في Git بشكل مستمر مع الحالة الفعلية في المجموعة ويقوم تلقائيًا بتسوية أي انحراف.
• المراقبة المستمرة - يقوم النظام بمراقبة كل من مستودع Git وحالة المجموعة بشكل مستمر، والتنبيه عند الاختلاف والتأكد من تطابق المجموعة دائمًا مع التكوين المعلن.

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

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

ArgoCD هي أداة GitOps الأكثر استخدامًا على نطاق واسع لـ Kubernetes. فهو يوفر واجهة مستخدم ويب قوية وCLI وAPI لإدارة عمليات نشر التطبيقات عبر المجموعات.

المكونات الأساسية

يتكون ArgoCD من عدة مكونات رئيسية تعمل معًا:

• خادم API - يعرض gRPC/REST API ويخدم واجهة مستخدم الويب. يتعامل مع المصادقة وRBAC والتكامل الخارجي.
• خادم المستودع - استنساخ مستودعات Git وإنشاء بيانات Kubernetes من مخططات Helm أو Kustomize أو YAML العادي.
• مراقب التطبيق - مراقبة التطبيقات قيد التشغيل باستمرار ومقارنة الحالة المباشرة بالحالة المطلوبة في Git.
• ريديس - يوفر التخزين المؤقت لخادم المستودع ووحدة التحكم في التطبيق.

تثبيت

انشر ArgoCD في مجموعتك باستخدام البيانات الرسمية أو مخطط Helm:

# Create namespace and install ArgoCD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Or via Helm
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --set server.service.type=LoadBalancer

تعريف التطبيقات

يستخدم ArgoCD Application مورد مخصص لتحديد ما سيتم نشره وأين. فيما يلي تعريف التطبيق النموذجي:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-web-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/k8s-manifests.git
    targetRevision: main
    path: apps/my-web-app/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

ال syncPolicy.automated يتيح القسم المزامنة التلقائية. ال prune يزيل الخيار الموارد التي لم تعد محددة في Git، بينما selfHeal يعود التغييرات اليدوية التي تم إجراؤها مباشرة إلى الكتلة.

القرص المضغوط Flux: نهج بديل

يتخذ Flux CD منهجًا معماريًا مختلفًا لـ GitOps. بدلاً من خادم مركزي مزود بواجهة مستخدم، يعمل Flux كمجموعة من وحدات التحكم Kubernetes التي يتعامل كل منها مع مشكلة معينة.

مكونات التدفق

• وحدة تحكم المصدر - إدارة مستودعات Git ومستودعات Helm ومصادر عناصر OCI.
• تخصيص وحدة التحكم - يطبق تراكبات Kustomize وبيانات YAML البسيطة.
• تحكم الخوذة - يدير إصدارات مخطط هيلم من خلال HelmRelease الموارد المخصصة.
• مراقب الإخطار - يتعامل مع الأحداث الواردة والصادرة، ويتكامل مع موفري Slack وTeams وwebhook.
• وحدات تحكم أتمتة الصور - مسح سجلات الحاويات وبيانات التحديث عند توفر صور جديدة.

تدفق التمهيد

# Bootstrap Flux on a cluster with a GitHub repository
flux bootstrap github \
  --owner=myorg \
  --repository=fleet-infra \
  --branch=main \
  --path=clusters/production \
  --personal

# Define a HelmRelease
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: nginx-ingress
  namespace: ingress-system
spec:
  interval: 5m
  chart:
    spec:
      chart: ingress-nginx
      version: "4.x"
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
        namespace: flux-system
  values:
    controller:
      replicaCount: 3
      metrics:
        enabled: true

ArgoCD مقابل Flux: متى تختار أيهما

يُعد ArgoCD مثاليًا عندما تحتاج إلى واجهة مستخدم ويب غنية للرؤية، وتعدد الإيجارات مع RBAC الدقيق، ومستوى إدارة مركزي. يتألق Flux في البيئات التي تفضل بنية خفيفة الوزن تعتمد على وحدة التحكم، أو تحتاج إلى إمكانات أتمتة الصور، أو تريد تكاملًا أعمق مع النظام البيئي Kubernetes API.

إدارة مخطط هيلم في GitOps

تعد مخططات Helm هي تنسيق التغليف الفعلي لتطبيقات Kubernetes. في سير عمل GitOps، تتطلب إدارة قيم Helm عبر البيئات تنظيمًا دقيقًا.

# Repository structure for multi-environment Helm management
k8s-manifests/
  base/
    my-app/
      Chart.yaml
      values.yaml          # Default values
      templates/
        deployment.yaml
        service.yaml
        ingress.yaml
  environments/
    dev/
      my-app/
        values.yaml        # Dev overrides
    staging/
      my-app/
        values.yaml        # Staging overrides
    production/
      my-app/
        values.yaml        # Production overrides

يدعم كل من ArgoCD وFlux Helm محليًا. يعرض ArgoCD المخططات من جانب الخادم من خلال خادم المستودع الخاص به، بينما يستخدم Flux Helm SDK مباشرة داخل وحدة التحكم Helm الخاصة به.

استراتيجيات النشر

يؤدي اختيار استراتيجية النشر الصحيحة إلى تقليل المخاطر وضمان عدم حدوث أي توقف عن العمل.

التحديثات المتداولة

استراتيجية Kubernetes الافتراضية. يتم استبدال البودات تدريجياً بإصدارات جديدة. تكوين maxSurge و maxUnavailable للتحكم في سرعة الطرح.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: myapp:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

عمليات النشر باللونين الأزرق والأخضر

قم بتشغيل بيئتين متطابقتين (الأزرق والأخضر). انشر الإصدار الجديد في البيئة غير النشطة، وتحقق منه، ثم قم بتبديل حركة المرور. وهذا يوفر التراجع الفوري عن طريق العودة إلى البيئة السابقة. يتم التنفيذ باستخدام محددات تصنيف الخدمة أو إدارة حركة مرور Istio.

عمليات نشر الكناري

قم بتوجيه نسبة صغيرة من حركة المرور تدريجيًا إلى الإصدار الجديد، وقم بزيادة النسبة مع نمو الثقة. تقوم أدوات مثل Flagger وArgo Rollouts بأتمتة التحليل الكناري من خلال الترويج المستند إلى المقاييس.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vsvc
            routes:
              - primary

التراجع الآلي

يجعل GitOps عمليات التراجع واضحة ومباشرة: ما عليك سوى التراجع عن التزام Git. ومع ذلك، توفر عمليات التراجع التلقائية بناءً على عمليات التحقق من السلامة شبكة أمان إضافية.

يدعم ArgoCD عمليات التراجع التلقائية من خلال نظام المزامنة والتقييم الصحي الخاص به. إذا دخل أحد التطبيقات إلى حالة متدهورة بعد المزامنة، فيمكن لـ ArgoCD الرجوع تلقائيًا إلى آخر حالة جيدة معروفة.

للحصول على سيناريوهات التراجع الأكثر تعقيدًا، يمكن لـ Argo Rollouts وFlagger تحليل مقاييس Prometheus، وإجراء اختبارات تلقائية، وإلغاء عمليات الطرح التي تظهر أداءً متدهورًا.

إدارة الأسرار بالأسرار المختومة

يمثل تخزين الأسرار في Git تحديًا كبيرًا لـ GitOps. تعمل الأسرار المختومة على حل هذه المشكلة عن طريق تشفير الأسرار التي لا يمكن فك تشفيرها إلا بواسطة وحدة التحكم التي تعمل في المجموعة المستهدفة.

# Install Sealed Secrets controller
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system

# Encrypt a secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=s3cure-p@ss \
  --dry-run=client -o yaml | \
  kubeseal --format yaml > db-credentials-sealed.yaml

الناتجة SealedSecret يمكن الالتزام بالمورد بأمان في Git. فقط وحدة تحكم الأسرار المختومة في المجموعة المستهدفة هي التي تحتفظ بالمفتاح الخاص اللازم لفك تشفيرها. تتضمن الأساليب البديلة External Secrets Operator (للسحب من AWS Secrets Manager، وHashiCorp Vault، وما إلى ذلك) وSOPS للتشفير على مستوى الملف.

مراقبة عمليات النشر

تعد رؤية حالة النشر أمرًا ضروريًا لخطوط أنابيب GitOps للإنتاج. تنفيذ المراقبة على مستويات متعددة:

• مقاييس ArgoCD - يعرض ArgoCD مقاييس Prometheus لحالة المزامنة والصحة ومدة التشغيل. قم بإنشاء لوحات معلومات Grafana لتتبع تكرار النشر ومعدلات الفشل.
• أحداث Kubernetes - مراقبة جدولة الكبسولة وسحب الصور وأحداث اختبار الاستعداد لاكتشاف المشكلات مبكرًا.
• فحوصات صحة التطبيق - قم بتكوين فحوصات السلامة المخصصة في ArgoCD باستخدام البرامج النصية Lua لتحديد معنى كلمة "صحي" لمواردك المحددة.
• تنبيه - دمج إشعارات ArgoCD مع Slack أو PagerDuty أو البريد الإلكتروني للتنبيه عند فشل المزامنة أو تدهور الصحة أو اكتشاف الانجراف.

# ArgoCD Notification ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  trigger.on-sync-failed: |
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [slack-notification]
  template.slack-notification: |
    message: |
      Application {{.app.metadata.name}} sync {{.app.status.operationState.phase}}.
      Revision: {{.app.status.sync.revision}}
  service.slack: |
    token: $slack-token
    channel: deployments

تسليم متعدد المجموعات

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

تعتبر وحدة التحكم ApplicationSet في ArgoCD قوية بشكل خاص لسيناريوهات المجموعات المتعددة. يمكنه إنشاء موارد التطبيق ديناميكيًا استنادًا إلى قوائم المجموعات أو أدلة Git أو أحداث طلب السحب.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-app-set
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
  template:
    metadata:
      name: 'my-app-{{name}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/myorg/k8s-manifests.git
        targetRevision: main
        path: 'apps/my-app/overlays/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: my-app

خاتمة

يوفر GitOps مع ArgoCD أو Flux CD أساسًا قويًا للتسليم المستمر لـ Kubernetes. من خلال التعامل مع Git كمصدر للحقيقة، وأتمتة التسوية، والاستفادة من استراتيجيات التسليم التقدمية، يمكن للفرق النشر بثقة والتعافي من حالات الفشل بسرعة. ابدأ بإعداد بسيط لمجموعة واحدة، وقم بإنشاء هيكل مستودع Git الخاص بك، واعتمد تدريجيًا أنماطًا متقدمة مثل عمليات نشر Canary، وإدارة المجموعات المتعددة، وسياسات التراجع التلقائية مع نضوج نظامك الأساسي.

يؤتي الاستثمار في البنية التحتية لـ GitOps ثماره من خلال الموثوقية المحسنة والاستجابة الأسرع للحوادث ومسارات التدقيق الكاملة وتجربة المطور التي تجعل عمليات النشر بسيطة مثل دمج طلب السحب.