DevOps and Infrastructure

تطبيق GitOps باستخدام ArgoCD لإطلاق التحديثات تلقائياً واكتشاف انحراف التكوين في Kubernetes

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

في هذا الدليل الشامل، سنستكشف كيفية تنفيذ ArgoCD لأتمتة إطلاق التحديثات في Kubernetes. سنغطي المفاهيم الأساسية، ونقدم خطوات تنفيذ عملية، ونناقش كيف تضمن قدرات اكتشاف انحراف التكوين الأصلية في ArgoCD أن حالة العنقود (Cluster) تتطابق دائماً مع مستودع Git الخاص بك.

فهم نموذج GitOps

غالباً ما تعتمد خطوط أنابيب CI/CD التقليدية على نموذج "الدفع" (Push)، حيث يقوم خادم البناء بدفع صور Docker مباشرة إلى مستودع الصور ثم يشغل عمليات النشر عبر النصوص البرمجية. وعلى الرغم من فعالية هذا النهج، إلا أنه قد يؤدي إلى انحراف التكوين، حيث تنحرف الحالة الفعلية للعنقود عن الحالة المقصودة المخزنة في نظام التحكم في الإصدارات.

يعكس GitOps هذا النموذج. فهو يعمل على آلية "السحب" (Pull). يعمل وكيل ArgoCD داخل عناقيد Kubernetes ويراقب مستودع Git باستمرار. عندما يقوم المطور بدفع تغيير إلى المستودع (مثل تحديث علامة الصورة)، يكتشف ArgoCD التغيير ويزامن العنقود ليتطابق مع تلك الحالة المطلوبة. يضمن هذا ما يلي:

  • يكون مستودع Git هو المصدر النهائي للحقيقة.
  • جميع القيد قابلة للتدقيق عبر سجل التزامات Git.
  • يتم اكتشاف التغييرات اليدوية التي تمت مباشرة على العنقود ويمكن تصحيحها تلقائياً.

إعداد ArgoCD

البدء باستخدام ArgoCD أمر بسيط. يمكنك تثبيته باستخدام مخطط Helm الرسمي أو الملف التعريفي (Manifest) المقدم. للبدء السريع في بيئة التطوير، يمكنك تطبيق الملف التعريفي مباشرة:

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

بعد التثبيت، تحتاج إلى الوصول إلى خادم ArgoCD. بشكل افتراضي، يعرض واجهة مستخدم ويب. يمكنك توجيه المنفذ (Port-forward) للوصول إليه محلياً:

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

يمكنك بعد ذلك الوصول إلى واجهة المستخدم على العنوان https://localhost:8080. يمكن استرداد كلمة المرور الأولية باستخدام الأمر:

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

تعريف التطبيقات وأتمتة الإطلاق

المكون الأساسي في ArgoCD هو مورد Application. هذا التعريف للمورد المخصص (CRD) يخبر ArgoCD أين يعيش كود التطبيق الخاص بك (Git)، وما هي الحالة المستهدفة، وأي عنقود سيتم النشر عليه.

لنقم بإنشاء ملف YAML بسيط لنشر تطبيق Nginx. يجب تخزين هذا الملف في مستودع Git الخاص بك جنباً إلى جنب مع كود التطبيق.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/guestbook-app.git
    targetRevision: HEAD
    path: kubernetes/base
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

تشمل التكوينات الرئيسية في هذا الملف التعريفي ما يلي:

  • المصدر (Source): يشير إلى مستودع Git الخاص بك والمسار المحدد الذي يحتوي على ملفات تعريف Kubernetes.
  • الوجهة (Destination): يحدد العنقود المستهدف والمساحة الاسم (Namespace).
  • سياسة المزامنة (Sync Policy): هذا أمر بالغ الأهمية. يضمن تعيين automated.prune: true إزالة الموارد التي تم حذفها في Git من العنقود. يتيح تعيين selfHeal: true اكتشاف انحراف التكوين وتصحيحه تلقائياً.

بمجرد دفع ملف Application.yml هذا إلى مستودع Git الخاص بك، سيكتشف ArgoCD المورد الجديد تلقائياً، ويقوم بمزامنته، وينشر التطبيق إلى عنقود Kubernetes الخاص بك.

إتقان اكتشاف انحراف التكوين

إحدى أقوى ميزات ArgoCD هي قدرتها على اكتشاف انحراف التكوين. يحدث الانحراف عندما يقوم شخص ما بإجراء تغييرات يدوية على عنقود Kubernetes (على سبيل المثال، باستخدام kubectl edit)، مما يتسبب في اختلاف الحالة الحية عن حالة Git.

مع تمكين selfHeal: true، سيقوم ArgoCD تلقائياً بالتراجع عن هذه التغييرات اليدوية لتتطابق مع مستودع Git. ومع ذلك، يمكنك أيضاً استخدام selfHeal: false فقط لإعلامك بوجود انحراف. في واجهة المستخدم، ستظهر التطبيقات المنحرفة بمؤشر حالة أصفر أو أحمر.

للبيئات التي تكون فيها التعديلات اليدوية ضرورية أحياناً، يمكنك تكوين موجات المزامنة (sync waves) أو استخدام ignoreDifferences في سياسة المزامنة. على سبيل المثال، إذا سمحت بالتوسع اليدوي للنسخ (replicas) ولكن تريد فرض بقية التكوين، يمكنك تجاهل التغييرات على spec.replicas:

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - IgnoreDifferences={"group":"apps","kind":"Deployment","jsonPointers":["/spec/replicas"]}

أفضل الممارسات للإنتاج

  1. البنية التحتية غير القابلة للتغيير (Immutable Infrastructure): لا تعدل الموارد الحية يدوياً أبداً. استخدم Git لجميع التغييرات.
  2. حماية الفروع (Branch Protection): استخدم طلبات السحب (Pull requests) لمراجعة التغييرات قبل وصولها إلى الفرع الرئيسي، الذي يراقبه ArgoCD.
  3. إدارة العناقيد المتعددة (Multi-Cluster Management): يتفوق ArgoCD في إدارة العناقيد المتعددة. استخدم cluster-secret لتسجيل العناقيد وإدارتها من لوحة تحكم واحدة.
  4. إدارة الأسرار (Secrets Management): تجنب تخزين البيانات الحساسة كنص واضح في Git. استخدم تشفير الأسرار المدمج في ArgoCD أو قم بالتكامل مع مديري الأسرار الخارجية مثل HashiCorp Vault أو AWS Secrets Manager باستخدام الإضافات (Plugins).

الخاتمة

يؤدي تنفيذ GitOps باستخدام ArgoCD إلى تحويل طريقة إدارة تطبيقات Kubernetes. من خلال الاستفادة من الإطلاق التلقائي واكتشاف انحراف التكوين القوي، تقلل من الأخطاء البشرية، وتحسن الأمان، وتكسب ثقة في حالة البنية التحتية الخاصة بك. مع انتقالك إلى إعدادات أكثر تعقيداً تتضمن عناقيد متعددة وبيئات متعددة، يوفر ArgoCD قابلية التوسع والرؤية اللازمة للحفاظ على السيطرة دون التضحية بالسرعة.

ابدأ بأتمتة نشر واحد، جرب سياسات المزامنة، وقم بتوسيع سير عمل GitOps الخاص بك تدريجياً. رحلة إدارة البنية التحتية المؤتمتة بالكامل تستحق الجهد المبذول.

Share: