استراتيجيات النشر باللون الأزرق والأخضر في Azure Spring Apps

  • مقالة

إشعار

يعد Azure Spring Apps هو الاسم الجديد لخدمة Azure Spring Cloud. رغم أن الخدمة تحمل اسماً جديداً، سترى الاسم القديم في بعض الأماكن لفترة من الوقت بينما نعمل على تحديث الأصول مثل لقطات الشاشة، ومقاطع الفيديو، والرسوم التخطيطية.

تنطبق هذه المقالة على: ✔️ Basic/Standard ✔️ Enterprise

تصف هذه المقالة دعم النشر الأزرق والأخضر في Azure Spring Apps.

تسمح Azure Spring Apps (الخطة القياسية والإصدارات الأحدث) بإجراء توزيعين لكل تطبيق، واحدة منها فقط تتلقى نسبة استخدام الشبكة للإنتاج. يُعرف هذا النمط عمومًا باسم الانتشار الأزرق والأخضر. يسمح دعم Azure Spring Apps للنشر الأزرق والأخضر، جنبًا إلى جنب مع خط أنابيب التسليم المستمر (CD) والاختبار الآلي الصارم، بنشر تطبيقات رشيقة بثقة عالية.

عمليات النشر بالتناوب

أبسط طريقة لتنفيذ النشر الأزرق والأخضر مع Azure Spring Apps هي إنشاء عمليتي نشر ثابتتين والنشر دائمًا في النشر الذي لا يتلقى حركة الإنتاج. مع مهمة Azure Spring Apps للبنية الأساسية لبرنامج ربط العمليات التجارية Azure ، يمكنك الانتشار بهذه الطريقة فقط عن طريق ضبط العلم UseStagingDeployment على true.

إليك كيفية عمل نهج النشر المتناوب في الممارسة العملية:

افترض أن تطبيقك يحتوي على عمليتي نشر: deployment1 و deployment2. حاليًا، تم تعيين deployment1 على أنه نشر الإنتاج، ويتم تشغيل النسخة v3 من التطبيق.

هذا يؤدي إلي deployment2 الانتشار التدريجي. وبالتالي، عندما يكون خط أنابيب التسليم المستمر (CD) جاهزًا للتشغيل، فإنه ينشر الإصدار التالي من التطبيق، الإصدار v4، على النشر التدريجي deployment2.

رسم تخطيطي يوضح deployment1 مع v3 يتلقى حركة مرور الإنتاج والنشر2 المرحلي v4.

بعد أن تبدأ v4 في deployment2، يمكنك إجراء اختبارات آلية ويدوية ضدها من خلال نقطة نهاية اختبار خاصة لضمان أن v4 تلبي جميع التوقعات.

رسم تخطيطي يظهر V4 تم نشره على deployment2 والخضوع للاختبار.

عندما يكون لديك ثقة في v4، يمكنك تعيين deployment2 كنشر للإنتاج بحيث يستقبل كل حركة الإنتاج. v3 سيظل يعمل على deployment1 في حال اكتشفت مشكلة حرجة تتطلب التراجع.

رسم تخطيطي يظهر V4 على deployment2 يتلقى حركة مرور الإنتاج.

الآن، deployment1 عملية التقسيم المرحلي. لذا فإن التشغيل التالي لخط أنابيب النشر ينتشر على deployment1.

رسم تخطيطي يظهر V5 مرحلي إلى deployment1.

يمكنك الآن اختبار V5 على deployment1 نقطة نهاية الاختبار الخاصة.

رسم تخطيطي يظهر V5 تم اختباره على deployment1.

أخيرًا، بعد v5 تلبية جميع توقعاتك، قمت بتعيين deployment1 كنشر الإنتاج مرة أخرى، بحيث يتلقى v5 كل حركة الإنتاج.

رسم تخطيطي يظهر V5 يتلقى حركة مرور الإنتاج عند التوزيع1.

مفاضلات نهج النشر بالتناوب

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

النشر التدريجي المستمر

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

شرط سباق الموافقة

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

رسم تخطيطي يوضح حالة تعارض الموافقة الموضحة في هذا القسم.

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

عمليات النشر المسماة

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

في الرسم التوضيحي أدناه، تعمل النسخة v5 على النشر deployment-v5. يحتوي اسم النشر الآن على النسخة لأن النشر تم إنشاؤه خصيصًا لهذا الإصدار. ليس هناك نشر آخر في البداية. الآن، لنشر الإصدار v6، تخلق البنية الأساسية لبرنامج ربط العمليات التجارية النشر نشرًا جديدًا deployment-v6 وينشر إصدار التطبيق v6 هناك.

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

لا يوجد خطر من نشر نسخة أخرى بالتوازي. أولاً، لا تسمح Azure Spring Apps بإنشاء نشر ثالث بينما توجد عمليتا نشر بالفعل. ثانياً، حتى لو كان من الممكن نشر أكثر من عمليتين، يتم تحديد كل انتشار من خلال نسخة التطبيق التي يحتويها. وبالتالي، فإن البنية الأساسية التي تنظم النشر v6 ستحاول فقط تعيين deployment-v6 كنشر للإنتاج.

رسم تخطيطي يوضح v6 تم نشره على deployment-v6 وتلقي حركة مرور الإنتاج.

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

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

مقايضات نهج النشر المسمى

ولنهج النشر المسمى الفوائد التالية:

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

ومع ذلك، هناك عيوب أيضا، على النحو المبين في الفرع التالي.

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

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

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

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