إعداد بيئات التدريج في Azure App Service
إشعار
بدءا من 1 يونيو 2024، يمكن لتطبيقات App Service التي تم إنشاؤها حديثا إنشاء اسم مضيف افتراضي فريد يستخدم اصطلاح <app-name>-<random-hash>.<region>.azurewebsites.net
التسمية . تظل أسماء التطبيقات الحالية دون تغيير. على سبيل المثال:
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
لمزيد من المعلومات، راجع اسم المضيف الافتراضي الفريد لمورد App Service.
عند نشر تطبيق الويب أو تطبيق الويب على Linux أو الواجهة الخلفية للأجهزة المحمولة أو تطبيق API إلى Azure App Service، يمكنك استخدام فتحة توزيع منفصلة بدلا من فتحة الإنتاج الافتراضية. يتوفر هذا الأسلوب إذا قمت بتشغيل في مستوى خطة خدمة التطبيقات القياسية أو المتميزة أو المعزولة. فتحات النشر هي تطبيقات مباشرة بأسماء مضيفين خاصة بهم. يمكن تبديل محتوى التطبيق وعناصر التكوينات بين فتحتين للنشر، بما في ذلك فتحة الإنتاج.
نشر التطبيق الخاص بك إلى فتحة غير إنتاجية له المزايا التالية:
- يمكنك التحقق من صحة تغييرات التطبيق في فتحة توزيع مرحلي قبل تبديلها بفتحة الإنتاج.
- يؤدي نشر تطبيق إلى فتحة أولا وتبديله إلى الإنتاج إلى التأكد من أن جميع مثيلات الفتحة يتم تجهيزها قبل تبديلها إلى إنتاج. يلغي هذا الأسلوب وقت التعطل عند نشر تطبيقك. إعادة توجيه نسبة استخدام الشبكة سلسة. لا يتم إسقاط أي طلبات بسبب عمليات التبديل. ويمكنك أتمتة سير العمل هذا بالكامل عن طريق تكوين التبديل التلقائي عندما لا تكون هناك حاجة إلى التحقق من صحة التبديل المسبق.
- بعد التبديل، أصبح للفتحة التي تحتوي على تطبيق مُقسّم سابقًا الآن تطبيق الإنتاج السابق. إذا لم تكن التغييرات التي تم تبديلها في فتحة الإنتاج كما تتوقع، يمكنك إجراء نفس التبديل على الفور للحصول على آخر موقع جيد معروف مرة أخرى.
ويدعم كل مستوى خطة App Service عدداً مختلفاً من فتحات النشر. لا توجد رسوم إضافية لاستخدام فتحات النشر. ولمعرفة عدد الفتحات التي يدعمها مستوى تطبيقك، اطلع على حدود App Service.
ولتوسيع نطاق تطبيقك إلى مستوى مختلف، تأكد من أن المستوى المستهدف يدعم عدد الفتحات التي يستخدمها تطبيقك بالفعل. على سبيل المثال، إذا كان تطبيقك يحتوي على أكثر من خمس فتحات، فلا يمكنك تقليصه إلى المستوى القياسي . يدعم المستوى القياسي خمس فتحات نشر فقط.
يوضح لك هذا الفيديو كيفية إعداد بيئات التشغيل المرحلي في Azure App Service.
يتم أيضا وصف الخطوات الواردة في الفيديو في الأقسام التالية.
المتطلبات الأساسية
- للحصول على معلومات حول الأذونات التي تحتاجها لتنفيذ عملية الفتحة التي تريدها، راجع عمليات موفر الموارد. ابحث عن فتحة، على سبيل المثال.
إضافة فتحة
يجب أن يكون التطبيق قيد التشغيل في المستوى القياسي أو المتميز أو المعزول لتمكين فتحات نشر متعددة.
في مدخل Azure، انتقل إلى صفحة إدارة التطبيق.
في الجزء الأيمن، حدد Deployment>Deployment slots>Add.
إشعار
إذا لم يكن التطبيق موجودا بالفعل في المستوى القياسي أو المتميز أو المعزول ، فحدد ترقية. انتقل إلى علامة التبويب مقياس لتطبيقك قبل المتابعة.
في مربع الحوار إضافة فتحة، امنح الفتحة اسمًا، وحدد ما إذا كنت تريد استنساخ تكوين تطبيق من فتحة نشر أخرى. حدد إضافة للمواصلة.
يمكنك استنساخ تكوين من أي فتحة موجودة. تتضمن الإعدادات التي يمكن استنساخها إعدادات التطبيق وسلاسل الاتصال وإصدارات إطار عمل اللغة ومآخذ الويب وإصدار HTTP وبت النظام الأساسي.
إشعار
حاليا، لا يتم استنساخ نقطة نهاية خاصة عبر الفتحات.
بعد إدخال الإعدادات، حدد إغلاق لإغلاق مربع الحوار. يتم الآن عرض الفتحة الجديدة في صفحة Deployment slots. بشكل افتراضي، يتم تعيين نسبة استخدام الشبكة % إلى 0 للفتحة الجديدة، مع توجيه جميع نسبة استخدام شبكة العملاء إلى فتحة الإنتاج.
حدد فتحة النشر الجديدة لفتح صفحة موارد تلك الفتحة.
تحتوي فتحة التقسيم المرحلي على صفحة إدارة تماما مثل أي تطبيق App Service آخر. يمكنك تغيير تكوين الفتحة. لتذكيرك بأنك تعرض فتحة التوزيع، يتم عرض اسم التطبيق كاسم <التطبيق/<اسم>> الفتحة. نوع التطبيق هو App Service (Slot) . يمكنك أيضًا رؤية الفتحة كتطبيق منفصل في مجموعة الموارد الخاصة بك، بنفس التعيينات.
حدد عنوان URL للتطبيق في صفحة مورد الفتحة. تحتوي فتحة التوزيع على اسم المضيف الخاص بها وهي أيضًا تطبيق مباشر. للحد من الوصول العام إلى فتحة النشر، راجع قيود IP لخدمة تطبيقات Azure.
لا تحتوي فتحة النشر الجديدة على أي محتوى، حتى إذا قمت باستنساخ الإعدادات من فتحة مختلفة. على سبيل المثال، يمكنك النشر إلى هذه الفتحة باستخدام Git. ويمكنك النشر إلى الفتحة من مستودع تخزين مختلف أو من فرع مستودع تخزين مختلف. يمكن أن يوفر الحصول على ملف تعريف النشر من Azure App Service المعلومات المطلوبة للتوزيع في الفتحة. يمكن ل Visual Studio استيراد ملف التعريف لنشر المحتويات إلى الفتحة.
يحتوي عنوان URL الخاص بالفتحة على التنسيق http://sitename-slotname.azurewebsites.net
. للحفاظ على طول عنوان URL ضمن حدود DNS الضرورية، يتم اقتطاع اسم الموقع في 40 حرفا. يجب أن يكون اسم الموقع المدمج واسم الفتحة أقل من 59 حرفا.
ماذا يحدث أثناء التبديل
خطوات عملية التبديل
عند تبديل فتحتين، تقوم App Service بما يلي للتأكد من أن فتحة الهدف لا تواجه وقت تعطل:
قم بتطبيق الإعدادات التالية من الفتحة الهدف (على سبيل المثال، فتحة الإنتاج) على جميع مثيلات فتحة المصدر:
- إعدادات التطبيق وسلاسل الاتصال الخاصة بالفتحة، إن وجدت.
- إعدادات النشر المستمر، إذا تم تمكينها.
- إعدادات مصادقة خدمة التطبيقات، إذا تم تمكينها.
عند تطبيق أي من الإعدادات على فتحة المصدر، يؤدي التغيير إلى تشغيل جميع المثيلات في فتحة المصدر لإعادة التشغيل. أثناء التبديل مع المعاينة، يشير هذا الإجراء إلى نهاية المرحلة الأولى. تم إيقاف عملية التبديل مؤقتا. يمكنك التحقق من أن فتحة المصدر تعمل بشكل صحيح مع إعدادات الفتحة الهدف.
انتظر حتى يكمل كل مثيل في فتحة المصدر عملية إعادة تشغيله. وإذا فشلت إعادة تشغيل أي مثيل، فإن عملية التبديل تُعيد جميع التغييرات إلى فتحة المصدر وتوقف العملية.
إذا تم تمكين ذاكرة التخزين المؤقت المحلية، فقم بتشغيل تهيئة ذاكرة التخزين المؤقتة المحلية عن طريق إجراء طلب HTTP إلى جذر التطبيق ("/") في كل مثيل من فتحة المصدر. وانتظر حتى يقوم كل مثيل بإرجاع أي استجابة HTTP. يؤدي تهيئة ذاكرة التخزين المؤقتة المحلية إلى عملية إعادة تشغيل أخرى على كل مثيل.
إذا تم تمكين التبديل التلقائي مع التجهيز المخصص، فشغل بدء التطبيق المخصص على كل مثيل من فتحة المصدر.
وإذا لم يتم تحديد
applicationInitialization
، فقم بتشغيل طلب HTTP إلى جذر التطبيق الخاص بفتحة المصدر في كل مثيل.إذا قام مثيل بإرجاع أي استجابة HTTP، فسيتم اعتباره جاهزاً.
إذا تم تجهيز جميع المثيلات في الفتحة المصدر بنجاح، فقم بتبديل الفتحتين عن طريق تبديل قواعد التحويل للفتحتين. بعد هذه الخطوة، تحتوي فتحة الهدف (على سبيل المثال، فتحة الإنتاج) على التطبيق الذي تم تجهيزه بشكل مسبق في فتحة المصدر.
والآن بعد أن كان تطبيق التبديل المسبق في فتحة الهدف بشكل مسبق في فتحة المصدر، قم بإجراء نفس العملية من خلال تطبيق جميع الإعدادات وإعادة تشغيل المثيلات.
في أي نقطة من عملية التبديل تتم جميع أعمال تهيئة التطبيقات التي تم تبديلها في فتحة المصدر. تظل فتحة الهدف متصلة بالإنترنت أثناء إعداد فتحة المصدر وتسخينها، بغض النظر عما إذا كانت المبادلة ناجحة أو تفشل. ولتبديل فتحة التشغيل المرحلي بفتحة الإنتاج، تأكد من أن فتحة الإنتاج هي دائماً فتحة الهدف. وبهذه الطريقة، لا تؤثر عملية التبديل على تطبيق الإنتاج.
إشعار
يتم تبديل مثيلات الإنتاج السابقة إلى التقسيم المرحلي بعد عملية التبديل هذه. تتم إعادة تدوير هذه المثيلات في الخطوة الأخيرة من عملية التبديل. في حالة وجود أي عمليات طويلة الأمد في التطبيق الخاص بك، يتم التخلي عنها، عندما يعيد العمال تدويرها. تنطبق هذه الحقيقة أيضا على تطبيقات الوظائف. لذلك، يجب كتابة التعليمات البرمجية للتطبيق الخاص بك بطريقة متسامحة مع الخطأ.
ما هي الإعدادات التي يتم تبديلها؟
عند نسخ تكوين من فتحة نشر أخرى، يكون التكوين المنسوخ قابلاً للتحرير. تتبع بعض عناصر التكوين المحتوى عبر المبادلة (ليست خاصة بالفتحة). تبقى عناصر التكوين الأخرى في نفس الفتحة بعد التبديل (فتحة محددة). تظهر القوائم التالية الإعدادات التي تتغير عند تبديل الفتحات.
الإعدادات التي تم تبديلها:
- مكدس اللغة وإصدارها، 32/64 بت
- إعدادات التطبيق (يمكن تهيئتها لتلتزم بفتحة)
- سلاسل الاتصال (يمكن تهيئتها لتلتزم بفتحة)
- حسابات التخزين المثبتة (يمكن تكوينها للتمسك بفتحة)
- تعيينات المعالج
- الشهادات العامة
- محتوى WebJobs
- اتصالات مختلطة *
- نقاط نهاية الخدمة *
- Azure Content Delivery Network *
- تعيينات المسار
الميزات المميزة بعلامة النجمة (*) مخططة بحيث لا يتم تبديلها.
الإعدادات التي لا يتم تبديلها:
- الإعدادات العامة غير المذكورة في الإعدادات التي تم تبديلها
- نشر نقاط النهاية
- أسماء المجالات المخصصة
- الشهادات غير العامة وإعدادات TLS/SSL
- إعدادات المقياس
- جدولة WebJobs
- قيود IP
- قيد التشغيل دائمًا
- إعدادات التشخيص
- مشاركة الموارد عبر المنشأ (CORS)
- تكامل الشبكة الظاهرية
- الهويات المدارة والإعدادات ذات الصلة
- الإعدادات التي تنتهي باللاحقة _EXTENSION_VERSION
- الإعدادات التي تم إنشاؤها بواسطة Service Connector
إشعار
لجعل الإعدادات قابلة للتبديل، أضف إعداد التطبيق WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS
في كل فتحة من التطبيق واضبط قيمته على 0
أو false
. هذه الإعدادات إما قابلة للتبديل أو غير قابلة للتبديل على الإطلاق. لا يمكنك جعل بعض الإعدادات قابلة للتبديل فقط وليس الإعدادات الأخرى. لا يتم تبديل الهويات المدارة أبدا. لا يؤثر إعداد تطبيق التجاوز هذا عليها.
وكذلك لا تُبدل بعض إعدادات التطبيق التي تنطبق على الإعدادات غير المبدلة. على سبيل المثال، نظرا لعدم تبديل إعدادات التشخيص، فإن إعدادات التطبيق ذات الصلة مثل WEBSITE_HTTPLOGGING_RETENTION_DAYS
ولا DIAGNOSTICS_AZUREBLOBRETENTIONDAYS
يتم تبديلها أيضا، حتى إذا لم تظهر كإعدادات فتحة.
لتكوين إعداد تطبيق أو سلسلة الاتصال الالتزام بفتحة معينة، والتي لم يتم تبديلها، انتقل إلى صفحة Settings>Environment Variable لتلك الفتحة. أضف إعداداً أو قم بتحريره، ثم حدد Deployment slot setting. يؤدي تحديد هذا الخيار إلى إعلام App Service بأن الإعداد غير قابل للتبديل.
تبديل فتحتين
يمكنك تبديل فتحات النشر في صفحة فتحات النشر الخاصة بالتطبيق وصفحة النظرة العامة. لمزيد من المعلومات حول تبديل الفتحة، راجع ما يحدث أثناء التبديل.
هام
وقبل تبديل تطبيق من فتحة نشر إلى فتحة إنتاج، تأكد من أن الإنتاج هو فتحة الهدف وأن جميع الإعدادات في فتحة المصدر قد تم تكوينها تماماً كما تريدها في الإنتاج.
لتبديل فتحات النشر:
انتقل إلى صفحة Deployment slots الخاصة بالتطبيق وحدد Swap.
يعرض مربع الحوار تبديل الإعدادات في فتحات المصدر والهدف المحددة التي سيتم تغييرها.
حدد الفتحات المطلوبة Source وTarget. عادةً ما يكون الهدف هو فتحة الإنتاج. حدد أيضاً علامتي التبويب Source Changes وTarget Changes وتحقق من توقع تغييرات التكامل. عند الانتهاء، يمكنك تبديل الفتحات على الفور عن طريق تحديد Swap.
لمعرفة كيفية تشغيل فتحة الهدف بالإعدادات الجديدة قبل حدوث التبديل فعلياً، لا تحدد التبديل، ولكن اتبع الإرشادات الواردة في Swap with preview.
عند الانتهاء، حدد إغلاق لإغلاق مربع الحوار.
إذا كان لديك أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها.
تبديل مع المعاينة (التبديل متعدد المراحل)
قبل التبديل إلى الإنتاج باعتباره فتحة الهدف، تحقق من أن التطبيق يعمل بالإعدادات التي تم تبديلها. ويتم أيضاً تجهيز فتحة المصدر قبل اكتمال التبديل، وهو أمر مرغوب فيه للتطبيقات ذات المهام الحرجة.
وعند إجراء تبديل مع المعاينة، تنفذ App Service نفس عملية التبديل ولكنها تتوقف مؤقتاً بعد الخطوة الأولى. ومن ثَم يمكنك التحقق من النتيجة على فتحة التشغيل المرحلي قبل إتمام التبديل.
وإذا ألغيت التبديل، فإن App Service يعيد تطبيق عناصر التكوين على فتحة المصدر.
إشعار
لا يمكن استخدام التبديل مع المعاينة عند تمكين مصادقة الموقع في إحدى الفتحات.
للتبديل مع المعاينة:
اتبع الخطوات السابقة في تبديل فتحات النشر ولكن حدد Perform swap with preview.
سيعرض لك مربع الحوار كيفية تغير التكوين في فتحة المصدر في المرحلة 1، وكيف تتغير فتحة المصدر وفتحة الهدف في المرحلة 2.
عندما تكون مستعداً لبدء التبديل، حدد Start Swap.
عند اكتمال المرحلة 1، يقوم مربع الحوار بإعلامك. قم بمعاينة التبديل في فتحة المصدر عن طريق الانتقال إلى
https://<app_name>-<source-slot-name>.azurewebsites.net
.عندما تكون مستعداً لإكمال التبديل المعلق، حدد Complete Swap في Swap action وحدد Complete Swap.
لإلغاء تبديل معلق، حدد إلغاء التبديل بدلا من ذلك، ثم حدد إلغاء التبديل في الأسفل.
عند الانتهاء، حدد إغلاق لإغلاق مربع الحوار.
إذا كان لديك أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها.
التراجع عن المبادلة
في حالة حدوث أي أخطاء في فتحة الهدف (على سبيل المثال، فتحة الإنتاج) بعد تبديل الفتحة، قم بإعادة الفتحات إلى حالات ما قبل التبديل عن طريق تبديل نفس الفتحتين على الفور.
تكوين التبديل التلقائي
إشعار
التبديل التلقائي غير مدعوم في تطبيقات الويب على Linux وWeb App للحاويات.
يعمل التبديل التلقائي على تبسيط سيناريوهات Azure DevOps حيث تريد نشر تطبيقك بشكل مستمر مع عدم وجود تشغيل عادي ووقت توقف عن العمل لعملاء التطبيق. عند تمكين التبديل التلقائي من الفتحة إلى الإنتاج، في كل مرة تدفع فيها تغييرات التعليمات البرمجية إلى تلك الفتحة، تقوم خدمة التطبيقات تلقائيًا بتبديل التطبيق إلى الإنتاج بعد تجهيزه في الفتحة المصدر.
إشعار
قبل تكوين التبديل التلقائي لفتحة الإنتاج، ضع في اعتبارك اختبار التبديل التلقائي على فتحة هدف غير منتج.
لتكوين التبديل التلقائي:
انتقل إلى صفحة موارد التطبيق. حدد فتحات نشر النشر>المطلوبة فتحة>>< المصدر.
في الجزء الأيمن، حدد الإعدادات الإعدادات الإعدادات العامة للتكوين>>.
بالنسبة إلى تمكين التبديل التلقائي، حدد تشغيل. ثم حدد فتحة الهدف المطلوبة لفتحة نشر التبديل التلقائي، وحدد Save في شريط الأوامر.
تشغيل دفع التعليمات البرمجية إلى فتحة المصدر. يحدث التبديل التلقائي بعد وقت قصير. ينعكس التحديث في عنوان URL الخاص بفتحة الهدف.
إذا كان لديك أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها.
تحديد التجهيز المخصص
قد تتطلب بعض التطبيقات إجراءات تجهيز مخصصة قبل التبديل.
applicationInitialization
يتيح لك عنصر التكوين في web.config تحديد إجراءات التهيئة المخصصة. وتنتظر عملية التبديل هذا التجهيز المخصص حتى ينتهي قبل التبديل مع فتحة الهدف. فيما يلي عينة جزء web.config .
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
لمزيد من المعلومات حول تخصيص العنصر applicationInitialization
، اطلع على أكثر حالات فشل تبديل فتحة النشر شيوعاً وكيفية إصلاحها.
يمكنك أيضا تخصيص سلوك التجهيز باستخدام إعدادات التطبيق التالية:
-
WEBSITE_SWAP_WARMUP_PING_PATH
: مسار لاختبار الاتصال عبر HTTP لتجهيز موقعك. أضف إعداد التطبيق هذا عن طريق تحديد مسار مخصص يبدأ بشرطة مائلة كقيمة. مثال على ذلك/statuscheck
. القيمة الافتراضية هي/
. -
WEBSITE_SWAP_WARMUP_PING_STATUSES
: تعليمات استجابة برمجية HTTP صالحة لعملية التجهيز. أضف إعداد التطبيق هذا بقائمة تعليمات HTTP برمجية مفصولة بفواصل. مثال على ذلك200,202
. إذا لم تكن تعليمات الحالة البرمجية التي تم إرجاعها موجودة في القائمة، فسيتم إيقاف عمليات التجهيز والتبديل. وتعد جميع تعليمات الاستجابة البرمجية صالحة بشكل افتراضي. -
WEBSITE_WARMUP_PATH
: مسار نسبي على الموقع يجب اختبار اتصاله عند إعادة تشغيل الموقع (ليس فقط أثناء تبديل الفتحات). تتضمن/statuscheck
قيم المثال أو المسار الجذر،/
.
إشعار
<applicationInitialization>
عنصر التكوين هو جزء من كل بدء تشغيل تطبيق، بينما تنطبق إعدادات تطبيق سلوك التجهيز فقط على تبديل الفتحات.
إذا كان لديك أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها.
مراقبة التبديل
وإذا استغرقت عملية التبديل وقتاً طويلاً حتى تكتمل، فيمكنك الحصول على معلومات حول عملية التبديل في سجل النشاط.
في صفحة موارد التطبيق في المدخل، في الجزء الأيمن، حدد Activity log.
ستظهر عملية التبديل في استعلام السجل كـ Swap Web App Slots
. ويمكنك توسيعه وتحديد أحد العمليات الفرعية أو الأخطاء لمعرفة التفاصيل.
توجيه نقل بيانات الإنتاج تلقائياً
ويتم توجيه جميع طلبات العميل إلى عنوان URL الخاص بإنتاج التطبيق (http://<app_name>.azurewebsites.net
) إلى فتحة الإنتاج بشكل افتراضي. ويمكنك توجيه جزء من نقل البيانات إلى فتحة أخرى. وتعد هذه الميزة مفيدة إذا كنت بحاجة إلى ملاحظات المستخدم لتحديث جديد، لكنك لست مستعداً لإصداره للإنتاج.
لتوجيه نقل بيانات الإنتاج تلقائياً:
انتقل إلى صفحة مورد تطبيق الويب وحدد Deployment slots.
في العمود Traffic % للفتحة التي تريد التوجيه إليها، حدد نسبة مئوية (بين 0 و100) لتمثل مقدار إجمالي نقل البيانات التي تريد توجيهها. حدد حفظ.
بعد حفظ الإعداد، يتم توجيه النسبة المئوية المحددة للعملاء عشوائيا إلى فتحة عدم الإنتاج.
بعد توجيه العميل تلقائيا إلى فتحة معينة، يتم تثبيته في تلك الفتحة لمدة ساعة واحدة أو حتى يتم حذف ملفات تعريف الارتباط. في مستعرض العميل، يمكنك معرفة الفتحة التي تم تثبيت جلستك عليها من خلال النظر إلى ملف تعريف الارتباط x-ms-routing-name
في رؤوس HTTP. يحتوي الطلب الذي يتم توجيهه إلى فتحة التقسيم المرحلي على ملف تعريف الارتباط x-ms-routing-name=staging
. يحتوي الطلب الموجه إلى فتحة الإنتاج على ملف تعريف الارتباط x-ms-routing-name=self
.
توجيه نقل بيانات الإنتاج يدوياً
بالإضافة إلى التحويل التلقائي لنقل البيانات، يمكن لـ App Service تحويل الطلبات إلى فتحة معينة. يعد هذا الخيار مفيدا عندما تريد أن يتمكن المستخدمون من الاشتراك في تطبيق بيتا أو إلغاء الاشتراك فيه. ولتوجيه نقل بيانات الإنتاج يدوياً، يمكنك استخدام معامل الاستعلام x-ms-routing-name
.
وللسماح للمستخدمين بإلغاء الاشتراك في تطبيق بيتا على سبيل المثال، يمكنك وضع هذا الارتباط على صفحة الويب:
<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>
تحدد السلسلة x-ms-routing-name=self
فتحة الإنتاج. بعد وصول مستعرض العميل إلى الارتباط تتم إعادة توجيهه إلى فتحة الإنتاج. ويحتوي كل طلب لاحق على ملف تعريف الارتباط x-ms-routing-name=self
الذي يثبت الجلسة في فتحة الإنتاج.
للسماح للمستخدمين بالاشتراك في تطبيق بيتا الخاص بك، قم بتعيين نفس معلمة الاستعلام إلى اسم فتحة عدم الإنتاج. إليك مثال:
<webappname>.azurewebsites.net/?x-ms-routing-name=staging
بشكل افتراضي، يتم إعطاء فتحات جديدة قاعدة توجيه من 0%
، تظهر باللون الرمادي. وعند تعيين هذه القيمة صراحةً على 0%
، (معروضة باللون الأسود)، ويمكن للمستخدمين الوصول إلى فتحة التشغيل المرحلي يدوياً باستخدام معلمة الاستعلام x-ms-routing-name
. لن يتم توجيهها إلى الفتحة تلقائيا لأن النسبة المئوية للتوجيه معينة إلى 0. هذا التكوين هو سيناريو متقدم حيث يمكنك إخفاء فتحة التقسيم المرحلي عن الجمهور مع السماح للفرق الداخلية باختبار التغييرات على الفتحة.
حذف فتحة
ابحث عن التطبيق وحدده. حدد فتحة Deployment>Deployment slots<>لحذف>>Overview. يتم عرض نوع التطبيق ك App Service (Slot) لتذكيرك بأنك تعرض فتحة توزيع. قبل حذف فتحة، تأكد من إيقاف الفتحة وتعيين نسبة استخدام الشبكة في الفتحة إلى الصفر. حدد Delete في شريط الأوامر.
التشغيل التلقائي باستخدام قوالب Resource Manager
قوالب Azure Resource Manager هي ملفات JSON تعريفية تستخدم لأتمتة نشر وتكوين موارد Azure. لتبديل الفتحات باستخدام قوالب Resource Manager، يمكنك تعيين خاصيتين على موارد Microsoft.Web/sites/slots وMicrosoft.Web /sites :
-
buildVersion
: خاصية سلسلة تمثل الإصدار الحالي من التطبيق المنشور في الفتحة. على سبيل المثالv1
، أو1.0.0.1
، أو2019-09-20T11:53:25.2887393-07:00
. -
targetBuildVersion
: خاصية سلسلة تحدد ماbuildVersion
يجب أن تحتوي عليه الفتحة.targetBuildVersion
إذا لم يساوي الحاليbuildVersion
، فإنه يقوم بتشغيل عملية التبديل عن طريق العثور على الفتحة مع المحددbuildVersion
.
مثال قالب إدارة الموارد
يقوم قالب Resource Manager التالي بتبديل فتحتين عن طريق تحديث buildVersion
الفتحة staging
وتعيين على targetBuildVersion
فتحة الإنتاج. يجب أن يكون لديك فتحة تسمى staging
.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"my_site_name": {
"defaultValue": "SwapAPIDemo",
"type": "String"
},
"sites_buildVersion": {
"defaultValue": "v1",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Web/sites/slots",
"apiVersion": "2018-02-01",
"name": "[concat(parameters('my_site_name'), '/staging')]",
"location": "East US",
"kind": "app",
"properties": {
"buildVersion": "[parameters('sites_buildVersion')]"
}
},
{
"type": "Microsoft.Web/sites",
"apiVersion": "2018-02-01",
"name": "[parameters('my_site_name')]",
"location": "East US",
"kind": "app",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
],
"properties": {
"targetBuildVersion": "[parameters('sites_buildVersion')]"
}
}
]
}
قالب Resource Manager هذا غير فعال. يمكنك تشغيله بشكل متكرر وإنتاج نفس حالة الفتحات. دون أي تغيير في القالب، لا تؤدي عمليات التشغيل اللاحقة لنفس القالب إلى تشغيل أي تبديل للفتحة لأن الفتحات موجودة بالفعل في الحالة المطلوبة.
استكشاف أخطاء التبديل وإصلاحها
إذا حدث أي خطأ أثناء تبديل الفتحة، يظهر الخطأ في D:\home\LogFiles\eventlog.xml. كما تم تسجيله في سجل الأخطاء الخاص بالتطبيق.
فيما يلي بعض أخطاء التبديل الشائعة:
تم توقيت طلب HTTP إلى جذر التطبيق. تنتظر عملية التبديل لمدة 90 ثانية لكل طلب HTTP، وتعيد المحاولة حتى خمس مرات. إذا انتهت مهلة جميع عمليات إعادة المحاولة، يتم إيقاف عملية التبديل.
قد تفشل تهيئة ذاكرة التخزين المؤقت المحلية عندما يتجاوز محتوى التطبيق الحصة النسبية للقرص المحلي المحددة لذاكرة التخزين المؤقت المحلية. لمزيد من المعلومات، راجع نظرة عامة على ذاكرة التخزين المؤقت المحلية.
أثناء عملية تحديث الموقع، يمكن أن يحدث الخطأ التالي لا يمكن تغيير الفتحة لأنه تم إعداد إعدادات التكوين الخاصة بها للتبديل. يمكن أن يحدث هذا الخطأ إذا انتهت المرحلة 1 من التبديل مع المعاينة (التبديل متعدد المراحل) ولكن لم يتم تنفيذ المرحلة 2 بعد. يمكن أن يحدث أيضا إذا فشلت المبادلة. هناك طريقتان لحل هذه المشكلة:
- إلغاء عملية التبديل التي تعيد تعيين الموقع إلى الحالة القديمة
- إكمال عملية التبديل التي تقوم بتحديث الموقع إلى الحالة الجديدة المطلوبة
لمعرفة كيفية إلغاء عملية التبديل أو إكمالها، راجع التبديل مع المعاينة (التبديل متعدد المراحل).
أثناء التجهيز المخصص، يتم إجراء طلبات HTTP داخليا دون المرور عبر عنوان URL الخارجي. يمكن أن تفشل مع قواعد معينة لإعادة كتابة عنوان URL في Web.config. على سبيل المثال، يمكن لقواعد إعادة توجيه أسماء المجالات أو فرض HTTPS منع طلبات التجهيز من الوصول إلى التعليمات البرمجية للتطبيق. لحل هذه المشكلة، قم بتعديل قواعد إعادة الكتابة عن طريق إضافة الشرطين التاليين:
<conditions> <add input="{WARMUP_REQUEST}" pattern="1" negate="true" /> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>
بدون إعداد مخصص، لا يزال بإمكان قواعد إعادة كتابة عنوان URL حظر طلبات HTTP. لحل هذه المشكلة، قم بتعديل قواعد إعادة الكتابة بإضافة الشرط التالي:
<conditions> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>
بعد تبديل الفتحات، قد يواجه التطبيق عمليات إعادة تشغيل غير متوقعة. تحدث إعادة التشغيل لأنه بعد التبديل، يخرج تكوين ربط اسم المضيف عن المزامنة. لا يتسبب هذا الموقف في حد ذاته في إعادة التشغيل. ومع ذلك، قد تكتشف بعض أحداث التخزين الأساسية، مثل تجاوز فشل وحدة التخزين، هذه التناقضات وتجبر جميع عمليات العامل على إعادة التشغيل. لتقليل هذه الأنواع من عمليات إعادة التشغيل، قم بتعيين
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1
إعداد التطبيق على جميع الفتحات. ومع ذلك، لا يعمل إعداد التطبيق هذا مع تطبيقات Windows Communication Foundation (WCF).