البرنامج التعليمي: إنشاء تطبيق متعدد المناطق متوفر بشكل كبير في Azure App Service

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

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

في هذا البرنامج التعليمي، ستتعلم كيفية نشر تطبيق ويب متعدد المناطق متوفر بشكل كبير. يتم الاحتفاظ بهذا السيناريو بسيطا عن طريق تقييد مكونات التطبيق على تطبيق ويب فقط وAzure Front Door، ولكن يمكن توسيع المفاهيم وتطبيقها على أنماط البنية الأساسية الأخرى. على سبيل المثال، إذا كان التطبيق الخاص بك يتصل بعرض قاعدة بيانات Azure أو حساب تخزين، فشاهد النسخ المتماثل الجغرافي النشط لقواعد بياناتSQL وخيارات التكرار لحسابات التخزين. للحصول على بنية مرجعية لسيناريو أكثر تفصيلا، راجع تطبيق الويب متعدد المناطق المتوفر بشكل كبير.

يوضح الرسم التخطيطي للبنية التالية البنية الأساسية التي تقوم بإنشائها في هذا البرنامج التعليمي. وهي تتكون من اثنين من خدمات التطبيقات المتطابقة في مناطق منفصلة، واحدة هي المنطقة النشطة أو الأساسية، والأخرى هي المنطقة الاحتياطية أو الثانوية. يتم استخدام Azure Front Door لتوجيه حركة المرور إلى App Services ويتم تكوين قيود الوصول بحيث يتم حظر الوصول المباشر إلى التطبيقات من الإنترنت. يشير الخط المنقط إلى أنه يتم إرسال حركة المرور إلى منطقة الاستعداد فقط إذا كانت المنطقة النشطة معطلة.

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

Architecture diagram of a multi-region App Service.

من خلال هذا البناء:

  • يتم نشر تطبيقات App Service المتطابقة في منطقتين منفصلتين.
  • يتم حظر حركة المرور العامة مباشرة إلى تطبيقات App Service.
  • يتم استخدام Azure Front Door لتوجيه نسبة استخدام الشبكة إلى المنطقة الأساسية/النشطة. تحتوي المنطقة الثانوية على App Service قيد التشغيل وجاهزة لخدمة نسبة استخدام الشبكة إذا لزم الأمر.

ستتعلم كيفية:

  • إنشاء خدمات تطبيقات متطابقة في مناطق منفصلة.
  • إنشاء Azure Front Door مع قيود الوصول التي تمنع الوصول العام إلى App Services.

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

إذا لم يكن لديك اشتراك في Azure، فأنشئ حساب Azure مجاني قبل أن تبدأ.

لإكمال هذا البرنامج التعليمي:

قم بإنشاء مثيلين لتطبيق الويب

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

لجعل الإدارة والتنظيف أبسط، يمكنك استخدام مجموعة موارد واحدة لجميع الموارد في هذا البرنامج التعليمي. ضع في اعتبارك استخدام مجموعات موارد منفصلة لكل منطقة/مورد لعزل مواردك بشكل أكبر في حالة التعافي من الكوارث.

قم بتشغيل الأمر التالي لإنشاء مجموعة الموارد الخاصة بك.

az group create --name myresourcegroup --location eastus

إعداد خطط App Service

قم بتشغيل الأوامر التالية لإنشاء خطط App Service. استبدل العناصر النائبة ل <app-service-plan-east-us> و <app-service-plan-west-us> باسمين فريدين حيث يمكنك بسهولة تحديد المنطقة التي توجد فيها.

az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus

az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus

إنشاء تطبيقات ويب

بمجرد إنشاء خطط App Service، قم بتشغيل الأوامر التالية لإنشاء تطبيقات الويب. استبدل العناصر النائبة ل <web-app-east-us> و <web-app-west-us> باسمين فريدين عموميين (الأحرف الصالحة هي a-zو 0-9و -) وتأكد من الانتباه إلى --plan المعلمة بحيث تضع تطبيقا واحدا في كل خطة (وبالتالي في كل منطقة). استبدل المعلمة <runtime> بإصدار اللغة لتطبيقك. قم بتشغيل az webapp list-runtimes لقائمة أوقات التشغيل المتوفرة. إذا كنت تخطط لاستخدام نموذج تطبيق Node.js المحدد في هذا البرنامج التعليمي في الأقسام التالية، فاستخدم NODE:18-lts وقت التشغيل الخاص بك.

