تنفيذنا للنشر المستمر على منصة العميل

لقد قمنا في True Engineering بإعداد عملية للتسليم المستمر للتحديثات إلى خوادم العملاء ونريد مشاركة هذه التجربة.

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

سنتحدث في هذا المقال عن جميع مراحل عملية النشر المستمر (CD) أو تسليم التحديثات إلى النظام الأساسي للعميل:

1. كيف تبدأ هذه العملية؟
2. المزامنة مع مستودع Git الخاص بالعميل،
3. تجميع الواجهة الخلفية والواجهة الأمامية،
4. النشر التلقائي للتطبيق في بيئة الاختبار،
5. النشر التلقائي إلى Prod.

سنشارك تفاصيل الإعداد على طول الطريق.

1. ابدأ القرص المضغوط

يبدأ النشر المستمر بقيام المطور بدفع التغييرات إلى فرع الإصدار الخاص بمستودع Git الخاص بنا.

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

قمنا بتنظيم العمل من خلال مستودع واحد لعدة أسباب:

• سهولة التطوير - يتم تطوير التطبيق بشكل نشط، حتى تتمكن من العمل مع جميع التعليمات البرمجية في وقت واحد.
• خط أنابيب CI/CD واحد يضمن اجتياز التطبيق كنظام واحد لجميع الاختبارات ويتم تسليمه إلى بيئة الإنتاج الخاصة بالعميل.
• نحن نتخلص من الارتباك في الإصدارات - لا يتعين علينا تخزين خريطة لإصدارات الخدمات الصغيرة ووصف تكوينها لكل خدمة صغيرة في البرامج النصية لـ Helm.

2. المزامنة مع مستودع Git للكود المصدري للعميل

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

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

بعد هذا عليك القيام بالتجميع. ويتكون من عدة مراحل: تجميع الواجهة الخلفية والواجهة الأمامية والاختبار والتسليم إلى الإنتاج.

3. تجميع الواجهة الخلفية والواجهة الأمامية

يعد إنشاء الواجهة الخلفية والواجهة الأمامية مهمتين متوازيتين يتم تنفيذهما في نظام GitLab Runner. يوجد تكوين التجميع الأصلي الخاص به في نفس المستودع.

برنامج تعليمي لكتابة نص YAML للبناء في GitLab.

يأخذ GitLab Runner الكود من المستودع المطلوب، ويجمعه باستخدام أمر إنشاء تطبيق Java ويرسله إلى سجل Docker. هنا نقوم بتجميع الواجهة الخلفية والواجهة الأمامية، ونحصل على صور Docker، ونضعها في مستودع من جانب العميل. لإدارة صور Docker التي نستخدمها البرنامج المساعد Gradle.

نقوم بمزامنة إصدارات صورنا مع إصدار الإصدار الذي سيتم نشره في Docker. من أجل التشغيل السلس قمنا بإجراء العديد من التعديلات:

1. لا يتم إعادة بناء الحاويات بين بيئة الاختبار وبيئة الإنتاج. لقد قمنا بإجراء معلمات بحيث يمكن للحاوية نفسها العمل مع جميع الإعدادات ومتغيرات البيئة والخدمات في بيئة الاختبار وفي الإنتاج دون إعادة البناء.

2. لتحديث تطبيق عبر Helm، يجب عليك تحديد نسخته. نحن نبني الواجهة الخلفية والواجهة الأمامية ونقوم بتحديث التطبيق - هذه ثلاث مهام مختلفة، لذا من المهم استخدام نفس الإصدار من التطبيق في كل مكان. بالنسبة لهذه المهمة، نستخدم البيانات من سجل Git، نظرًا لأن تكوين مجموعة K8S وتطبيقاتها موجودة في نفس مستودع Git.

نحصل على إصدار التطبيق من نتائج تنفيذ الأمر
git describe --tags --abbrev=7.

4. النشر التلقائي لجميع التغييرات في بيئة الاختبار (UAT)

الخطوة التالية في هذا البرنامج النصي للإنشاء هي تحديث مجموعة K8S تلقائيًا. يحدث هذا بشرط إنشاء التطبيق بالكامل ونشر كافة العناصر في Docker Registry. بعد ذلك، يبدأ تحديث بيئة الاختبار.

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

