في المشهد سريع التطور للبنية التحتية السحابية الأصلية، لم يعد التحول من الإدارة الأمرية إلى الإدارة الإعلانية مجرد اتجاه، بل أصبح ضرورة. ومع نمو تعقيد العناقيد وتكرار عمليات النشر، تصبح التدخلات اليدوية عنق زجاجة كبير ومصدراً لـ "انحراف التكوين". وهنا تبرز GitOps كمعيار ذهبي. ومن خلال الجمع بين مرونة البنية التحتية الإعلانية ومزايا التعاون التي يوفرها Git، يمكن للمنظمات تحقيق تسليم تطبيقات قوي وقابل للتدقيق وتلقائي. ومن بين الأدوات المتاحة، رسخ Argo CD نفسه كمعيار فعلي للتسليم المستمر إلى Kubernetes.
يستكشف هذا المنشور التنفيذ العملي لـ Argo CD، حيث يرشد المطورين من المستوى المتوسط إلى المتقدم خلال عملية إنشاء سير عمل GitOps يضمن أن حالة العنقود المباشر تتطابق دائماً مع الحالة المطلوبة المحددة في Git.
فهم نموذج GitOps مع Argo CD
GitOps هي إطار تشغيلي يأخذ أفضل ممارسات DevOps المستخدمة في تطوير التطبيقات، مثل التحكم في الإصدارات، والتعاون، والامتثال، وCI/CD، ويطبقها على أتمتة البنية التحتية. يعمل Argo CD كأداة للتسليم المستمر تراقب العنقود وتوفق أي تغييرات تحدث. وعلى عكس خطوط أنابيب CI/CD التقليدية التي تدفع التغييرات إلى العنقود، يعمل Argo CD بناءً على نموذج "السحب". فهو يراقب باستمرار مستودع Git بحثاً عن التغييرات ويقوم بمزامنة العنقود تلقائياً لمطابقة ملفات التعريف المخزنة في ذلك المستودع.
يوفر هذا النهج القائم على السحب عدة مزايا:
- الأمان: لا تحتاج عقد العنقود إلى كتابة خارجية للوصول إلى أنظمة التحكم في المصدر.
- قابلية التدقيق: يتم تتبع كل تغيير عبر عمليات الإيداع في Git، مما يوفر سجلاً واضحاً لمن قام بتغيير ماذا ومتى.
- الاستعادة: في حالة حدوث كارثة، غالباً ما يكون التراجع إلى عملية إيداع سابقة في Git أسهل من التراجع عبر تاريخ معقد لـ CI/CD.
الخطوة 1: تثبيت Argo CD على العنقود الخاص بك
الخطوة الأولى في رحلتك مع GitOps هي تثبيت Argo CD. الطريقة الأكثر كفاءة للقيام بذلك هي استخدام Helm، مدير الحزم لـ Kubernetes. تأكد من تثبيت Helm وتكوينه للتفاعل مع العنقود المستهدف. سنقوم بإنشاء مساحة اسم مخصصة لـ Argo CD للحفاظ على عزل الموارد وإدارتها بسهولة.
أولاً، قم بإنشاء مساحة الاسم:
kubectl create namespace argocd
بعد ذلك، قم بتطبيق ملفات تعريف Argo CD. في بيئة الإنتاج، ستستخدم عادةً Helm لإدارة التحديثات بشكل أكثر فعالية، ولكن للإعداد الأولي، فإن ملف تعريف YAML مباشر:
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
بمجرد اكتمال التثبيت، تحقق من أن وحدات خوادم Argo CD تعمل:
kubectl get pods -n argocd
الخطوة 2: تعريض خادم Argo CD
للتفاعل مع Argo CD، تحتاج إلى الوصول إلى واجهته الويب وواجهته البرمجية (API). بشكل افتراضي، الخدمة متاحة فقط داخل العنقود. للتطوير المحلي أو الاختبار، يعد توجيه المنافذ (port-forwarding) أسرع طريقة:
kubectl port-forward svc/argocd-server -n argocd 8080:443
يمكنك بعد ذلك الانتقال إلى https://localhost:8080. يمكن استرداد كلمة مرور المسؤول الأولية من سر العنقود:
kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d
الخطوة 3: ربط مستودع Git الخاص بك
مع تشغيل Argo CD، تكون الخطوة الحرجة التالية هي ربطه بمصدر الحقيقة الخاص بك: مستودع Git الخاص بك. يجب أن يحتوي هذا المستودع على ملفات تعريف Kubernetes (ملفات YAML) أو مخططات Helm التي تحدد الحالة المطلوبة لتطبيقك.
في واجهة Argo CD، انتقل إلى الإعدادات > المستودعات. انقر على ربط المستودع باستخدام HTTPS (أو SSH، اعتماداً على متطلبات الأمان الخاصة بك). ستحتاج إلى تقديم عنوان URL HTTPS للمستودع الخاص بك. إذا كان المستودع يتطلب المصادقة، فستحتاج إلى إنشاء Secret يحتوي على بيانات الاعتماد وربطه أثناء عملية الربط. بالنسبة للمستودعات العامة، تكون هذه الخطوة فورية.
الخطوة 4: إنشاء مورد تطبيق
ربط المستودع ليس كافياً؛ يجب أن تخبر Argo CD بالأجزاء من المستودع التي يجب مراقبتها ومزامنتها. يتم ذلك عبر تعريف مورد مخصص (CRD) لـ Application. بينما يمكنك إنشاء هذا عبر واجهة المستخدم، فإن أفضل ممارسة هي تعريفه ككود.
إليك مثال على Application.yaml يشير إلى دليل يحتوي على ملفات تعريف Kubernetes القياسية:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/your-repo.git
targetRevision: main
path: k8s/overlays/production
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
المكونات الرئيسية لهذا التكوين هي:
- source: يحدد مكان وجود ملفات التعريف في Git.
- destination: يحدد أي عنقود ومساحة اسم سيتم النشر إليها.
- syncPolicy: هذا هو محرك الأتمتة. تعيين
automated.pruneإلىtrueيضمن إزالة الموارد المحذوفة من Git من العنقود. يضمنselfHealأن أي تغييرات يدوية تم إجراؤها مباشرة على العنقود سيتم تجاوزها لمطابقة Git.
قم بتطبيق ملف التعريف هذا على العنقود الخاص بك:
kubectl apply -f application.yaml
الخاتمة: قوة البنية التحتية الإعلانية
يغير تنفيذ GitOps مع Argo CD الطريقة التي تدير بها الفرق عناقيد Kubernetes. من خلال ترسيخ البنية التحتية في Git وأتمتة المزامنة، تقلل من الأخطاء البشرية، وتعزز الأمان، وتسرع دورات النشر. بينما يتطلب الإعداد الأولي مراعاة دقيقة لسياقات الأمان والشبكات، فإن الفوائد طويلة الأمد لبنية تحتية مستقرة وقابلة للتدقيق وقادرة على الشفاء الذاتي لا يمكن إنكارها. مع توسع نطاقك، فكر في دمج Argo CD مع خطوط أنابيب CI/CD لتحديث العلامات أو الفروع في مستودعك تلقائياً عند نجاح البناء، مما يكمل حلقة التسليم البرمجي المؤتمت بالكامل والمقود بواسطة Git.