az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>

az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>

دون اسم المضيف الافتراضي لكل تطبيق ويب حتى تتمكن من تحديد عناوين الواجهة الخلفية عند نشر Front Door في الخطوة التالية. يجب أن يكون بالتنسيق <web-app-name>.azurewebsites.net. يمكن العثور على أسماء المضيفين هذه عن طريق تشغيل الأمر التالي أو بالانتقال إلى صفحة نظرة عامة على التطبيق في مدخل Microsoft Azure.

az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"

إنشاء Azure Front Door

يمكن للنشر متعدد المناطق استخدام تكوين نشط-نشط أو نشط-سلبي. يقوم التكوين النشط-النشط بتوزيع الطلبات عبر مناطق نشطة متعددة. يحتفظ التكوين النشط-السلبي بتشغيل المثيلات في المنطقة الثانوية، ولكنه لا يرسل نسبة استخدام الشبكة هناك ما لم تفشل المنطقة الأساسية. يحتوي Azure Front Door على ميزة مضمنة تسمح لك بتمكين هذه التكوينات. لمزيد من المعلومات حول تصميم التطبيقات لقابلية الوصول العالية والتسامح مع الخطأ، راجع تصميم تطبيقات Azure للمرونة والتوافر.

إنشاء ملف تعريف Azure Front Door

يمكنك الآن إنشاء Azure Front Door Premium لتوجيه نسبة استخدام الشبكة إلى تطبيقاتك.

قم بتشغيل az afd profile create لإنشاء ملف تعريف Azure Front Door.

إشعار

إذا كنت ترغب في نشر Azure Front Door Standard بدلا من Premium، فاستبدل قيمة المعلمة --sku Standard_AzureFrontDoor. لا يمكنك نشر القواعد المدارة باستخدام نهج WAF إذا اخترت المستوى القياسي. للحصول على مقارنة مفصلة لمستويات التسعير، راجع مقارنة طبقة Azure Front Door.

az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor
المعلمة قيمة ‏‏الوصف
profile-name myfrontdoorprofile اسم ملف تعريف Azure Front Door، وهو فريد داخل مجموعة الموارد.
resource-group myresourcegroup مجموعة الموارد التي تحتوي على الموارد من هذا البرنامج التعليمي.
sku Premium_AzureFrontDoor مستوى التسعير لملف تعريف Azure Front Door.

إضافة نقطة نهاية

قم بتشغيل az afd endpoint create لإنشاء نقطة نهاية في ملف التعريف الخاص بك. يمكنك إنشاء عدة نقاط نهاية في ملف التعريف الخاص بك بعد الانتهاء من تجربة الإنشاء.

az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
المعلمة قيمة ‏‏الوصف
endpoint-name myendpoint اسم نقطة النهاية ضمن ملف التعريف، وهو فريد عالميا.
enabled-state Enabled ما إذا كان يجب تمكين نقطة النهاية هذه.

إنشاء مجموعة أصل

قم بتشغيل az afd origin-group create لإنشاء مجموعة أصل تحتوي على تطبيقي ويب.

az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50
المعلمة قيمة ‏‏الوصف
origin-group-name myorigingroup اسم مجموعة الأصل.
probe-request-type GET نوع طلب فحص السلامة الذي يتم إجراؤه.
probe-protocol Http بروتوكول لاستخدامه في فحص السلامة.
probe-interval-in-seconds 60 عدد الثوان بين فحوصات السلامة.
probe-path / المسار المتعلق بالأصل المستخدم لتحديد صحة الأصل.
sample-size 4 عدد العينات التي يجب مراعاتها لاتخاذ قرارات موازنة التحميل.
successful-samples-required 3 عدد العينات خلال فترة العينة التي يجب أن تنجح.
additional-latency-in-milliseconds 50 زمن الانتقال الإضافي بالمللي ثانية للفحوصات لتقع في مستودع زمن الانتقال الأدنى.

إضافة أصل إلى المجموعة