نحن نوفر تكوين مجموعة K8S مع التجميع. لذلك، فإن الخطوة التالية هي تحديثه: configMaps وعمليات النشر والخدمات والأسرار وأي تكوينات أخرى لـ K8S قمنا بتغييرها.

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

5. النشر التلقائي لجميع التغييرات على Prod

لنشر تحديث في بيئة الإنتاج، ما عليك سوى النقر فوق زر واحد في GitLab - وسيتم تسليم الحاويات على الفور إلى بيئة الإنتاج.

يمكن أن يعمل نفس التطبيق في بيئات مختلفة - الاختبار والإنتاج - دون إعادة البناء. نستخدم نفس العناصر دون تغيير أي شيء في التطبيق، ونقوم بتعيين المعلمات خارجيًا.

تعتمد المعلمات المرنة لإعدادات التطبيق على البيئة التي سيتم تنفيذ التطبيق فيها. لقد قمنا بنقل كافة إعدادات البيئة خارجيًا: تم تحديد كل شيء من خلال تكوين K8S ومعلمات Helm. عندما ينشر Helm تجميعًا في بيئة الاختبار، يتم تطبيق إعدادات الاختبار عليه، ويتم تطبيق إعدادات المنتج على بيئة الإنتاج.

كان الأمر الأكثر صعوبة هو تحديد معلمات جميع الخدمات والمتغيرات المستخدمة التي تعتمد على البيئة، وترجمتها إلى متغيرات البيئة ووصف وتكوينات معلمات البيئة لـ Helm.

تستخدم إعدادات التطبيق متغيرات البيئة. يتم تعيين قيمها في حاويات باستخدام خريطة تهيئة K8S، والتي تم تصميمها باستخدام قوالب Go. على سبيل المثال، يمكن تعيين متغير بيئة لاسم المجال على النحو التالي:

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.القيم.global.env - يقوم هذا المتغير بتخزين اسم البيئة (prod، Stage، UAT).
.Values.app.properties.app_external_domain – في هذا المتغير قمنا بتعيين المجال المطلوب في ملف .Values.yaml

عند تحديث تطبيق ما، يقوم Helm بإنشاء ملف configmap.yaml من القوالب ويملأ قيمة APP_EXTERNAL_DOMAIN بالقيمة المطلوبة اعتمادًا على البيئة التي يبدأ فيها تحديث التطبيق. تم تعيين هذا المتغير بالفعل في الحاوية. يمكن الوصول إليه من التطبيق، لذلك سيكون لكل بيئة تطبيق قيمة مختلفة لهذا المتغير.

في الآونة الأخيرة نسبيًا، ظهر دعم K8S في Spring Cloud، بما في ذلك العمل مع configMaps: الربيع سحابة Kubernetes. في حين أن المشروع يتطور بنشاط ويتغير بشكل جذري، لا يمكننا استخدامه في الإنتاج. لكننا نراقب حالته بنشاط ونستخدمه في تكوينات DEV. وبمجرد أن يستقر، سنتحول من استخدام متغيرات البيئة إليه.

في المجموع

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

الخطط المستقبلية: الترحيل التلقائي لقاعدة البيانات

لقد فكرنا في ترقية قاعدة البيانات وإمكانية التراجع عن هذه التغييرات. بعد كل شيء، هناك إصداران مختلفان من التطبيق يعملان في نفس الوقت: الإصدار القديم قيد التشغيل، والإصدار الجديد قيد التشغيل. ولن نقوم بإيقاف تشغيل الإصدار القديم إلا عندما نتأكد من أن الإصدار الجديد يعمل. يجب أن يسمح لك ترحيل قاعدة البيانات بالعمل مع كلا الإصدارين من التطبيق.

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

إذا لم يعمل الإصدار الجديد من التطبيق بشكل صحيح، فيمكننا العودة إلى الإصدار السابق، بما في ذلك الإصدار السابق من قاعدة البيانات. باختصار، ستسمح لك تغييراتنا بالعمل مع عدة إصدارات من التطبيق في وقت واحد.

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

المصدر: www.habr.com