سير عمل CI/CD باستخدام GitOps (Flux v2)

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

توضح هذه المقالة كيف يتناسب GitOps مع دورة حياة تغيير التطبيق الكامل باستخدام Azure Arc وAzure Repos وAzure Pipelines. كما يوفر مثالا على تغيير تطبيق واحد لبيئات Kubernetes التي تسيطر عليها GitOps.

بناء الأنظمة

يوضح هذا الرسم التخطيطي سير عمل CI/CD لتطبيق تم نشره في بيئات Kubernetes واحدة أو أكثر.

مستودع التعليمات البرمجية للتطبيق

يحتوي مستودع التطبيق على التعليمات البرمجية للتطبيق التي يعمل عليها المطورون أثناء الحلقة الداخلية الخاصة بهم. تعيش قوالب توزيع التطبيق في هذا المستودع في نموذج عام، مثل Helm أو Kustomize. لا يتم تخزين القيم الخاصة بالبيئة في المستودع.

تستدعي التغييرات التي يتم إجراؤها على هذا المستودع مسار PR أو CI الذي يبدأ عملية النشر.

سجل الحاوية

يحتفظ سجل الحاوية بجميع الصور الأولى والثالثة المستخدمة في بيئات Kubernetes. يتم وضع علامة على صور تطبيق الطرف الأول بعلامات يمكن للبشر قراءتها وتثبيت Git المستخدم لبناء الصورة. قد يتم تخزين صور الجهات الخارجية مؤقتا للمساعدة في الأمان والسرعة والمرونة. قم بتعيين خطة لاختبار تحديثات الأمان وتكاملها في الوقت المناسب.

لمزيد من المعلومات، راجع كيفية استهلاك المحتوى العام والحفاظ عليه باستخدام مهام سجل حاويات Azure.

البنية الأساسية لبرنامج ربط العمليات التجارية ل PR

يتم وضع طلبات السحب من المطورين التي تم إجراؤها إلى مستودع التطبيق على تشغيل ناجح لمسار PR. يقوم هذا المسار بتشغيل بوابات الجودة الأساسية، مثل التحليل واختبارات الوحدة على التعليمات البرمجية للتطبيق. يختبر المسار التطبيق وقوالب Dockerfiles وHelm المستخدمة للتوزيع في بيئة Kubernetes. يجب إنشاء صور Docker واختبارها، ولكن لا يتم دفعها. احتفظ بمدة المسار قصيرة نسبيا للسماح بالتكرار السريع.

تدفق CI

تقوم البنية الأساسية لبرنامج ربط العمليات التجارية CI للتطبيق بتشغيل جميع خطوات مسار PR، وتوسيع عمليات التحقق من الاختبار والنشر. يمكن تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية لكل تثبيت إلى رئيسي، أو يمكن تشغيله بوتيرة منتظمة مع مجموعة من التثبيتات.

في هذه المرحلة، يمكن إجراء اختبارات التطبيق المستهلكة جدا لمسار PR، بما في ذلك:

• دفع الصور إلى سجل الحاوية
• إنشاء الصور وتحليلها واختبارها
• إنشاء قالب لملفات YAML الأولية

بنهاية بناء CI، يتم إنشاء البيانات الاصطناعية. يمكن استخدام هذه البيانات الاصطناعية بواسطة خطوة CD للاستهلاك استعدادا للنشر.

ملحق نظام مجموعة Flux

Flux هو عامل يعمل في كل مجموعة كملحق نظام المجموعة. ملحق نظام مجموعة Flux هذا مسؤول عن الحفاظ على الحالة المطلوبة. يستقصي العامل مستودع GitOps في فاصل زمني محدد من قبل المستخدم، ثم يقوم بتسوية حالة نظام المجموعة مع الحالة المعلن عنها في مستودع Git.

لمزيد من المعلومات، راجع البرنامج التعليمي: نشر التطبيقات باستخدام GitOps مع Flux v2.

تدفق CD

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

مستودع GitOps

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

موصل GitOps

ينشئ GitOps الاتصال or اتصالا بين عامل Flux ومسار GitOps Repository/CD. أثناء تطبيق التغييرات على نظام المجموعة، يقوم Flux بإعلام موصل GitOps بكل تغيير في المرحلة وإجراء فحص السلامة. يعمل هذا المكون كمحول. وهو يفهم كيفية الاتصال بمستودع Git، ويحدث حالة تثبيت Git بحيث يكون تقدم المزامنة مرئيا في مستودع GitOps. عند انتهاء النشر (سواء نجح أو فشل)، يقوم الموصل بإعلام مسار CD بالمتابعة حتى يتمكن المسار من تنفيذ أنشطة ما بعد التوزيع، مثل اختبار التكامل.