قم بتشغيل az afd origin create لإضافة أصل إلى مجموعة الأصل الخاصة بك. بالنسبة للمعلمة --host-name ، استبدل العنصر النائب باسم <web-app-east-us> التطبيق في تلك المنطقة. لاحظ أنه تم تعيين المعلمة --priority إلى 1، مما يشير إلى أنه يتم إرسال جميع نسبة استخدام الشبكة إلى تطبيقك الأساسي.

az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443
المعلمة قيمة ‏‏الوصف
host-name <web-app-east-us>.azurewebsites.net اسم مضيف تطبيق الويب الأساسي.
origin-name primaryapp اسم الأصل.
origin-host-header <web-app-east-us>.azurewebsites.net عنوان المضيف لإرسال الطلبات إلى هذا الأصل. إذا تركت هذا فارغا، يحدد اسم مضيف الطلب هذه القيمة. تتطلب أصول Azure CDN، مثل Web Apps وBlob Storage وCloud Services قيمة عنوان المضيف هذه لمطابقة اسم مضيف الأصل بشكل افتراضي.
priority 1 قم بتعيين هذه المعلمة إلى 1 لتوجيه كافة نسبة استخدام الشبكة إلى تطبيق الويب الأساسي.
weight 1000 وزن الأصل في مجموعة الأصل المحددة لموازنة التحميل. يجب أن يكون بين 1 و1000.
enabled-state Enabled ما إذا كان يجب تمكين هذا الأصل.
http-port 80 المنفذ المستخدم لطلبات HTTP إلى الأصل.
https-port 443 المنفذ المستخدم لطلبات HTTPS إلى الأصل.

كرر هذه الخطوة لإضافة الأصل الثاني. انتبه إلى المعلمة --priority . لهذا الأصل، يتم تعيينه إلى 2. يخبر إعداد الأولوية هذا Azure Front Door بتوجيه كافة نسبة استخدام الشبكة إلى الأصل الأساسي ما لم يتعطل الأساسي. إذا قمت بتعيين الأولوية لهذا الأصل إلى 1، فإن Azure Front Door يعامل كلا الأصلين على أنهما حركة مرور نشطة ومباشرة إلى كلتا المنطقتين. تأكد من استبدال مثيلي العنصر النائب <web-app-west-us> باسم تطبيق الويب هذا.

az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

إضافة مسار

قم بتشغيل az afd route create لتعيين نقطة النهاية إلى مجموعة الأصل. يقوم هذا المسار بإعادة توجيه الطلبات من نقطة النهاية إلى مجموعة الأصل الخاصة بك.

az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled 
المعلمة قيمة ‏‏الوصف
endpoint-name myendpoint اسم نقطة النهاية.
بروتوكول إعادة التوجيه طلب المطابقة البروتوكول الذي تستخدمه هذه القاعدة عند إعادة توجيه حركة المرور إلى الخلفيات.
route-name route اسم المسار.
إعادة توجيه https Enabled ما إذا كنت تريد إعادة توجيه حركة مرور HTTP تلقائيا إلى حركة مرور HTTPS.
supported-protocols Http Https قائمة البروتوكولات المدعومة لهذا المسار.
link-to-default-domain Enabled ما إذا كان هذا المسار مرتبطا بمجال نقطة النهاية الافتراضي.

السماح بحوالي 15 دقيقة لإكمال هذه الخطوة حيث يستغرق نشر هذا التغيير على مستوى العالم بعض الوقت. بعد هذه الفترة، يعمل Azure Front Door بكامل طاقته.

تقييد الوصول إلى تطبيقات الويب إلى مثيل Azure Front Door

