إعداد بيئات التدريج في Azure App Service

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

نشر التطبيق الخاص بك إلى فتحة غير إنتاجية له المزايا التالية:

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

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

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

يوضح لك هذا الفيديو كيفية إعداد بيئات التشغيل المرحلي في Azure App Service.

يتم أيضا وصف الخطوات الواردة في الفيديو في الأقسام التالية.

المتطلبات الأساسية

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

إضافة فتحة

يجب أن يكون التطبيق قيد التشغيل في المستوى القياسي أو المتميز أو المعزول لتمكين فتحات نشر متعددة.

az webapp deployment slot create --name <app-name> --resource-group <group-name> --slot <slot-name>

New-AzWebAppSlot -ResourceGroupName <group-name> -Name <app-name> -Slot <slot-name> -AppServicePlan <plan-name>

لا تحتوي فتحة النشر الجديدة على أي محتوى، حتى إذا قمت باستنساخ الإعدادات من فتحة مختلفة. على سبيل المثال، يمكنك النشر إلى هذه الفتحة باستخدام Git. ويمكنك النشر إلى الفتحة من مستودع تخزين مختلف أو من فرع مستودع تخزين مختلف. يمكن أن يوفر الحصول على ملف تعريف النشر من Azure App Service المعلومات المطلوبة للتوزيع في الفتحة. يمكن ل Visual Studio استيراد ملف التعريف لنشر المحتويات إلى الفتحة.

يحتوي عنوان URL الخاص بالفتحة على التنسيق http://sitename-slotname.azurewebsites.net. للحفاظ على طول عنوان URL ضمن حدود DNS الضرورية، يتم اقتطاع اسم الموقع في 40 حرفا. يجب أن يكون اسم الموقع المدمج واسم الفتحة أقل من 59 حرفا.

ماذا يحدث أثناء التبديل

خطوات عملية التبديل

عند تبديل فتحتين، تقوم App Service بما يلي للتأكد من أن فتحة الهدف لا تواجه وقت تعطل:

1. قم بتطبيق الإعدادات التالية من الفتحة الهدف (على سبيل المثال، فتحة الإنتاج) على جميع مثيلات فتحة المصدر:

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

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

2. انتظر حتى يكمل كل مثيل في فتحة المصدر عملية إعادة تشغيله. وإذا فشلت إعادة تشغيل أي مثيل، فإن عملية التبديل تُعيد جميع التغييرات إلى فتحة المصدر وتوقف العملية.

3. إذا تم تمكين ذاكرة التخزين المؤقت المحلية، فقم بتشغيل تهيئة ذاكرة التخزين المؤقتة المحلية عن طريق إجراء طلب HTTP إلى جذر التطبيق ("/") في كل مثيل من فتحة المصدر. وانتظر حتى يقوم كل مثيل بإرجاع أي استجابة HTTP. يؤدي تهيئة ذاكرة التخزين المؤقتة المحلية إلى عملية إعادة تشغيل أخرى على كل مثيل.

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

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

   إذا قام مثيل بإرجاع أي استجابة HTTP، فسيتم اعتباره جاهزاً.

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

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

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

ما هي الإعدادات التي يتم تبديلها؟

عند نسخ تكوين من فتحة نشر أخرى، يكون التكوين المنسوخ قابلاً للتحرير. تتبع بعض عناصر التكوين المحتوى عبر المبادلة (ليست خاصة بالفتحة). تبقى عناصر التكوين الأخرى في نفس الفتحة بعد التبديل (فتحة محددة). تظهر القوائم التالية الإعدادات التي تتغير عند تبديل الفتحات.

الإعدادات التي تم تبديلها:

• مكدس اللغة وإصدارها، 32/64 بت
• إعدادات التطبيق (يمكن تهيئتها لتلتزم بفتحة)
• سلاسل الاتصال (يمكن تهيئتها لتلتزم بفتحة)
• حسابات التخزين المثبتة (يمكن تكوينها للتمسك بفتحة)
• تعيينات المعالج
• الشهادات العامة
• محتوى WebJobs
• اتصالات مختلطة *
• نقاط نهاية الخدمة *
• Azure Content Delivery Network *
• تعيينات المسار

الميزات المميزة بعلامة النجمة (*) مخططة بحيث لا يتم تبديلها.

الإعدادات التي لا يتم تبديلها:

