ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
عند نشر تطبيق الويب أو تطبيق الويب على Linux أو الواجهة الخلفية للأجهزة المحمولة أو تطبيق API إلى Azure App Service، يمكنك استخدام فتحة توزيع منفصلة بدلا من فتحة الإنتاج الافتراضية. يتوفر هذا الأسلوب إذا قمت بتشغيل في المستوى القياسي أو المتميز أو المعزول لخطة App Service. فتحات النشر هي تطبيقات مباشرة بأسماء مضيفين خاصة بهم. يمكن تبديل محتوى التطبيق وعناصر التكوين بين فتحتين للتوزيع، بما في ذلك فتحة الإنتاج.
نشر التطبيق الخاص بك إلى فتحة غير إنتاجية له المزايا التالية:
يمكنك التحقق من صحة تغييرات التطبيق قبل تبديل الفتحة إلى الإنتاج.
يمكنك التأكد من أن جميع مثيلات الفتحة يتم تجهيزها قبل تبديلها في الإنتاج. يلغي هذا الأسلوب وقت التعطل عند نشر تطبيقك. إعادة توجيه نسبة استخدام الشبكة سلسة. لا يتم إسقاط أي طلبات بسبب عمليات التبديل.
يمكنك أتمتة سير العمل بأكمله عن طريق تكوين التبديل التلقائي عندما لا تكون هناك حاجة إلى التحقق من صحة ما قبل التبديل.
بعد التبديل، تحتوي الفتحة التي تحتوي على تطبيق تم تنظيمه مسبقا الآن على تطبيق الإنتاج السابق. إذا لم تكن التغييرات التي تم تبديلها في فتحة الإنتاج كما تتوقع، يمكنك إجراء نفس التبديل على الفور للحصول على آخر موقع جيد معروف مرة أخرى.
لا توجد رسوم إضافية لاستخدام فتحات النشر. ويدعم كل مستوى خطة App Service عدداً مختلفاً من فتحات النشر. لمعرفة عدد الفتحات التي يدعمها مستوى التطبيق، راجع حدود App Service.
لتوسيع نطاق تطبيقك إلى مستوى مختلف، تأكد من أن المستوى الهدف يدعم عدد الفتحات التي يستخدمها تطبيقك بالفعل. على سبيل المثال، إذا كان تطبيقك يحتوي على أكثر من خمس فتحات، فلا يمكنك تقليصه إلى المستوى القياسي. يدعم المستوى القياسي خمس فتحات نشر فقط.
يكمل الفيديو التالي الخطوات الواردة في هذه المقالة من خلال توضيح كيفية إعداد بيئات التشغيل المرحلي في Azure App Service.
المتطلبات الأساسية
- أذونات لتنفيذ عملية الفتحة التي تريدها. للحصول على معلومات حول الأذونات المطلوبة، راجع عمليات موفر الموارد. ابحث عن فتحة، على سبيل المثال.
إضافة فتحة
لتمكين فتحات نشر متعددة، يجب أن يكون التطبيق قيد التشغيل في المستوى القياسي أو المتميز أو المعزول.
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
في مدخل Microsoft Azure، انتقل إلى صفحة إدارة التطبيق.
في القائمة اليسرى، حدد Deployment>Deployment slots. ثمَّ حَدِّد إضَافَة.
ملاحظة
إذا لم يكن التطبيق موجودا بالفعل في المستوى القياسي أو المتميز أو المعزول، فحدد ترقية. انتقل إلى علامة التبويب مقياس لتطبيقك قبل المتابعة.
في مربع الحوار إضافة فتحة ، امنح الفتحة اسما، وحدد ما إذا كنت تريد استنساخ تكوين تطبيق من فتحة نشر أخرى. حدد إضافة للمتابعة.
يمكنك استنساخ تكوين من أي فتحة موجودة. تتضمن الإعدادات التي يمكن استنساخها إعدادات التطبيق وسلاسل الاتصال وإصدارات إطار عمل اللغة ومآخذ الويب وإصدار HTTP وبت النظام الأساسي.
ملاحظة
حاليا، لا يتم استنساخ نقطة نهاية خاصة عبر الفتحات.
بعد إدخال الإعدادات، حدد إغلاق لإغلاق مربع الحوار. تظهر الفتحة الجديدة الآن على صفحة Deployment slots . بشكل افتراضي، يتم تعيين %نسبة استخدام الشبكة إلى 0 للفتحة الجديدة، مع توجيه جميع حركة مرور العملاء إلى فتحة الإنتاج.
حدد فتحة النشر الجديدة لفتح صفحة الموارد الخاصة بها.
تحتوي فتحة التقسيم المرحلي على صفحة إدارة تماما مثل أي تطبيق App Service آخر. يمكنك تغيير تكوين الفتحة. لتذكيرك بأنك تعرض فتحة التوزيع، يظهر اسم التطبيق واسم الفتحة في عنوان URL. نوع التطبيق هو App Service (Slot) . يمكنك أيضا رؤية الفتحة كتطبيق منفصل في مجموعة الموارد الخاصة بك، بنفس التعيينات.
في صفحة موارد الفتحة، حدد عنوان URL للتطبيق. تحتوي فتحة التوزيع على اسم المضيف الخاص بها وهي أيضا تطبيق مباشر. للحد من الوصول العام إلى فتحة النشر، راجع إعداد قيود الوصول إلى Azure App Service.
لا تحتوي فتحة النشر الجديدة على محتوى، حتى إذا قمت بنسخ الإعدادات من فتحة مختلفة. على سبيل المثال، يمكنك النشر إلى هذه الفتحة باستخدام Git. ويمكنك النشر إلى الفتحة من مستودع تخزين مختلف أو من فرع مستودع تخزين مختلف. يمكن أن توفر المقالة الحصول على ملف تعريف نشر من Azure App Service المعلومات المطلوبة للتوزيع في الفتحة. يمكن ل Visual Studio استيراد ملف التعريف لنشر المحتويات إلى الفتحة.
يحتوي عنوان URL الخاص بالفتحة على التنسيق http://sitename-slotname.azurewebsites.net. للحفاظ على طول عنوان URL ضمن حدود DNS الضرورية، يتم اقتطاع اسم الموقع في 40 حرفا. يجب أن يكون اسم الموقع المدمج واسم الفتحة أقل من 59 حرفا.
فهم ما يحدث أثناء التبديل
خطوات عملية التبديل
عند تبديل فتحتين، تقوم App Service بما يلي للتأكد من أن فتحة الهدف لا تواجه وقت تعطل:
قم بتطبيق الإعدادات التالية من الفتحة الهدف (على سبيل المثال، فتحة الإنتاج) على جميع مثيلات فتحة المصدر:
- إعدادات التطبيق الخاصة بالفتحة وسلاسل الاتصال، إن أمكن
- إعدادات النشر المستمر، إذا تم تمكينها
- إعدادات مصادقة 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 بأن الإعداد غير قابل للتبديل.
حدد تطبيق.
تبديل فتحات التوزيع
يمكنك تبديل فتحات النشر على صفحة فتحات النشر الخاصة بتطبيقك وصفحة نظرة عامة .
وقبل تبديل تطبيق من فتحة نشر إلى فتحة إنتاج، تأكد من أن الإنتاج هو فتحة الهدف وأن جميع الإعدادات في فتحة المصدر قد تم تكوينها تماماً كما تريدها في الإنتاج.
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
انتقل إلى صفحة Deployment slots الخاصة بالتطبيق وحدد Swap.
يعرض مربع الحوار Swap الإعدادات في فتحات المصدر والهدف المحددة التي سيتم تغييرها.
حدد الفتحات المطلوبة Source وTarget. عادةً ما يكون الهدف هو فتحة الإنتاج. أيضا، حدد علامات التبويب تغييرات فتحة المصدروتغييرات فتحة الهدف وتحقق من أن تغييرات التكوين متوقعة. عند الانتهاء، يمكنك تبديل الفتحات على الفور عن طريق تحديد Start Swap.
لمعرفة كيفية تشغيل فتحة الهدف مع الإعدادات الجديدة قبل حدوث التبديل، لا تحدد Start Swap. اتبع الإرشادات الواردة في Swap with preview لاحقا في هذه المقالة.
حدد إغلاق لإغلاق مربع الحوار.
إذا واجهت أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها لاحقا في هذه المقالة.
التبديل مع المعاينة (التبديل متعدد الأطوار)
قبل التبديل إلى الإنتاج باعتباره فتحة الهدف، تحقق من أن التطبيق يعمل بالإعدادات التي تم تبديلها. ويتم أيضاً تجهيز فتحة المصدر قبل اكتمال التبديل، وهو أمر مرغوب فيه للتطبيقات ذات المهام الحرجة.
عند إجراء تبديل باستخدام المعاينة، تقوم App Service بتنفيذ نفس عملية التبديل ولكنها تتوقف مؤقتا بعد الخطوة الأولى. ومن ثَم يمكنك التحقق من النتيجة على فتحة التشغيل المرحلي قبل إتمام التبديل.
وإذا ألغيت التبديل، فإن App Service يعيد تطبيق عناصر التكوين على فتحة المصدر.
ملاحظة
لا يمكنك استخدام التبديل مع المعاينة عند تمكين مصادقة الموقع في إحدى الفتحات.
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
اتبع الخطوات الواردة في قسم Swap deployment slots ، ولكن حدد Perform swap with preview.
يوضح لك مربع الحوار كيفية تغيير التكوين في فتحة المصدر في المرحلة الأولى، وكيفية تغيير فتحة المصدر والهدف في المرحلة الثانية.
عندما تكون مستعداً لبدء التبديل، حدد Start Swap.
عند انتهاء المرحلة الأولى، يقوم مربع الحوار بإعلامك.
عندما تكون جاهزا لإكمال التبديل المعلق، حدد إجراء "Complete Swap in Swap"، ثم حدد الزر Complete Swap .
لإلغاء تبديل معلق، حدد إلغاء التبديل بدلا من ذلك، ثم حدد الزر إلغاء التبديل .
عند الانتهاء، حدد إغلاق لإغلاق مربع الحوار.
إذا واجهت أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها لاحقا في هذه المقالة.
التراجع عن المبادلة
في حالة حدوث أي أخطاء في فتحة الهدف (على سبيل المثال، فتحة الإنتاج) بعد تبديل الفتحة، قم بإعادة الفتحات إلى حالات ما قبل التبديل عن طريق تبديل نفس الفتحتين على الفور.
تكوين التبديل التلقائي
يبسط التبديل التلقائي سيناريوهات Azure DevOps حيث تريد نشر تطبيقك باستمرار مع صفر من عمليات البدء الباردة ووقت تعطل صفري لعملاء التطبيق. عند تمكين التبديل التلقائي من فتحة إلى الإنتاج، في كل مرة تدفع فيها تغييرات التعليمات البرمجية إلى تلك الفتحة، تقوم App Service تلقائيا بتبديل التطبيق إلى الإنتاج بعد تجهيزه في فتحة المصدر.
ملاحظة
التبديل التلقائي غير مدعوم في تطبيقات الويب على Linux وفي تطبيق الويب للحاويات.
قبل تكوين التبديل التلقائي لفتحة الإنتاج، ضع في اعتبارك اختبارها على فتحة هدف غير منتج.
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
انتقل إلى صفحة موارد التطبيق. حدد Deployment>Deployment slots، ثم حدد فتحة المصدر المطلوبة.
في القائمة اليسرى، حدد الإعدادات>للتكوين>.
بالنسبة إلى تمكين التبديل التلقائي، حدد تشغيل. بالنسبة إلى فتحة توزيع التبديل التلقائي، حدد فتحة الهدف. ثم حدد حفظ على شريط الأوامر.
تشغيل دفع التعليمات البرمجية إلى فتحة المصدر. يحدث التبديل التلقائي بعد وقت قصير. ينعكس التحديث في عنوان 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> عنصر التكوين هو جزء من كل بدء تشغيل للتطبيق، بينما تنطبق إعدادات التطبيق لسلوك التجهيز فقط على تبديل الفتحات.
إذا واجهت أي مشاكل، فراجع استكشاف أخطاء التبديل وإصلاحها لاحقا في هذه المقالة.
مراقبة التبديل
إذا كانت عملية التبديل تستغرق وقتا طويلا لإكمالها، يمكنك الحصول على معلومات حول عملية التبديل في سجل النشاط.
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
في صفحة موارد التطبيق في المدخل، في القائمة اليسرى، حدد Activity log.
ستظهر عملية التبديل في استعلام السجل كـ
Swap Web App Slots. لعرض التفاصيل، يمكنك توسيعها وتحديد أحد العمليات الفرعية أو الأخطاء.
توجيه نسبة استخدام الشبكة للإنتاج تلقائيا
بشكل افتراضي، يتم توجيه جميع طلبات العميل إلى عنوان URL لإنتاج التطبيق إلى فتحة الإنتاج. يمكنك توجيه جزء من نسبة استخدام الشبكة إلى فتحة أخرى. هذه الميزة مفيدة إذا كنت بحاجة إلى ملاحظات المستخدم لتحديث جديد ولكنك لست مستعدا لإصداره في الإنتاج.
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
انتقل إلى صفحة موارد تطبيق الويب وحدد>Deployment Deployment slots.
في العمود نسبة استخدام الشبكة % للفتحة التي تريد التوجيه إليها، حدد نسبة مئوية (بين 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. هذا التكوين هو سيناريو متقدم حيث يمكنك إخفاء فتحة التقسيم المرحلي عن الجمهور مع السماح للفرق الداخلية باختبار التغييرات على الفتحة.
حذف فتحة
- مدخل Microsoft Azure
- Azure CLI
- Azure PowerShell
ابحث عن التطبيق وحدده.
حدد فتحة Deployment >Deployment slots>لحذف>Overview. يظهر نوع التطبيق ك App Service (Slot) لتذكيرك بأنك تعرض فتحة توزيع.
أوقف الفتحة وقم بتعيين نسبة استخدام الشبكة في الفتحة إلى الصفر.
في شريط الأوامر، حدد حذف.
أتمتة باستخدام قوالب 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
يقوم قالب 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، وتعيد المحاولة حتى خمس مرات. إذا انتهت مهلة جميع عمليات إعادة المحاولة، يتم إيقاف عملية التبديل.
قد تفشل تهيئة ذاكرة التخزين المؤقت المحلية عندما يتجاوز محتوى التطبيق الحصة النسبية للقرص المحلي المحددة لذاكرة التخزين المؤقت المحلية. لمزيد من المعلومات، راجع نظرة عامة على ذاكرة التخزين المؤقت المحلية ل Azure App Service.
أثناء عملية تحديث الموقع، يمكن أن يحدث الخطأ التالي: "لا يمكن تغيير الفتحة لأنه تم إعداد إعدادات التكوين الخاصة بها للتبديل." يمكن أن يحدث هذا الخطأ إذا انتهت المرحلة الأولى في تبديل متعدد المراحل ولكن لم تحدث المرحلة الثانية. يمكن أن يحدث أيضا إذا فشلت المبادلة. هناك طريقتان لحل هذه المشكلة:
- قم بإلغاء عملية التبديل، التي تعيد تعيين الموقع إلى الحالة القديمة.
- أكمل عملية التبديل، التي تحدث الموقع إلى الحالة الجديدة المطلوبة.
لمعرفة كيفية إلغاء عملية التبديل أو إكمالها، راجع التبديل مع المعاينة (التبديل متعدد المراحل) سابقا في هذه المقالة.
أثناء التجهيز المخصص، يتم إجراء طلبات 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).