في هذه المرحلة، لا يزال بإمكانك الوصول إلى تطبيقاتك مباشرة باستخدام عناوين URL الخاصة بها في هذه المرحلة. لضمان وصول نسبة استخدام الشبكة إلى تطبيقاتك فقط من خلال Azure Front Door، يمكنك تعيين قيود الوصول على كل تطبيق من تطبيقاتك. تعمل ميزات Front Door بشكل أفضل عندما تتدفق نسبة استخدام الشبكة فقط عبر Front Door. يجب عليك تكوين أصولك لمنع حركة المرور التي لم يتم إرسالها من خلال Front Door حتى الآن. وإلا، فقد تتجاوز نسبة استخدام الشبكة جدار حماية تطبيق الويب ل Front Door وحماية DDoS وميزات الأمان الأخرى. تنشأ نسبة استخدام الشبكة من Azure Front Door إلى تطبيقاتك من مجموعة معروفة من نطاقات IP المحددة في AzureFrontDoor.Backend علامة الخدمة. باستخدام قاعدة تقييد علامة الخدمة، يمكنك تقييد حركة المرور لتنشأ فقط من Azure Front Door.

قبل إعداد قيود الوصول إلى App Service، لاحظ معرف Front Door عن طريق تشغيل الأمر التالي. هذا المعرف مطلوب لضمان أن نسبة استخدام الشبكة تنشأ فقط من مثيل Front Door المحدد. يقوم تقييد الوصول بتصفية الطلبات الواردة استنادا إلى عنوان HTTP الفريد الذي يرسله Azure Front Door.

az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"

قم بتشغيل الأوامر التالية لتعيين قيود الوصول على تطبيقات الويب الخاصة بك. استبدل العنصر النائب ل <front-door-id> بالنتيجة من الأمر السابق. استبدل العناصر النائبة لأسماء التطبيقات.

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

اختبر Front Door

عندما تنشئ ملف تعريف Azure Front Door Standard/Premium، فذلك يستغرق بعض الدقائق من أجل نشر الإعدادات عالميًا بمجرد الانتهاء، يمكنك الوصول إلى مضيف الواجهة الأمامية الذي أنشأته.

قم بتشغيل az afd endpoint show للحصول على اسم مضيف نقطة نهاية Front Door.

az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

في مستعرض، انتقل إلى اسم مضيف نقطة النهاية الذي أرجعه الأمر السابق: <myendpoint>-<hash>.z01.azurefd.net. يجب أن يتم توجيه طلبك تلقائيا إلى التطبيق الأساسي في شرق الولايات المتحدة.

لاختبار تجاوز الفشل العمومي الفوري:

  1. افتح مستعرضا وانتقل إلى اسم مضيف نقطة النهاية: <myendpoint>-<hash>.z01.azurefd.net.

  2. أوقف التطبيق الأساسي عن طريق تشغيل az webapp stop.

    az webapp stop --name <web-app-east-us> --resource-group myresourcegroup
    
  3. قم بتحديث المستعرض. يجب أن تشاهد صفحة المعلومات نفسها لأن نسبة استخدام الشبكة موجهة الآن إلى التطبيق قيد التشغيل في غرب الولايات المتحدة.

    تلميح

    قد تحتاج إلى تحديث الصفحة عدة مرات حتى يكتمل تجاوز الفشل.

  4. الآن أوقف التطبيق الثانوي.

    az webapp stop --name <web-app-west-us> --resource-group myresourcegroup
    
  5. قم بتحديث المستعرض. هذه المرة، يجب أن تشاهد رسالة خطأ.

    Screenshot of the message: Both instances of the web app stopped.

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

    az webapp start --name <web-app-east-us> --resource-group myresourcegroup
    

لقد تحققت الآن من أنه يمكنك الوصول إلى تطبيقاتك من خلال Azure Front Door ووظائف تجاوز الفشل هذه كما هو مقصود. أعد تشغيل تطبيقك الآخر إذا انتهيت من اختبار تجاوز الفشل.

لاختبار قيود الوصول والتأكد من أنه لا يمكن الوصول إلى تطبيقاتك إلا من خلال Azure Front Door، افتح مستعرضا وانتقل إلى كل عنوان من عناوين URL لتطبيقك. للعثور على عناوين URL، قم بتشغيل الأوامر التالية:

az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"

az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"

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

تنظيف الموارد

في الخطوات السابقة، أنشأت موارد Azure في إحدى مجموعات الموارد. إذا لم تتوقع احتياجك لهذه الموارد في المستقبل، فاحذف مجموعة الموارد من خلال تشغيل الأمر التالي في Cloud Shell.

az group delete --name myresourcegroup

ولربما يستغرق التشغيل بضع دقائق.

النشر من ARM/Bicep