• الإعدادات العامة غير المذكورة في الإعدادات التي تم تبديلها
• نشر نقاط النهاية
• أسماء المجالات المخصصة
• الشهادات غير العامة وإعدادات TLS/SSL
• إعدادات المقياس
• جدولة WebJobs
• قيود IP
• قيد التشغيل دائمًا
• إعدادات التشخيص
• مشاركة الموارد عبر المنشأ (CORS)
• تكامل الشبكة الظاهرية
• الهويات المدارة والإعدادات ذات الصلة
• الإعدادات التي تنتهي باللاحقة _EXTENSION_VERSION
• الإعدادات التي تم إنشاؤها بواسطة Service Connector

لتكوين إعداد تطبيق أو سلسلة الاتصال الالتزام بفتحة معينة، والتي لم يتم تبديلها، انتقل إلى صفحة Settings>Environment Variable لتلك الفتحة. أضف إعداداً أو قم بتحريره، ثم حدد Deployment slot setting. يؤدي تحديد هذا الخيار إلى إعلام App Service بأن الإعداد غير قابل للتبديل.

تبديل فتحتين

يمكنك تبديل فتحات النشر في صفحة فتحات النشر الخاصة بالتطبيق وصفحة النظرة العامة. لمزيد من المعلومات حول تبديل الفتحة، راجع ما يحدث أثناء التبديل.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>"

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

تبديل مع المعاينة (التبديل متعدد المراحل)

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

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

وإذا ألغيت التبديل، فإن App Service يعيد تطبيق عناصر التكوين على فتحة المصدر.

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action preview

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action swap

az webapp deployment slot swap --resource-group <group-name> --name <app-name> --slot <source-slot-name> --target-slot production --action reset

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ApplySlotConfig

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction CompleteSlotSwap

Switch-AzWebAppSlot -SourceSlotName "<source-slot-name>" -DestinationSlotName "production" -ResourceGroupName "<group-name>" -Name "<app-name>" -SwapWithPreviewAction ResetSlotSwap

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

التراجع عن المبادلة

في حالة حدوث أي أخطاء في فتحة الهدف (على سبيل المثال، فتحة الإنتاج) بعد تبديل الفتحة، قم بإعادة الفتحات إلى حالات ما قبل التبديل عن طريق تبديل نفس الفتحتين على الفور.

تكوين التبديل التلقائي

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

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name>

az webapp deployment slot auto-swap --name <app-name> --resource-group <group-name> --slot <source-slot-name> --disable

Set-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<source-slot-name>" -AutoSwapSlotName "production"

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

تحديد التجهيز المخصص

قد تتطلب بعض التطبيقات إجراءات تجهيز مخصصة قبل التبديل. 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 قيم المثال أو المسار الجذر، /.

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

مراقبة التبديل

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

az monitor activity-log list --resource-group <group-name> --query "[?contains(operationName.value,'Microsoft.Web/sites/slots/slotsswap/action')]"

Get-AzLog -ResourceGroup <group-name> -StartTime 2025-01-01 | where{$_.OperationName -eq 'Swap Web App Slots'}

توجيه نقل بيانات الإنتاج تلقائياً

ويتم توجيه جميع طلبات العميل إلى عنوان URL الخاص بإنتاج التطبيق (http://<app_name>.azurewebsites.net) إلى فتحة الإنتاج بشكل افتراضي. ويمكنك توجيه جزء من نقل البيانات إلى فتحة أخرى. وتعد هذه الميزة مفيدة إذا كنت بحاجة إلى ملاحظات المستخدم لتحديث جديد، لكنك لست مستعداً لإصداره للإنتاج.

az webapp traffic-routing set --resource-group <group-name> --name <app-name> --distribution <slot-name>=15

Add-AzWebAppTrafficRouting -ResourceGroupName "<group-name>" -WebAppName "<app-name>" -RoutingRule @{ActionHostName='<app-name>-<slot-name>.azurewebsites.net';ReroutePercentage='15';Name='<slot-name>'}

بعد توجيه العميل تلقائيا إلى فتحة معينة، يتم تثبيته في تلك الفتحة لمدة ساعة واحدة أو حتى يتم حذف ملفات تعريف الارتباط. في مستعرض العميل، يمكنك معرفة الفتحة التي تم تثبيت جلستك عليها من خلال النظر إلى ملف تعريف الارتباط 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. هذا التكوين هو سيناريو متقدم حيث يمكنك إخفاء فتحة التقسيم المرحلي عن الجمهور مع السماح للفرق الداخلية باختبار التغييرات على الفتحة.

حذف فتحة

az webapp deployment slot delete --name <app-name> --resource-group <group-name> --slot <slot-name>

Remove-AzWebAppSlot -ResourceGroupName "<group-name>" -Name "<app-name>" -Slot "<slot-name>"

التشغيل التلقائي باستخدام قوالب 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).

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