سير عمل CI/CD باستخدام GitOps - Kubernetes الممكنة بواسطة Azure Arc
ملاحظة
يستخدم سير العمل الموضح في هذا المستند GitOps مع Flux v1. GitOps with Flux v2 متاح الآن في المعاينة لمجموعات Kubernetes و Azure Kubernetes Service (AKS) التي تدعم Azure Arc ؛ تعرف على سير عمل CI/CD باستخدام GitOps مع Flux v2.
تضم عمليات نشر Kubernetes الحديثة العديد من التطبيقات والمجموعات والبيئات. باستخدام GitOps ، يمكنك إدارة هذه الإعدادات المعقدة بسهولة أكبر ، وتتبع الحالة المطلوبة لبيئات Kubernetes بشكل معلن باستخدام Git. باستخدام أدوات Git الشائعة لتعقب حالة نظام المجموعة، يمكنك زيادة المساءلة وتسهيل التحقيق في الأخطاء وتمكين التشغيل التلقائي لإدارة البيئات.
تشرح هذه النظرة العامة المفاهيمية GitOps كحقيقة واقعة في دورة حياة تغيير التطبيق الكاملة باستخدام Azure Arc وAzure Repos وAzure Pipelines. انتقل إلى مثال لتغيير تطبيق واحد إلى بيئات Kubernetes التي يتحكم فيها GitOps.
التصميم
ضع في اعتبارك تطبيقا تم نشره على بيئة Kubernetes واحدة أو أكثر.
ريبو التطبيق
يحتوي ريبو التطبيق على رمز التطبيق الذي يعمل عليه المطورون أثناء حلقتهم الداخلية. تعيش قوالب نشر التطبيق في هذا الريبو في شكل عام ، مثل Helm أو Kustomize. لا يتم تخزين القيم الخاصة بالبيئة. تستدعي التغييرات التي تطرأ على إعادة الشراء هذه خط أنابيب PR أو CI الذي يبدأ عملية النشر.
Container Registry
يحتوي سجل الحاوية على جميع صور الجهات الخارجية والأولى المستخدمة في بيئات Kubernetes. ضع علامة على صور تطبيق الطرف الأول باستخدام علامات قابلة للقراءة من قبل الإنسان والتزام Git المستخدم لإنشاء الصورة. قم بتخزين صور الجهات الخارجية مؤقتا لضمان الأمان والسرعة والمرونة. ضع خطة لاختبار تحديثات الأمان وتكاملها في الوقت المناسب. لمزيد من المعلومات، راجع دليل ACR استهلاك المحتوى العام والاحتفاظ به للحصول على مثال.
خط أنابيب العلاقات العامة
يتم إغلاق العلاقات العامة إلى ريبو التطبيق على تشغيل ناجح لخط أنابيب العلاقات العامة. يقوم خط الأنابيب هذا بتشغيل بوابات الجودة الأساسية ، مثل اختبارات البطانة والوحدة على رمز التطبيق. يختبر خط الأنابيب التطبيق وقوالب Dockerfiles و Helm المستخدمة للنشر في بيئة Kubernetes. يجب إنشاء صور Docker واختبارها ، ولكن لا يتم دفعها. حافظ على مدة خط الأنابيب قصيرة نسبيا للسماح بالتكرار السريع.
خط أنابيب CI
يقوم خط أنابيب CI للتطبيق بتشغيل جميع خطوات خط أنابيب العلاقات العامة ويوسع عمليات التحقق من الاختبار والنشر. يمكن تشغيل خط الأنابيب لكل التزام ، أو بإيقاع منتظم مع مجموعة من الالتزامات. في هذه المرحلة ، قم بإجراء اختبار التطبيق الذي يكون طويلا جدا بالنسبة لخط أنابيب العلاقات العامة. ادفع صور Docker إلى سجل الحاويات بعد الإنشاء استعدادا للنشر. يمكن وضع القالب المستبدل مع مجموعة من قيم الاختبار. يجب أن تكون الصور المستخدمة في وقت تشغيل الخدمة مبطنة ومبنية ومختبرة في هذه المرحلة. في بنية CI على وجه التحديد، يتم نشر القطع الأثرية لخطوة القرص المضغوط لاستهلاكها استعدادا للنشر.
Flux
Flux هي خدمة تعمل في كل مجموعة وهي مسؤولة عن الحفاظ على الحالة المطلوبة. تقوم الخدمة في كثير من الأحيان باستطلاع رأي GitOps repo بحثا عن التغييرات التي تطرأ على مجموعتها وتطبيقها.
خط أنابيب الأقراص المضغوطة
يتم تشغيل خط أنابيب القرص المضغوط تلقائيا بواسطة إصدارات CI الناجحة. يستخدم القوالب المنشورة سابقا ، ويستبدل قيم البيئة ، ويفتح PR إلى إعادة الشراء GitOps لطلب تغيير الحالة المطلوبة لواحد أو أكثر من مجموعات Kubernetes. يقوم مسؤولو نظام المجموعة بمراجعة العلاقات العامة لتغيير الحالة والموافقة على الدمج في Repo GitOps. ثم ينتظر خط الأنابيب اكتمال العلاقات العامة ، مما يسمح ل Flux بالتقاط تغيير الحالة.
GitOps ريبو
يمثل ريبو GitOps الحالة الحالية المطلوبة لجميع البيئات عبر المجموعات. يتم التقاط أي تغيير في هذا الريبو بواسطة خدمة Flux في كل مجموعة ونشره. يتم إنشاء العلاقات العامة مع تغييرات على الحالة المطلوبة ومراجعتها ودمجها. تحتوي هذه العلاقات العامة على تغييرات على كل من قوالب النشر وبيانات Kubernetes الناتجة التي تم تقديمها. تسمح البيانات المقدمة منخفضة المستوى بإجراء فحص أكثر دقة للتغييرات التي لا يمكن رؤيتها عادة على مستوى القالب.
مجموعات أجهزة كمبيوتر Kubernetes
تخدم مجموعة Kubernetes واحدة على الأقل ممكنة من Azure Arc البيئات المختلفة التي يحتاجها التطبيق. على سبيل المثال ، يمكن لمجموعة واحدة أن تخدم بيئة التطوير وضمان الجودة من خلال مساحات أسماء مختلفة. يمكن أن توفر المجموعة الثانية فصلا أسهل للبيئات وتحكما أكثر دقة.
مثال على سير العمل
كمطور تطبيقات ، أليس:
- يكتب رمز التطبيق.
- يحدد كيفية تشغيل التطبيق في حاوية Docker.
- تعريف القوالب التي تقوم بتشغيل الحاوية والخدمات التابعة في مجموعة Kubernetes.
على الرغم من أن أليس تعرف أن التطبيق يحتاج إلى القدرة على التشغيل في بيئات متعددة ، إلا أنها لا تعرف الإعدادات المحددة لكل بيئة.
لنفترض أن أليس تريد إجراء تغيير في التطبيق يغير صورة Docker المستخدمة في قالب نشر التطبيق.
- تقوم أليس بتغيير قالب النشر ، وتدفعه إلى فرع بعيد في ريبو التطبيق ، وتفتح PR للمراجعة.
- تطلب أليس من فريقها مراجعة التغيير.
- يقوم خط أنابيب العلاقات العامة بتشغيل التحقق من الصحة.
- بعد تشغيل خط أنابيب ناجح ، يقوم الفريق بتسجيل الخروج ويتم دمج التغيير.
- يتحقق خط أنابيب CI من صحة تغيير أليس ويكمل بنجاح.
- التغيير آمن للنشر إلى المجموعة، ويتم حفظ القطع الأثرية في تشغيل خط أنابيب CI.
- يدمج تغيير أليس ويشغل خط أنابيب القرص المضغوط.
- يلتقط خط أنابيب CD القطع الأثرية المخزنة بواسطة تشغيل خط أنابيب CI الخاص ب Alice.
- يستبدل خط أنابيب القرص المضغوط القوالب بقيم خاصة بالبيئة، ويقوم بترحيل أي تغييرات مقابل حالة الكتلة الحالية في ريبو GitOps.
- يقوم خط أنابيب القرص المضغوط بإنشاء PR إلى ريبو GitOps مع التغييرات المطلوبة في حالة نظام المجموعة.
- يقوم فريق أليس بمراجعة علاقاتها العامة والموافقة عليها.
- يتم دمج التغيير في الفرع المستهدف المقابل للبيئة.
- في غضون دقائق ، يلاحظ Flux تغييرا في ريبو GitOps ويسحب تغيير أليس.
- بسبب تغيير صورة Docker ، يتطلب جراب التطبيق تحديثا.
- يطبق التدفق التغيير على المجموعة.
- تختبر أليس نقطة نهاية التطبيق للتحقق من اكتمال النشر بنجاح.
ملاحظة
لمزيد من البيئات المستهدفة للنشر، يتكرر خط أنابيب القرص المضغوط عن طريق إنشاء علاقات عامة للبيئة التالية ويكرر الخطوات من 4 إلى 7. تحتاج العملية إلى موافقة إضافية لعمليات النشر أو البيئات الأكثر خطورة، مثل التغيير المرتبط بالأمان أو بيئة الإنتاج.
- بمجرد أن تتلقى جميع البيئات عمليات نشر ناجحة، يكتمل خط الأنابيب.
الخطوات التالية
تعرف على المزيد حول إنشاء اتصالات بين مجموعتك ومستودع Git كمورد تكوين باستخدام Kubernetes الذي تم تمكين Azure Arc له