يمكن نشر الموارد التي أنشأتها في هذا البرنامج التعليمي باستخدام قالب ARM/Bicep. يتيح لك قالب Bicep لتطبيق الويب متعدد المناطق المتوفر بشكل كبير إنشاء حل آمن ومتاح للغاية ومتعدد المناطق من طرف إلى طرف باستخدام تطبيقي ويب في مناطق مختلفة خلف Azure Front Door.

لمعرفة كيفية نشر قوالب ARM/Bicep، راجع كيفية نشر الموارد باستخدام Bicep وAzure CLI.

الأسئلة الشائعة

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

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

بالنسبة لهذا البرنامج التعليمي، استخدمت Azure CLI لنشر موارد البنية الأساسية الخاصة بك. ضع في اعتبارك تكوين آلية نشر مستمرة لإدارة البنية الأساسية للتطبيق الخاص بك. نظرا لأنك تقوم بنشر الموارد في مناطق مختلفة، فأنت بحاجة إلى إدارة هذه الموارد بشكل مستقل عبر المناطق. لضمان تطابق الموارد عبر كل منطقة، يجب استخدام البنية الأساسية كتعليق برمجي (IaC) مثل قوالب Azure Resource Manager أو Terraform مع مسارات التوزيع مثل Azure Pipelines أو GitHub Actions. بهذه الطريقة، إذا تم تكوينه بشكل مناسب، فإن أي تغيير في الموارد سيؤدي إلى تشغيل التحديثات عبر جميع المناطق التي تم النشر إليها. لمزيد من المعلومات، راجع النشر المستمر إلى Azure App Service.

كيف يمكنني استخدام فتحات التقسيم المرحلي لممارسة النشر الآمن للإنتاج؟

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

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

بالنسبة للخطوات المتبقية في هذا البرنامج التعليمي، يجب أن يكون لديك تطبيق جاهز للنشر في App Services. إذا كنت بحاجة إلى نموذج تطبيق، يمكنك استخدام نموذج التطبيق Node.js مرحبًا بالعالم. قم بتشعب هذا المستودع حتى يكون لديك نسختك الخاصة.

تأكد من تعيين إعدادات مكدس App Service لتطبيقاتك. تشير إعدادات المكدس إلى اللغة أو وقت التشغيل المستخدم لتطبيقك. يمكن تكوين هذا الإعداد باستخدام Azure CLI مع az webapp config set الأمر أو في المدخل بالخطوات التالية. إذا كنت تستخدم نموذج Node.js، فقم بتعيين إعدادات المكدس إلى Node 18 LTS.

  1. الانتقال إلى تطبيقك وتحديد التكوين في جدول المحتويات الأيسر.
  2. حدد علامة التبويب إعدادات عامة.
  3. ضمن إعدادات المكدس، اختر القيمة المناسبة لتطبيقك.
  4. حدد حفظ ثم تابع لتأكيد التحديث.
  5. كرر هذه الخطوات لتطبيقاتك الأخرى.

قم بتشغيل الأوامر التالية لإنشاء فتحات مرحلية تسمى "المرحلة" لكل تطبيق من تطبيقاتك. استبدل العناصر النائبة لأسماء <web-app-east-us> التطبيقات و <web-app-west-us> بها.

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>

لإعداد النشر المستمر، يجب استخدام مدخل Microsoft Azure. للحصول على إرشادات مفصلة حول كيفية تكوين النشر المستمر مع موفري مثل GitHub Actions، راجع النشر المستمر إلى Azure App Service.

