توضح هذه المقالة حل نشر أزرق/أخضر عالي التوفر للتطبيقات على Azure Spring Apps.
يتضمن نمط النشر الأزرق/الأخضر الاحتفاظ بإصدار موجود من التطبيق مباشرة (يسمى الإصدار الأزرق ) بينما يتم نشر إصدار جديد من التطبيق (يسمى الإصدار الأخضر ). يسمح لك هذا النشر بإعادة تشغيل إصدار التطبيق الجديد وإعداده واختباره بشكل مستقل. بعد تشغيل الإصدار الجديد من التطبيق، يمكنك التبديل إليه وإعادة توجيه أي حركة مرور واردة جديدة إليه. بالنسبة لمستخدم التطبيق، يتم توزيع الإصدار الجديد دون أي توقف مرئي. يسهل النشر الأزرق/الأخضر التخلي عن إصدار جديد دون التأثير على الإصدار المباشر إذا لم يعمل التوزيع الجديد كما هو متوقع.
بناء الأنظمة
يوضح الرسم التخطيطي التالي بنية هذا النهج:
قم بتنزيل ملف Visio لهذه البنية.
المكونات
يستخدم هذا الحل المكونات التالية:
Azure Spring Apps هي منصة خدمات مصغرة حديثة لتشغيل تطبيقات Java Spring Boot و Steeltoe .NET Core . تلغي الخدمة التعليمات البرمجية المتداولة لتشغيل الخدمات المصغرة وتساعدك على تطوير تطبيقات قوية بسرعة في السحابة. يمكنك أيضا استخدام Azure Spring Apps لنشر التعليمات البرمجية على أساس كل تطبيق.
GitHub هو نظام أساسي لاستضافة التعليمة البرمجية يوفر التحكم في الإصدار والتعاون. يوفر GitHub التحكم في الإصدار المركز من Git وإدارة التعليمة البرمجية المصدر وميزات أخرى.
GitHub Actions تساعدك على أتمتة تطوير البرامج وسير عمل التوزيع من داخل المستودع. يمكنك استخدام النظام الأساسي لإنشاء تكامل مستمر تلقائي بالكامل وإعداد التسليم المستمر (CI/CD). يمكنك أيضا استخدام إجراءات GitHub لإنشاء بيئات يمكنك تكوين قواعد لها مثل طلب المراجعين.
سير العمل
تنفذ بنية الحل سير العمل التالي:
مطور يقوم بتغيير التطبيق. يحتفظ مستودع GitHub بالتعليمة البرمجية للتطبيق التي تحتاج إلى نشرها في Azure Spring Apps. يحدث كل تغيير في التعليمات البرمجية للتطبيق تحت التحكم بالمصادر. يكمل GitHub المهام التالية:
تأكد من مراجعة التغييرات.
منع التغييرات غير المقصودة أو غير المصرح بها.
تأكد من اكتمال فحوصات الجودة.
يحتفظ مستودع GitHub أيضا بسير عمل إجراءات GitHub لإنشاء تغييرات التعليمات البرمجية وإكمال عمليات التحقق من الجودة الضرورية. بعد تحويل التعليمات البرمجية برمجيا، ينشر سير عمل GitHub Actions أحدث إصدار من التعليمات البرمجية للتطبيق إلى Azure Spring Apps. يتضمن سير عمل GitHub Actions الخطوات التالية:
تحديد بيئة الإنتاج النشطة الحالية.
نشر التعليمات البرمجية إلى بيئة غير إنتاجية. إذا لم تكن البيئة غير المنتجة موجودة، فبادر بإنشاء البيئة.
في هذه المرحلة من النشر، يستمر الإصدار القديم (الأزرق) من التطبيق في نشر الإنتاج في تلقي جميع حركة مرور الإنتاج.
انتظر مراجعة النشر والموافقة على التطبيق الجديد.
تمنح هذه الخطوة التطبيق المنشور حديثا (الإصدار الأخضر) وقتا للبدء والاحتماء.
قبل الموافقة، يمكنك استخدام عنوان URL غير المنتج للتطبيق للتحقق من الإصدار الجديد والتأكد من أنه جاهز.
بعد الموافقة، قم بتبديل توزيع الإنتاج والتوزيع غير المنتج.
توجه جميع حركة مرور الإنتاج الآن إلى الإصدار الجديد من التطبيق.
إشعار
إذا رفضت التوزيع الجديد، فلن يقوم GitHub بتبديل البيئات. يستمر الإصدار السابق في تلقي حركة مرور الإنتاج.
بعد الموافقة وتبديل حركة المرور، احذف نشر الإنتاج القديم.
تنتج خطوة التنظيف هذه إعدادا أكثر فعالية من حيث التكلفة.
البدائل
يستخدم هذا الحل GitHub Actions للتنفيذ التلقائي فيما يخص التوزيع. يمكنك أيضا استخدام Azure Pipelines أو أي نظام أتمتة CI/CD آخر كبديل. تستخدم العينة المتوفرة في قسم Scenario deployment عبارات Azure CLI قدر الإمكان، حتى تتمكن من ترجمة هذا الإعداد بسهولة إلى أداة أتمتة أخرى. استخدم أداة CI/CD لإعداد بيئة وإنشاء تدفق موافقة عليها.
تستخدم هذه البنية Azure Spring Apps مع عمليات التوزيع كخدمة مستهدفة. يمكنك استخدام فتحات التدريج في Azure App Service كبديل. تحتوي الفتحة على الإصدار الجديد من التطبيق، والذي يمكن إعادة تحميله وتسخينه واختباره قبل إجراء تبديل الفتحة. تبديل الفتحات يضع الإصدار الجديد في مرحلة الإنتاج. هذه العملية مضمنة في الخدمة، لذا فإن الإعداد سهل.
كبديل آخر، يمكنك وضع أي خدمة Azure تستضيف نقاط نهاية الويب خلف حل موازنة التحميل. إذا كنت تستخدم هذا الأسلوب، يمكنك تدوير مثيل ثان من خدمة Azure، حيث يمكنك نشر إصدار جديد من التطبيق الخاص بك. كخطوة تالية، يمكنك إنشاء نشر بدون توقف عن العمل عن طريق تبديل نسبة استخدام الشبكة في حل موازنة التحميل إلى خدمة Azure التي تحتوي على الإصدار الجديد من التطبيق. ضع في اعتبارك أن هذا النهج للتوزيع الأزرق/الأخضر يتطلب حملا إداريا كبيرا.
تفاصيل السيناريو
بالنسبة لبعض التطبيقات السحابية، يعد الحفاظ على وقت التشغيل على أعلى مستوى ممكن أمراً بالغ الأهمية. أحد الحلول هو استخدام تكوين قابلية وصول عالية، والذي يمكن أن يضاعف التكاليف. حل آخر هو خطة التعافي من الكوارث، والتي تظهر التطبيق مرة أخرى في منطقة أخرى بعد انقطاع التيار الكهربائي. قد تكون تكلفة الأخير أقل، ولكن إحضار التطبيق بأكمله عبر الإنترنت مرة أخرى يستغرق وقتا.
توضح هذه المقالة عملية ضمان قابلية الوصول العالية أثناء توزيع إصدار جديد من التطبيق. في التكوين التقليدي، يتم توزيع وحدات البت الجديدة للتطبيق في الخدمة التي تستضيف التطبيق. غالباً ما يؤدي هذا التكوين إلى إعادة تحميل التطبيق وإعادة تشغيله. أثناء هذه العملية، يكون التطبيق غير متاح.
يستخدم هذا الحل Azure Spring Apps لتنفيذ التوزيع الأزرق/الأخضر ويعالج أتمتة نشر التطبيقات.
حالات الاستخدام المحتملة
يمكن أن يفيد هذا الحل أي مؤسسة تتطلب توفراً عالياً. الحل مناسب بشكل خاص للصناعات مثل التجارة الإلكترونية والألعاب، حيث يمكن أن يؤدي التوقف عن العمل إلى فقدان الأعمال والإيرادات.
يمكنك زيادة تحسين توافرك من خلال تنفيذ عمليات توزيع دون توقف. لمزيد من المعلومات، راجع قسم Alternatives في هذه المقالة.
الاعتبارات
تنفذ اعتبارات الحل التالية ركائز Azure Well-Architected Framework. هذا الإطار هو مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.
التوافر
يساعدك هذا الحل في الحفاظ على توفر التطبيق الخاص بك أثناء توزيع إصدار جديد. لا يزيد من اتفاقية مستوى الخدمة الإجمالية التي توفرها Azure Spring Apps. لا يزال بإمكان إخفاقات الخدمة على النظام الأساسي التأثير على تطبيقك.
إذا كنت تريد حلا لزيادة اتفاقية مستوى الخدمة الإجمالية للتكوين الخاص بك، فابحث في إعداد خدمة Azure Spring Apps عالية التوفر عبر مناطق متعددة. في هذا النهج، يمكنك واجهة التكوين مع حل موازنة التحميل العمومي.
قابلية التوسع
يعمل هذا الحل على أساس كل تطبيق، لذا فهو مناسب تماماً لتطبيقات الخدمات المصغرة. كما يسمح لفرق التطبيق بالعمل بشكل مستقل عن فرق التطبيق الأخرى دون التأثير على وقت تشغيل الحل الشامل.
يعمل هذا الحل أيضاً بشكل أفضل على أساس كل تطبيق، حيث يكون لكل تطبيق سير عمل توزيع أزرق/أخضر خاص به. إذا قمت بدمج التطبيقات في نفس سير العمل، يصبح هذا التكوين معقداً بسرعة، لذلك لا نوصي بهذا الأسلوب.
الأمان
ويوفر عامل الأمان ضمانات للحماية من الهجمات المتعمدة واستغلال البيانات والأنظمة القيمة الخاصة بك. للمزيد من المعلومات، يرجى الرجوع إلى نظرة عامة على ركيزة الأمان.
بصرف النظر عن إعداد أذونات المستودع، ضع في اعتبارك تنفيذ مقاييس الأمان التالية في مستودعات Git التي تحتوي على التعليمات البرمجية التي تريد نشرها في Azure Spring Apps:
حماية الفرع. احمِ الفروع التي تمثل حالة إنتاج تطبيقك من دفع التغييرات إليها مباشرةً. طلب تقديم كل اقتراح تغيير كطلب سحب (PR). استخدم PRs لإجراء فحوصات تلقائية. قد تتضمن عمليات التحقق إنشاء كافة التعليمات البرمجية وتشغيل اختبارات الوحدة على التعليمات البرمجية التي ينشئها طلب السحب أو يعدلها.
مراجعة العلاقات العامة. لفرض كيان العيون الأربع، يجب أن يكون لدى العلاقات العامة مرجع واحد على الأقل. يمكنك أيضاً استخدام ميزة مالكي الأكواد في GitHub لتحديد الأفراد أو الفرق المسؤولة عن مراجعة ملفات معينة في المستودع.
تاريخ غير قابل للتغيير. السماح بالتثبيتات الجديدة فقط بالإضافة إلى التغييرات الموجودة. التاريخ غير القابل للتغيير مهم بشكل خاص لأغراض التدقيق.
مزيد من التدابير الأمنية. اطلب من مستخدمي GitHub تنشيط المصادقة متعددة العوامل. أيضاً، اسمح بالالتزامات الموقعة فقط، والتي لا يمكن تغييرها في وقت لاحق.
نوصي أيضا بالنشر إلى خدمة Azure Spring Apps واحدة فقط. في إعداد الإنتاج، يجب أولاً اختبار التعليمة البرمجية الخاصة بك في بيئات أخرى قبل توزيعها في الإنتاج. يفضل أن تكون بيئة الإنتاج في بيئة مختلفة عن بيئة التطوير والاختبار.
للحصول على معلومات حول الأمان الإضافي لخدمة Azure Spring Apps، راجع نشر Azure Spring Apps في شبكة ظاهرية. إذا قمت بتنفيذ النشر الموصى به، فلا يمكنك استخدام المشغلات المستضافة على GitHub. تحتاج إلى استخدام العداء الخاص بك لسير عمل التوزيع.
DevOps
أتمتة هذا الإعداد عبر مهام سير عمل GitHub Actions تزيد من إنتاجية DevOps. إحدى الميزات الأكثر فائدة هي القدرة على التراجع بسرعة عن التغييرات التي تتصرف بشكل غير متوقع. فقط رفض التوزيع الجديد.
غالباً ما تدير الفرق بيئات متعددة لنفس التطبيق. من المعتاد أن يكون لديك عدة إصدارات من تطبيق تم توزيعه على خدمات Azure Spring Apps المختلفة. يُظهر مستودع Git، وهو المصدر الوحيد للحقيقة، إصدارات التطبيقات التي يتم توزيعها حالياً في مجموعة.
تحسين التكلفة
يتضمن تحسين التكلفة البحث عن طرق لتقليل النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.
استخدم حاسبة تسعير Azure لتقدير التكاليف.
تحتوي Azure Spring Apps على طبقة أساسية وطبقة قياسية. للحصول على التفاصيل، راجع أسعار Azure Spring Apps. عند استخدام إستراتيجية التوزيع باللونين الأزرق/الأخضر، فإنك تدفع مقابل SPU الظاهري الإضافي لفترة قصيرة فقط، أثناء تشغيل التوزيع.
يقدم GitHub خدمة مجانية. ومع ذلك، لاستخدام ميزات متقدمة متعلقة بالأمان مثل مالكي التعليمات البرمجية أو المراجعين المطلوبين، تحتاج إلى خطة الفريق. لمزيد من المعلومات، راجع صفحة أسعار GitHub.
نشر السيناريو
للحصول على عينة من هذا التكوين، راجع النشر التلقائي الأزرق/الأخضر لتطبيقات Azure Spring Apps GitHub repo. يتضمن المستودع أيضا خطوات إعداد خدمة Azure Spring Apps باستخدام قالب Bicep.
المساهمون
تحتفظ Microsoft بهذا المحتوى. قام المساهم التالي بتطوير المحتوى الأصلي.
الكاتب الرئيسي:
- Gitte Vermeiren | FastTrack لمهندس Azure
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
- تنفيذ هذه البنية باستخدام دليل خطوة بخطوة
- استراتيجيات النشر الأزرق/الأخضر في Azure Spring Apps
- التشغيل السريع: إنشاء وتوزيع التطبيقات إلى Azure Spring Apps
- إعداد بيئة مرحلية في Azure Spring Apps
- GitHub: فهم إجراءات GitHub
- GitHub: استخدام البيئات للنشر
- GitHub: إعادة استخدام مهام سير العمل