مجموعات أجهزة كمبيوتر Kubernetes

تخدم مجموعة Kubernetes واحدة على الأقل ممكنة ل Azure Arc أو مجموعة Azure Kubernetes Service (AKS) البيئات المختلفة التي يحتاجها التطبيق. على سبيل المثال، يمكن أن تخدم مجموعة واحدة كلا من بيئة التطوير و QA من خلال مساحات أسماء مختلفة. يمكن أن توفر المجموعة الثانية فصلا أسهل للبيئات وتحكما أكثر دقة.

مثال على سير العمل

بصفتها مطور تطبيق، أليس:

• كتابة التعليمات البرمجية للتطبيق.
• تحديد كيفية تشغيل التطبيق في حاوية Docker.
• تعريف القوالب التي تقوم بتشغيل الحاوية والخدمات التابعة في مجموعة Kubernetes.

تريد Alice التأكد من أن التطبيق لديه القدرة على التشغيل في بيئات متعددة، ولكنها لا تعرف الإعدادات المحددة لكل بيئة.

افترض أن Alice تريد إجراء تغيير تطبيق يغير صورة Docker المستخدمة في قالب نشر التطبيق.

1. تغير Alice قالب النشر، وتدفعه إلى فرع بعيد يسمى alice في Application Repo، وتفتح طلب سحب للمراجعة مقابل main الفرع.

2. تطلب Alice من فريقها مراجعة التغيير.

   • يقوم مسار PR بتشغيل التحقق من الصحة.
   • بعد تشغيل مسار PR بنجاح والموافقة على الفريق، يتم دمج التغيير.

3. ثم تبدأ البنية الأساسية لبرنامج ربط العمليات التجارية CI وتتحقق من صحة تغيير Alice وتكتمل بنجاح.

   • التغيير آمن للنشر إلى نظام المجموعة، ويتم حفظ البيانات الاصطناعية في تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية CI.

4. يؤدي تشغيل مسار CI الناجح إلى تشغيل مسار CD.

   • تلتقط البنية الأساسية لبرنامج ربط العمليات التجارية CD البيانات الاصطناعية المخزنة بواسطة تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية CI الخاصة ب Alice.
   • يستبدل مسار CD القوالب بقيم خاصة بالبيئة ويرحل أي تغييرات مقابل حالة نظام المجموعة الموجودة في مستودع GitOps.
   • ينشئ مسار CD طلب سحب مقابل فرع الإنتاج من GitOps Repo مع التغييرات المطلوبة في حالة نظام المجموعة.

5. يراجع فريق Alice طلب السحب الخاص بها ويوافق عليه.

   • يتم دمج التغيير في الفرع الهدف المقابل للبيئة.

6. في غضون دقائق، يلاحظ Flux تغييرا في مستودع GitOps ويسحب تغيير Alice.

   • بسبب تغيير صورة Docker، يتطلب جراب التطبيق تحديثا.
   • يطبق Flux التغيير على نظام المجموعة.
   • يقوم Flux بالإبلاغ عن حالة النشر مرة أخرى إلى مستودع GitOps عبر GitOps الاتصال or.

7. يقوم مسار CD بتشغيل الاختبارات التلقائية للتحقق من اكتمال النشر الجديد بنجاح ويعمل كما هو متوقع.

   إشعار

   بالنسبة للبيئات الإضافية المستهدفة للتوزيع، يتكرر مسار CD عن طريق إنشاء طلب سحب للبيئة التالية ويكرر الخطوات من 4 إلى 7. تحتاج العملية العديد من الموافقة الإضافية على عمليات النشر أو البيئات الأكثر خطورة، مثل التغيير المتعلق بالأمان أو بيئة الإنتاج.

8. عندما تتلقى جميع البيئات عمليات نشر ناجحة، تكتمل البنية الأساسية لبرنامج ربط العمليات التجارية.

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

• اطلع على برنامجنا التعليمي لتنفيذ CI/CD باستخدام GitOps.
• تعرف على إنشاء اتصالات بين مجموعتك ومستودع Git باستخدام تكوينات Flux.