لتكوين النشر المستمر باستخدام GitHub Actions، أكمل الخطوات التالية لكل فتحة من فتحات التقسيم المرحلي.

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

  2. في الجزء الأيسر، حدد مركز التوزيع. ثم حدد Settings.

  3. في مربع المصدر ، حدد "GitHub" من خيارات CI/CD:

    Screenshot that shows how to choose the deployment source

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

  5. بعد تفويض حساب Azure الخاص بك مع GitHub، حدد المؤسسة والمستودع والفرع لتهيئة CI/CD إليه. إذا لم تتمكن من العثور على مؤسسة أو مستودع، فقد تحتاج إلى تمكين المزيد من الأذونات على GitHub. لمزيدٍ من المعلومات، راجع إدارة الوصول إلى مستودعات مؤسستك.

    1. إذا كنت تستخدم نموذج التطبيق Node.js، فاستخدم الإعدادات التالية.

      الإعداد القيمة‬
      المنظمة <your-GitHub-organization>
      المستودع nodejs-docs-hello-world
      فرع أساسي
  6. حدد حفظ.

    يتم الآن نشر عمليات التثبيت الجديدة في المستودع والفرع المحددين بشكل مستمر في فتحة تطبيق App Service. يمكنك تتبع الالتزامات وعمليات التوزيع في علامة تبويب السجلات.

تتم إضافة ملف سير عمل افتراضي يستخدم ملف تعريف نشر للمصادقة على App Service إلى مستودع GitHub الخاص بك. يمكنك عرض هذا الملف بالانتقال إلى <repo-name>/.github/workflows/ الدليل.

كيف أعمل تعطيل المصادقة الأساسية على App Service؟

ضع في اعتبارك تعطيل المصادقة الأساسية، ما يحد من الوصول إلى نقاط نهاية FTP وSCM للمستخدمين الذين يدعمهم معرف Microsoft Entra. إذا كنت تستخدم أداة نشر مستمرة لنشر التعليمات البرمجية المصدر للتطبيق الخاص بك، فإن تعطيل المصادقة الأساسية يتطلب خطوات إضافية لتكوين النشر المستمر. على سبيل المثال، لا يمكنك استخدام ملف تعريف نشر لأنه لا يستخدم بيانات اعتماد Microsoft Entra. بدلا من ذلك، تحتاج إلى استخدام إما كيان خدمة أو OpenID الاتصال.

لتعطيل المصادقة الأساسية لخدمة التطبيقات الخاصة بك، قم بتشغيل الأوامر التالية لكل تطبيق وفتحة عن طريق استبدال العناصر النائبة لأسماء <web-app-east-us> التطبيقات و <web-app-west-us> بها. تعطل المجموعة الأولى من الأوامر وصول FTP لمواقع الإنتاج وفتحات التقسيم المرحلي، وتعطل المجموعة الثانية من الأوامر الوصول الأساسي إلى منفذ WebDeploy وموقع SCM لمواقع الإنتاج وفتحات التقسيم المرحلي.

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false
az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

لمزيد من المعلومات حول تعطيل المصادقة الأساسية بما في ذلك كيفية اختبار ومراقبة عمليات تسجيل الدخول، راجع تعطيل المصادقة الأساسية في عمليات نشر App Service.

كيف أعمل نشر التعليمات البرمجية الخاصة بي باستخدام النشر المستمر إذا قمت بتعطيل المصادقة الأساسية؟

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

إذا قمت بتعطيل المصادقة الأساسية لخدمات التطبيقات الخاصة بك، فإن النشر المستمر يتطلب كيان خدمة أو الاتصال OpenID للمصادقة. إذا كنت تستخدم GitHub Actions كمستودع للتعليمات البرمجية، فشاهد البرنامج التعليمي خطوة بخطوة لاستخدام كيان خدمة أو OpenID الاتصال للنشر إلى App Service باستخدام إجراءات GitHub أو إكمال الخطوات في القسم التالي.

إنشاء كيان الخدمة وتكوين بيانات الاعتماد باستخدام إجراءات GitHub

