Share via

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

  • مقالة

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

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

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

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

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

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

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

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

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

إضافة فتحة

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

  1. في مدخل Azure⁧⁩، انتقل إلى صفحة إدارة التطبيق.

  2. في الجزء الأيمن، حدد Deployment slots>Add Slot.

    إشعار

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

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

    A screenshot that shows how to configure a new deployment slot called 'staging' in the portal.

    يمكنك استنساخ تكوين من أي فتحة موجودة. تتضمن الإعدادات التي يمكن استنساخها إعدادات التطبيق وسلاسل الاتصال وإصدارات إطار عمل اللغة ومآخذ الويب وإصدار HTTP وبت النظام الأساسي.

    إشعار

    حاليا، لا يتم استنساخ نقطة نهاية خاصة عبر الفتحات.

  4. بعد إضافة الفتحة، حدد إغلاق لإغلاق مربع الحوار. يتم الآن عرض الفتحة الجديدة في صفحة Deployment slots. بشكل افتراضي، يتم تعيين نسبة استخدام الشبكة % إلى 0 للفتحة الجديدة، مع توجيه جميع نسبة استخدام شبكة العملاء إلى فتحة الإنتاج.

  5. حدد فتحة النشر الجديدة لفتح صفحة موارد تلك الفتحة.

    A screenshot that shows how to open deployment slot's management page in the portal.

    تحتوي فتحة التقسيم المرحلي على صفحة إدارة تماما مثل أي تطبيق App Service آخر. يمكنك تغيير تكوين الفتحة. لتذكيرك بأنك تعرض فتحة التوزيع، يتم عرض اسم التطبيق كاسم< التطبيق/>اسم< الفتحة>، ونوع التطبيق هو App Service (Slot). يمكنك أيضًا رؤية الفتحة كتطبيق منفصل في مجموعة الموارد الخاصة بك، بنفس التعيينات.

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

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

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

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

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

عند تبديل فتحتين (عادة من فتحة التقسيم المرحلي كمصدر إلى فتحة الإنتاج كهدف)، تقوم App Service بما يلي للتأكد من أن فتحة الهدف لا تواجه وقت تعطل:

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

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

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

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

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

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

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

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

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

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

إشعار

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

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

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

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

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

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

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

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

إشعار

لجعل الإعدادات قابلة للتبديل، أضف إعداد التطبيق WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS في كل فتحة من التطبيق واضبط قيمته على 0 أو false. هذه الإعدادات إما قابلة للتبديل أو غير قابلة للتبديل على الإطلاق. لا يمكنك جعل بعض الإعدادات قابلة للتبديل فقط وليس الإعدادات الأخرى. لا يتم تبادل الهويات المُدارة مطلقاً ولا تتأثر بإعداد تطبيق التجاوز هذا.

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

لتكوين إعداد تطبيق أو سلسلة اتصال للالتزام بفتحة معينة (غير متبادلة)، انتقل إلى صفحة التكوين لتلك الفتحة. أضف إعداداً أو قم بتحريره، ثم حدد إعداد فتحة التوزيع. يؤدي تحديد خانة الاختيار هذه إلى إعلام App Service بأن الإعداد غير قابل للتبديل.

A screenshot that shows how to configure an app setting as a slot setting in the Azure portal.

تبديل فتحتين

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

هام

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

لتبديل فتحات النشر:

  1. انتقل إلى صفحة Deployment slots الخاصة بالتطبيق وحدد Swap.

    A screenshot that shows how to initiate a swap operation in the portal.

    سيعرض مربع الحوار Swap الإعدادات في فتحات الهدف والمصدر المحددة التي سيتم تغييرها.

  2. حدد الفتحات المطلوبة Source وTarget. عادةً ما يكون الهدف هو فتحة الإنتاج. حدد أيضاً علامتي التبويب Source Changes وTarget Changes وتحقق من توقع تغييرات التكامل. عند الانتهاء، يمكنك تبديل الفتحات فوراً عن طريق تحديد Swap.

    A screenshot that shows how to configure and complete a swap in the portal.

    لمعرفة كيفية تشغيل فتحة الهدف بالإعدادات الجديدة قبل حدوث التبديل فعلياً، لا تحدد التبديل، ولكن اتبع الإرشادات الواردة في Swap with preview.

  3. عند الانتهاء، أغلق مربع الحوار عن طريق تحديد Close.

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

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

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

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

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

إشعار

لا يمكن استخدام التبديل مع المعاينة عند تمكين مصادقة الموقع في إحدى الفتحات.

للتبديل مع المعاينة:

  1. اتبع الخطوات السابقة في تبديل فتحات النشر ولكن حدد Perform swap with preview.

    A screenshot that shows how to configure a swap with preview in the portal.

    سيعرض لك مربع الحوار كيفية تغير التكوين في فتحة المصدر في المرحلة 1، وكيف تتغير فتحة المصدر وفتحة الهدف في المرحلة 2.

  2. عندما تكون مستعداً لبدء التبديل، حدد Start Swap.

    عند انتهاء المرحلة 1، يتم إعلامك في مربع الحوار. قم بمعاينة التبديل في فتحة المصدر عن طريق الانتقال إلى https://<app_name>-<source-slot-name>.azurewebsites.net.

  3. عندما تكون مستعداً لإكمال التبديل المعلق، حدد Complete Swap في Swap action وحدد Complete Swap.

    لإلغاء تبديل معلق، حدد إلغاء التبديل بدلا من ذلك، ثم حدد إلغاء التبديل في الأسفل.

  4. عند الانتهاء، أغلق مربع الحوار عن طريق تحديد Close.

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

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

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

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

إشعار

التبديل التلقائي غير مدعوم في تطبيقات الويب على Linux وWeb App للحاويات.

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

إشعار

قبل تكوين التبديل التلقائي لفتحة الإنتاج، ضع في اعتبارك اختبار التبديل التلقائي على فتحة هدف غير منتج.

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

  1. انتقل إلى صفحة موارد التطبيق. حدد Deployment slots><desired source slot>>Configuration>General settings.

  2. بالنسبة إلى تمكين التبديل التلقائي، حدد تشغيل. ثم حدد فتحة الهدف المطلوبة لفتحة نشر التبديل التلقائي، وحدد Save في شريط الأوامر.

    A screenshot that shows how to configure auto swap into the production slot in the portal.

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

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

  1. انتقل إلى صفحة موارد التطبيق وحدد Deployment slots.

  2. في العمود Traffic % للفتحة التي تريد التوجيه إليها، حدد نسبة مئوية (بين 0 و100) لتمثل مقدار إجمالي نقل البيانات التي تريد توجيهها. حدد حفظ.

    A screenshot that shows how to route a percentage of request traffic to a deployment slot, in the portal.

بعد حفظ الإعداد، يتم توجيه النسبة المئوية المحددة للعملاء عشوائيا إلى فتحة عدم الإنتاج.

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

حذف فتحة

ابحث عن التطبيق وحدده. حدد فتحات><النشر لحذف>>نظرة عامة. يتم عرض نوع التطبيق ك App Service (Slot) لتذكيرك بأنك تعرض فتحة توزيع. قبل حذف فتحة، تأكد من إيقاف الفتحة وتعيين نسبة استخدام الشبكة في الفتحة إلى الصفر. حدد Delete في شريط الأوامر.

A screenshot that shows how to delete a deployment slot in the portal.

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

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

  • في أثناء التجهيز المخصص، يتم إجراء طلبات 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).

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

حظر الوصول إلى الفتحات غير الإنتاجية