لتكوين النشر المستمر باستخدام GitHub Actions وأساس الخدمة، استخدم الخطوات التالية.

  1. قم بتشغيل الأمر التالي لإنشاء كيان الخدمة. استبدل العناصر النائبة بأسماء التطبيقات <subscription-id> و. الإخراج هو كائن JSON مع بيانات اعتماد تعيين الدور التي توفر الوصول إلى تطبيقات App Service. انسخ كائن JSON هذا للخطوة التالية. يتضمن سر العميل الخاص بك، والذي يكون مرئيا فقط في هذا الوقت. من الممارسات الجيدة دائماً منح الحد الأدنى من الوصول. يقتصر النطاق في هذا المثال على التطبيقات فقط، وليس مجموعة الموارد بأكملها.

    az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-auth
    
  2. تحتاج إلى توفير بيانات اعتماد كيان الخدمة لإجراء Azure/تسجيل الدخول كجزء من سير عمل إجراء GitHub الذي تستخدمه. يمكن توفير هذه القيم إما مباشرة في سير العمل أو يمكن تخزينها في أسرار GitHub والإشارة إليها في سير العمل خاصتك. حفظ القيم على أنها أسرار GitHub هو الخيار الأكثر أمانًا.

    1. افتح مستودع GitHub وانتقل إلى الإعدادات> Security>Secrets and variables Actions>

    2. حدد New repository secret وأنشئ بيانات سرية لكل قيمة من القيم التالية. يمكن العثور على القيم في إخراج json الذي نسخته سابقا.

      الاسم القيمة‬
      AZURE_APP_ID <application/client-id>
      AZURE_PASSWORD <client-secret>
      AZURE_TENANT_ID <tenant-id>
      AZURE_SUBSCRIPTION_ID <subscription-id>

إنشاء سير عمل إجراءات GitHub

الآن بعد أن أصبح لديك كيان خدمة يمكنه الوصول إلى تطبيقات App Service، قم بتحرير مهام سير العمل الافتراضية التي تم إنشاؤها لتطبيقاتك عند تكوين النشر المستمر. يجب إجراء المصادقة باستخدام كيان الخدمة بدلا من ملف تعريف النشر. للحصول على نماذج مهام سير العمل، راجع علامة التبويب "كيان الخدمة" في إضافة ملف سير العمل إلى مستودع GitHub الخاص بك. يمكن استخدام نموذج سير العمل التالي لتطبيق نموذج Node.js الذي تم توفيره.

  1. افتح مستودع GitHub الخاص بتطبيقك وانتقل إلى <repo-name>/.github/workflows/ الدليل. يجب أن تشاهد مهام سير العمل التي تم إنشاؤها تلقائيا.

  2. لكل ملف سير عمل، حدد زر "القلم الرصاص" في أعلى اليمين لتحرير الملف. استبدل المحتويات بالنص التالي، والذي يفترض أنك قمت بإنشاء أسرار GitHub مسبقا لبيانات الاعتماد الخاصة بك. قم بتحديث العنصر النائب ل <web-app-name> ضمن قسم "env"، ثم قم بالتثبيت مباشرة إلى الفرع الرئيسي. يؤدي هذا التثبيت إلى تشغيل إجراء GitHub مرة أخرى ونشر التعليمات البرمجية الخاصة بك، هذه المرة باستخدام كيان الخدمة للمصادقة.

    
    name: Build and deploy Node.js app to Azure Web App
    
    on:
      push:
        branches:
          - main
      workflow_dispatch:
    
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
      NODE_VERSION: '18.x'                # set this to the node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
      AZURE_WEBAPP_SLOT_NAME: stage       # set this to your application's slot name
    
    jobs:
      build:
        runs-on: ubuntu-latest
    
        steps:
          - uses: actions/checkout@v2
    
          - name: Set up Node.js version
            uses: actions/setup-node@v1
            with:
              node-version: ${{ env.NODE_VERSION }}
    
          - name: npm install, build
            run: |
              npm install
              npm run build --if-present
    
          - name: Upload artifact for deployment job
            uses: actions/upload-artifact@v2
            with:
              name: node-app
              path: .
    
      deploy:
        runs-on: ubuntu-latest
        needs: build
        environment:
          name: 'stage'
          url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    
        steps:
          - name: Download artifact from build job
            uses: actions/download-artifact@v2
            with:
              name: node-app
    
          - uses: azure/login@v1
            with:
              creds: |
                {
                  "clientId": "${{ secrets.AZURE_APP_ID }}",
                  "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
                  "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
                  "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
                }
    
          - name: 'Deploy to Azure Web App'
            id: deploy-to-webapp
            uses: azure/webapps-deploy@v2
            with:
              app-name: ${{ env.AZURE_WEBAPP_NAME }}
              slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
              package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
    
          - name: logout
            run: |
              az logout
    

كيف يسمح لي توجيه حركة مرور الفتحات باختبار التحديثات التي أقوم بها لتطبيقاتي؟

يسمح لك توجيه نسبة استخدام الشبكة باستخدام الفتحات بتوجيه جزء محدد مسبقا من نسبة استخدام الشبكة للمستخدم إلى كل فتحة. في البداية، يتم توجيه 100٪ من نسبة استخدام الشبكة إلى موقع الإنتاج. ومع ذلك، لديك القدرة، على سبيل المثال، لإرسال 10٪ من نسبة استخدام الشبكة إلى فتحة التقسيم المرحلي. إذا قمت بتكوين توجيه حركة مرور الفتحة بهذه الطريقة، عندما يحاول المستخدمون الوصول إلى تطبيقك، يتم توجيه 10٪ منهم تلقائيا إلى فتحة التقسيم المرحلي دون أي تغييرات على مثيل Front Door. لمعرفة المزيد حول تبديل الفتحات وبيئات التقسيم المرحلي في App Service، راجع إعداد بيئات التدريج في Azure App Service.

كيف أعمل نقل التعليمات البرمجية الخاصة بي من فتحة التقسيم المرحلي إلى فتحة الإنتاج الخاصة بي؟

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

لإجراء التبديل، قم بتشغيل الأمر التالي لكل تطبيق. استبدل العنصر النائب ل <web-app-name>.

az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production

بعد بضع دقائق، يمكنك الانتقال إلى نقطة نهاية Front Door للتحقق من نجاح تبديل الفتحة.

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

كيف يمكنني استخدام Azure Front Door في عمليات النشر متعددة المناطق؟

إذا كنت قلقا بشأن الاضطرابات المحتملة أو المشكلات المتعلقة بالاستمرارية عبر المناطق، كما هو الحال في بعض العملاء الذين يرون إصدارا واحدا من تطبيقك بينما يرى آخرون إصدارا آخر، أو إذا كنت تجري تغييرات كبيرة على تطبيقاتك، فيمكنك إزالة الموقع الذي يخضع لتبديل الفتحة مؤقتا من مجموعة أصل Front Door. ثم يتم توجيه جميع حركة المرور إلى الأصل الآخر. انتقل إلى جزء Update origin group واحذف الأصل الذي يخضع للتغيير. بمجرد إجراء جميع التغييرات الخاصة بك والاستعداد لخدمة نسبة استخدام الشبكة هناك مرة أخرى، يمكنك العودة إلى نفس الجزء وتحديد + إضافة أصل لقراءة الأصل.

Screenshot showing how to remove an Azure Front Door origin.

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

لإثبات العمل مع أصول متعددة، في لقطة الشاشة التالية، هناك ثلاث مجموعات أصل. تتكون "MyOriginGroup" من كلا تطبيقي الويب، ومجموعتين أصل أخريين تتكون كل منهما من تطبيق الويب في منطقتهما. في المثال، يخضع التطبيق في المنطقة الأساسية لتغيير. قبل بدء هذا التغيير، كان المسار مقترنا ب "MySecondaryRegion" لذلك سيتم إرسال جميع نسبة استخدام الشبكة إلى التطبيق في المنطقة الثانوية خلال فترة التغيير. يمكنك تحديث المسار عن طريق تحديد Unassociated، والذي يظهر جزء Associate routes .

Screenshot showing how to associate routes with Azure Front Door.

كيف أعمل تقييد الوصول إلى موقع الأدوات المتقدمة؟

باستخدام خدمة Azure App، يتم استخدام موقع SCM/الأدوات المتقدمة لإدارة تطبيقاتك ونشر التعليمات البرمجية المصدر للتطبيق. ضع في اعتبارك تأمين موقع SCM/الأدوات المتقدمة لأن هذا الموقع لا يحتاج على الأرجح إلى الوصول إليه من خلال Front Door. على سبيل المثال، يمكنك إعداد قيود الوصول التي تسمح لك فقط بإجراء الاختبار وتمكين النشر المستمر من الأداة التي تختارها. إذا كنت تستخدم فتحات النشر، لمساحات الإنتاج على وجه التحديد، يمكنك رفض الوصول إلى موقع SCM تقريبا نظرا لأن الاختبار والتحقق من الصحة يتمان مع فتحات التقسيم المرحلي.

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