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

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

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

يشرح هذا الدرس كيفية نشر تطبيق ويب متعدد المناطق عالي التوفرة. تنفذ العملية سيناريو بسيط يتكون من تطبيق ويب والواجهة الأمامية لـ Azure. يمكنك توسيع المفاهيم لدعم أنماط بنية تحتية أخرى. على سبيل المثال، إذا كان تطبيقك يتصل بقاعدة بيانات Azure أو حساب تخزين، راجع Active geo-replication for SQL databases و تخزين Azure التكرار. للحصول على بنية مرجعية لسيناريو أكثر تفصيلا، راجع نمط تطبيق الويب Reliable ل .NET.

في هذا البرنامج التعليمي، سوف تتعلّم:

• أنشئ تطبيقات خدمة تطبيقات متطابقة في مناطق منفصلة
• إنشاء الواجهة الأمامية لـ Azure مع قيود الوصول لمنع الوصول العام إلى خدمة التطبيقات

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

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

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

• استخدم بيئة باش في Azure Cloud Shell. لمزيد من المعلومات، راجع ابدأ مع Azure Cloud Shell.

  

• إذا كنت تفضل تشغيل أوامر مرجعية لواجهة الواجهة محليا، install Azure CLI. إذا كنت تعمل على Windows أو macOS، فكر في تشغيل Azure CLI في حاوية Docker. لمزيد من المعلومات، راجع كيفية تشغيل Azure CLI في حاوية Docker.

  • إذا كنت تستخدم تثبيتا محليا، سجل الدخول إلى Azure CLI باستخدام أمر az login. لإنهاء عملية المصادقة، اتبع الخطوات المعروضة في جهازك. لخيارات تسجيل الدخول الأخرى، راجع المصادقة إلى Azure باستخدام Azure CLI.

  • عندما يطلب منك ذلك، قم بتثبيت إضافة Azure CLI عند الاستخدام الأول. لمزيد من المعلومات حول الإضافات، راجع استخدم وإدارة الإضافات باستخدام Azure CLI.

  • يُرجى تشغيل إصدار az للوصول إلى الإصدار والمكتبات التابعة التي تم تثبيتها. للتحديث لآخر إصدار، يُرجى تشغيل تحديث az.

راجع بنية السيناريو

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

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

السيناريو في هذا الدرس يوفر السلوك التالي:

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

إنشاء مجموعة موارد

تحتاج إلى نسختين من تطبيق ويب يعمل في مناطق Azure مختلفة لهذا الدرس.

1. راجع أزواج المناطق المتاحة واختر منطقتين مرتبطتين لتطبيقات الويب الخاصة بك.

   في هذا الدرس، يشار إلى المنطقتين باسم <primary-region> (eastus) و <standby-region> (westus).

2. أنشئ مجموعة موارد لجميع الموارد التي تكوينها في هذا الدرس. هذا الدرس ينشئ مجموعة الموارد في <primary-region> الموقع.

   az group create --name <resource-group> --location <primary-region>
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --name	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --location	<primary-region>	موقع المنطقة لمجموعة الموارد. يستخدم هذا الدرس نفس موقع المنطقة لمجموعة الموارد وتطبيق الويب الرئيسي.	eastus

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

   لمزيد من المعلومات، راجع مرجع إنشاء أوامر من مجموعة az .

أنشئ خطتين لخدمة التطبيقات

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

لهذا الأمر، تستخدم زوج المنطقة الذي اخترته سابقا. استخدم المنطقة النشطة لتطبيق الويب الأساسي والمنطقة السلبية لتطبيق الويب الاحتياطي.

شغل الأمر التالي لإنشاء خطة خدمة التطبيقات لتطبيق الويب الرئيسي، ثم شغل الأمر مرة أخرى لإنشاء خطة التطبيق الاحتياطي.

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

المعلمة	قيمة	‏‏الوصف	مثال
--name	<app-service-plan>	اسم خطة خدمة التطبيق لتطبيق الويب. يجب أن يكون لكل نسخة خطة اسم فريد.	zava-primary-plan zava-standby-plan
--resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
--location	<region>	موقع المنطقة لتطبيق الويب.	- تطبيق ويب أساسي، المنطقة النشطة eastus - تطبيق ويب احتياطي، منطقة سلبية westus

لمزيد من المعلومات، راجع خطة إنشاء أوامر في az appservice .

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

أنشئ تطبيقين ويب لخدمة التطبيقات. ضع كل تطبيق في خطة خدمة التطبيقات وموقع المنطقة المناسبة.

1. حدد --runtime نسخة اللغة لتطبيقات الويب.

   يمكنك تشغيل الأمر التالي لقائمة أوقات التشغيل المتاحة:

   az webapp list-runtimes
   

   إذا كنت تخطط لاستخدام تطبيق Node.js النموذجي الموضح في هذا الشرح، قم بتعيين <language-version> القيمة على NODE:24-lts.

2. أنشئ تطبيقين على الويب. شغل الأمر التالي لإنشاء تطبيق الويب الأساسي، ثم شغل الأمر مرة أخرى لإنشاء التطبيق الاحتياطي.

   az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --name	<web-app-name>	اسم تطبيق الويب. يجب أن يكون لكل تطبيق اسم فريد عالميا. الأحرف الصالحة هي a-z، 0-9، و -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --name	<app-service-plan>	اسم خطة خدمة التطبيق لتطبيق الويب.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	نسخة لغة التشغيل لتطبيق الويب.	NODE:24-lts

   لمزيد من المعلومات، راجع مرجع إنشاء أوامر على الويب في az .

3. حدد defaultHostName قيمة كل تطبيق ويب. تنسيق اسم المضيف هو <web-app-name>.azurewebsites.net.

   قم بمسح إخراج الأوامر لكل تطبيق ويب وتحديد القيمة، أو شغل الأمر التالي لكل تطبيق ويب:

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

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --name	<web-app-name>	اسم تطبيق الويب.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group

   في بوابة Azure، يكون اسم المضيف لكل تطبيق مرئيا في صفحة تطبيق الويب نظرة عامة.

   سجل قيم أسماء المضيف لاحقا. تستخدم أسماء المضيفين لتعريف عناوين الخلفية لنشر الواجهة الأمامية لـ Azure.

4. تأكد من إمكانية الوصول إلى تطبيقات الويب الجديدة.

   1. في المتصفح، أدخل اسم المضيف لتطبيق الويب الرئيسي، مثل zava-primary-app.azurewebsites.net.

      عندما ينجح الاتصال، ترى الرسالة التالية:

      

   2. كرر الاختبار باستخدام اسم المضيف لتطبيق الويب الاحتياطي الخاص بك.

Configure الواجهة الأمامية لـ Azure

يمكن أن يستخدم النشر متعدد المناطق تكوين نشط-نشط أو نشط-سلبي . المنطقة الأساسية نشطة والمنطقة الاحتياطية سلبية.

• يقوم التكوين النشط-النشط بتوزيع الطلبات عبر مناطق نشطة متعددة.
• التكوين النشط-السلبي يستمر في تشغيل المثيلات في منطقة الاستعداد (السلبية)، لكنه لا يرسل حركة مرور هناك إلا إذا فشلت المنطقة الأساسية (النشطة).

الواجهة الأمامية لـ Azure يتيح لك تفعيل كلا التكوينين. لمزيد من المعلومات حول تصميم التطبيقات ذات توفر عالي وتحمل الأخطاء، راجع قائمة مراجعة التصميم للموثوقية.

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

أنشئ نسخة من الواجهة الأمامية لـ Azure Premium لتوجيه حركة المرور إلى تطبيقات الويب الخاصة بك.

1. راجع مقارنة المستويات الواجهة الأمامية لـ Azure< وc0> واختر المستوى المناسب لنشرك.

   يستخدم هذا الدرس الواجهة الأمامية لـ Azure Premium (Premium_AzureFrontDoor).

   إذا كنت تفضل نشر الواجهة الأمامية لـ Azure Standard، ضع في اعتبارك أن مستوى Standard لا يدعم نشر القواعد المدارة مع سياسة WAF.

2. شغل الأمر التالي لإنشاء الملف الشخصي:

   az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --profile-name	<front-door-profile>	اسم ملف تعريف الواجهة الأمامية لـ Azure. يجب أن يكون الاسم فريدا داخل مجموعة الموارد.	zava-profile
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --sku	<front-door-tier>	ال tier sku ل الواجهة الأمامية لـ Azure for the deployment.	Premium_AzureFrontDoor (موصى به) Standard_AzureFrontDoor

   لمزيد من المعلومات، راجع ملف تعريف az afd create command reference.

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

أنشئ نقطة نهاية في ملفك الشخصي. بعد إنشاء نقطة النهاية الأولى، يمكنك إنشاء عدة نقاط نهاية في ملفك الشخصي.

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

المعلمة	قيمة	‏‏الوصف	مثال
--resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
--endpoint-name	<front-door-endpoint>	اسم نقطة النهاية تحت ملف تعريف الواجهة الأمامية لـ Azure. يجب أن يكون الاسم فريدًا عالميًا.	zava-endpoint
--profile-name	<front-door-profile>	اسم ملفك الشخصي في الواجهة الأمامية لـ Azure.	zava-profile

لمزيد من المعلومات، راجع مرجع أوامر إنشاء az endpoint afd .

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

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

أنشئ مجموعة أصل في ملف الواجهة الأمامية لـ Azure الخاص بك لتحتوي على الأصول لتطبيقي الويب الاثنين لديك.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

المعلمة	قيمة	‏‏الوصف	مثال
--resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
--origin-group-name	<front-door-origin-group>	اسم مجموعة الأصل الواجهة الأمامية لـ Azure. يجب أن يكون الاسم فريدًا عالميًا.	zava-origin-group
--profile-name	<front-door-profile>	اسم ملفك الشخصي في الواجهة الأمامية لـ Azure.	zava-profile
--probe-request-type	<probe-request>	نوع طلب فحص صحي.	GET
--probe-protocol	<probe-protocol>	البروتوكول المستخدم في فحص الصحة.	Http
--probe-interval-in-seconds	<probe-interval>	عدد الثوان بين فحوصات السلامة.	60
--probe-path	<probe-path>	المسار المرتبط بالأصل، والذي يستخدم لتحديد صحة الأصل.	/ (ارتداد)
--sample-size	<sample-size>	عدد العينات التي يجب مراعاتها لاتخاذ قرارات موازنة التحميل.	4
--successful-samples-required	<required-samples>	عدد العينات خلال فترة العينة التي يجب أن تنجح.	3
--additional-latency-in-milliseconds	<extra-latency>	زمن الانتقال الإضافي بالمللي ثانية للفحوصات لتقع في مستودع زمن الانتقال الأدنى.	50

لمزيد من المعلومات، راجع az afd origin-group create command reference.

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

أضف أصلا لكل تطبيق ويب إلى مجموعة الواجهة الأمامية لـ Azure origin الخاصة بك.

1. أضف أصلا لتطبيق الويب الرئيسي . قم بتعيين معامل --priority إلى 1، مما يخبر الواجهة الأمامية لـ Azure أن هذا التطبيق هو المستقبل الأساسي لحركة المرور.

   az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
      --origin-group-name <front-door-origin-group> \
      --origin-name <web-app-origin-name> \
      --origin-host-header <web-app-name>.azurewebsites.net \
      --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
      --http-port <origin-port> --https-port <origin-secure-port>
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	اسم المضيف لتطبيقك الرئيسي على الويب. يجمع اسم المضيف بين اسم تطبيق الويب، مثل zava-primary-app مع معرف المضيف، azurewebsites.net.	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	اسم ملفك الشخصي في الواجهة الأمامية لـ Azure.	zava-profile
   --origin-group-name	<front-door-origin-group>	اسم مجموعة الأصل الواجهة الأمامية لـ Azure.	zava-origin-group
   --origin-name	<web-app-origin-name>	اسم أصل التطبيق الرئيسي على الويب. يجب أن يكون الاسم فريدا ضمن مجموعة الأصل.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	رأس المضيف لإرسال طلبات إلى الأصل الأساسي لتطبيق الويب. إذا لم تحدد قيمة، يحدد اسم المضيف الخاص بالطلب هذه القيمة. تتطلب أصول Azure CDN، مثل Web Apps ومخزن البيانات الثنائية الكبيرة وCloud Services، أن تتطابق قيمة رأس المضيف هذه مع اسم المضيف الأصلي بشكل افتراضي.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	الأولوية لهذا الأصل ضمن مجموعة الأصل. بالنسبة لتطبيق الويب الرئيسي ، اضبط الأولوية على 1. يستخدم الواجهة الأمامية لـ Azure قيم الأولوية لموازنة الأحمال عبر المناطق الأصلية والمناطق النشطة. يجب أن تكون القيمة بين 1 و5.	1
   --weight	<origin-weight>	وزن الأصل داخل مجموعة الأصل لتوازن الأحمال. يجب أن تكون القيمة بين 1 و1000.	1000
   --enabled-state	<origin-state>	حدد ما إذا كان يجب تمكين هذا المصدر لاستقبال حركة المرور.	Enabled
   --http-port	<origin-port>	المنفذ المستخدم لطلبات HTTP إلى الأصل.	80
   --https-port	<origin-secure-port>	المنفذ المستخدم لطلبات HTTPS الآمنة إلى المصدر.	443

   لمزيد من المعلومات، راجع مرجع إنشاء أوامر في أصول afd az.

2. شغل الأمر مرة أخرى وأضف أصلا لتطبيق الويب الاحتياطي . يستخدم الأمر نفس المعلمات، ولكن مع قيم المعلمات الفريدة التالية:

   المعلمة	قيمة	‏‏الوصف	مثال
   --host-name	<web-app-name>.azurewebsites.net	اسم المضيف لتطبيق الويب الاحتياطي الخاص بك.	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	اسم أصل تطبيق الويب الاحتياطي .	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	رأس المضيف لإرسال طلبات إلى أصل تطبيق الويب الاحتياطي .	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	الأولوية لهذا الأصل ضمن مجموعة الأصل. بالنسبة لتطبيق الويب الاحتياطي ، اضبط الأولوية إلى 2. يحاول الواجهة الأمامية لـ Azure توجيه جميع حركة المرور إلى الأصل الأساسي. عندما لا يكون الأصل الأساسي متاحا، تتوجه حركة المرور إلى نقطة البداية الاحتياطية.	2

إضافة قاعدة مسار

أضف قاعدة توجيه لتعيين نقطة نهاية الواجهة الأمامية لـ Azure إلى مجموعة الأصل. المسار يعيد توجيه الطلبات من نقطة النهاية إلى مجموعة الأصل الخاصة بك.

1. إنشاء قاعدة مسار لتعيين نقطة نهاية الواجهة الأمامية لـ Azure إلى مجموعة الأصل:

   az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
      --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
      --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link> 
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --profile-name	<front-door-profile>	اسم ملفك الشخصي في الواجهة الأمامية لـ Azure.	zava-profile
   --endpoint-name	<front-door-endpoint>	اسم نقطة النهاية تحت ملف الواجهة الأمامية لـ Azure الخاص بك.	zava-endpoint
   --forwarding-protocol	<protocol-type>	البروتوكول المستخدم في قاعدة المسار هذه عند إعادة توجيه حركة المرور إلى تطبيقات الخلفية.	MatchRequest
   --route-name	<route-rule-name>	اسم قاعدة المسار. يجب أن يكون فريدا ضمن ملف تعريف الواجهة الأمامية لـ Azure.	zava-route-rule
   --https-redirect	<secure-redirect>	يشير إلى ما إذا كان سيتم إعادة توجيه حركة HTTP تلقائيا إلى حركة HTTPS.	Enabled
   --origin-group-name	<front-door-origin-group>	اسم مجموعة الأصل الواجهة الأمامية لـ Azure.	zava-origin-group
   --supported-protocols	<protocol-list>	قائمة البروتوكولات المدعومة لهذه قاعدة الطريق. استخدم مساحة لفصل أنواع البروتوكولات.	Http Https
   --link-to-default-domain	<domain-link>	أشار إلى ما إذا كان هذا المسار مرتبطا بنطاق نقطة النهاية الافتراضي.	Enabled

   لمزيد من المعلومات، راجع az afd route create command reference.

2. اترك حوالي 15 دقيقة لإكمال النشر. قد يستغرق الأمر بعض الوقت حتى تنتشر التغييرات عالميا.

Relimit access through الواجهة الأمامية لـ Azure only

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

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

تأتي حركة المرور من الواجهة الأمامية لـ Azure إلى تطبيقاتك من مجموعة معروفة من نطاقات IP المحددة في وسم الخدمة AzureFrontDoor.Backend. باستخدام قاعدة تقييد علامات الخدمة، يمكنك تقييد حركة المرور لتكون فقط من الواجهة الأمامية لـ Azure.

1. احصل على معرف ملف تعريف الواجهة الأمامية لـ Azure الخاص بك.

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

   az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --profile-name	<front-door-profile>	اسم ملفك الشخصي في الواجهة الأمامية لـ Azure.	zava-profile

   يعرض مخرج الأمر معرف الملف الشخصي (قيمة أبجدية رقمية مكونة من 32 رقما):

   "0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"
   

   في الخطوة التالية، تستخدم معرف الملف الشخصي للقيمة <profile-identifier> .

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

   az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
      --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --name	<web-app-name>	اسم تطبيق الويب الذي تضع عليه قيود الوصول.	zava-primary-app zava-standby-app
   --priority	<access-priority>	حدد أولوية قاعدة تقييد الوصول عبر جميع القواعد المعرفة للملف الشخصي. القيمة الأقل تعني أولوية أعلى.	100
   --service-tag	<tag-name>	اسم وسم الخدمة المعترف به بواسطة الواجهة الأمامية لـ Azure. تنطبق قيود الوصول على نطاق IP المشار إليه بعلامة الخدمة.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	حدد رأس أو أكثر من عناوين HTTP الفريدة لمزيد من التصفية لحركة المرور الواردة. تقوم قيود الوصول بتصفية الطلبات الواردة بناء على رأس HTTP الفريد المرسل من ملف الواجهة الأمامية لـ Azure الخاص بك. يجمع الرأس بين بادئة الواجهة الأمامية لـ Azure ومعرف الملف الشخصي الخاص بمثيل الواجهة الأمامية لـ Azure الخاص بك.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   لمزيد من المعلومات، راجع مرجع أوامر إضافة إعدادات access-restriction في az webapp .

قيود الوصول إلى الاختبار

تأكد من أن قيود الوصول لديك تمنع الوصول المباشر إلى تطبيقاتك.

1. في المتصفح، أدخل اسم المضيف لتطبيق الويب الرئيسي، مثل zava-primary-app.azurewebsites.net.

   يجب أن يفشل الاتصال مع الرسالة التالية:

   

2. كرر الاختبار باستخدام اسم المضيف لتطبيق الويب الاحتياطي الخاص بك، مثل zava-standby-app.azurewebsites.net.

Test الواجهة الأمامية لـ Azure deployment

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

1. احصل على اسم المضيف لنقطة نهاية الواجهة الأمامية لـ Azure الخاصة بك:

   az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"
   

   استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

   المعلمة	قيمة	‏‏الوصف	مثال
   --resource-group	<resource-group>	مجموعة الموارد التي تحتوي على الموارد التي تم إنشاؤها في هذا الدرس.	zava-resource-group
   --profile-name	<front-door-profile>	اسم ملفك الشخصي في الواجهة الأمامية لـ Azure.	zava-profile
   --endpoint-name	<front-door-endpoint>	اسم نقطة النهاية تحت ملف الواجهة الأمامية لـ Azure الخاص بك.	zava-endpoint

   يعرض مخرج الأمر اسم المضيف في نقطة النهاية:

   "zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"
   

   يتكون اسم المضيف من اسم نقطة النهاية، وهاش أبجدي رقمي فريد، ومعرف، ولاحقة الواجهة الأمامية لـ Azure. في الخطوة التالية، تستخدم اسم مضيف نقطة النهاية.

   لمزيد من المعلومات، راجع مرجع أوامر az endpoint show .

2. في المتصفح، أدخل اسم المضيف لنقطة النهاية، مثل zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   يجب أن يتم توجيه طلبك تلقائيا إلى تطبيقك الأساسي في المنطقة النشطة.

   عندما ينجح الاتصال، ترى الرسالة التالية:

   

3. اختبر الفشل العالمي الفوري بين التطبيقات في المناطق المرتبطة.

   1. في المتصفح، أدخل اسم المضيف لنقطة النهاية، مثل zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net.

   2. أوقف التطبيق الأساسي عن طريق تشغيل أمر إيقاف تطبيق الويب الخاص بأزيد .

      استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

      az webapp stop --name <primary-web-app> --resource-group <resource-group>
      

   3. قم بتحديث المستعرض.

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

      تلميح

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

      يمكنك التأكد من أن الواجهة الأمامية لـ Azure يعيد توجيهه إلى تطبيق الاستعداد من خلال التحقق من حالة تطبيقات الويب في بوابة Azure. في صفحة النظرة العامة لتطبيق الويب الرئيسي، يجب أن يكون خيار Start متاحا (وليس رمادي). في صفحة النظرة العامة لتطبيق الويب الاحتياطي، لا ينبغي أن يكون خيار Start متاحا (مغطى بالرمادي).

   4. شغل az webapp stop الأمر مرة أخرى وأوقف تطبيق الاستعداد .

      استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

      az webapp stop --name <standby-web-app> --resource-group <resource-group>
      

   5. قم بتحديث متصفحك مرة أخرى.

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

      

   6. شغل az webapp start الأمر وأعد تشغيل تطبيق الاستعداد .

      استبدل قيم المعلمات التالية <placeholder> بمعلومات مواردك الخاصة:

      az webapp start --name <standby-web-app> --resource-group <resource-group>
      

   7. قم بتحديث متصفحك وسترى اتصالا ناجحا للتطبيق.

التحقق من الصحة يؤكد أنه يمكنك الآن الوصول إلى تطبيقاتك من خلال وظائف الواجهة الأمامية لـ Azure وFailover كما هو مقصود.

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

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

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

استبدل قيمة المعلمة <placeholder> بمعلومات مصدرك الخاص:

az group delete --name <resource-group>

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

الانتشار من ARM أو Bicep

يمكن نشر الموارد التي أنشأتها في هذا الدرس باستخدام قالب Azure Resource Manager (قالب ARM) أو قالب Bicep. يمكنك البدء بتطبيق الويب متعدد المناطق المتوفر بجودة عالية Bicep ملف على GitHub. يساعدك هذا القالب على إنشاء حل آمن وعالي التوفر ومتعدد المناطق من الطرف إلى الطرف مع تطبيقين ويب في مناطق مختلفة خلف الواجهة الأمامية لـ Azure.

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

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

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

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

إدارة ونشر البنية التحتية وموارد Azure

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

استخدم فتحات التجهيز للنشر الآمن في الإنتاج

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

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

لاستخدام فتحات التجهيز، اتبع هذا الإجراء:

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

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

   إذا لم يكن لديك تطبيق، يمكنك البدء بنموذج تطبيق Node.js مرحبًا بالعالم . قم بتقسيم مستودع GitHub حتى يكون لديك نسختك الخاصة لإجراء التعديلات.

2. قم بتكوين إعدادات مكدس خدمة التطبيقات لتطبيقات الويب الخاصة بك.

   إعدادات المكدس تشير إلى نسخة اللغة أو وقت التشغيل المستخدم لتطبيقك.

   يمكنك ضبط الإعدادات في بوابة Azure أو استخدام أمر az webapp config set. إذا استخدمت عينة Node.js، اضبط إعدادات المكدس على Node 24 LTS.

   1. في بوابة Azure، اذهب إلى تطبيق الويب الخاص بك primary الخاص بك.

   2. في القائمة اليسرى، حدد Settings>Configuration.

   3. في تبويب إعدادات المكدس ، قم بتكوين الإعدادات التالية:

      1. اختر قيمة المكدس ، مثل Node.

      2. اختر قيمة الإصدار ، مثل Node 24 LTS.

      3. حدد تطبيق.

   4. كرر العملية لتكوين إعدادات مكدس خدمة التطبيقات لتطبيق الويب الاحتياطي .

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

4. شغل الأمر التالي لإنشاء فتحة تجهيز مسماة stage لتطبيقك الرئيسي على الويب.

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

5. شغل az webapp deployment slot create الأمر مرة أخرى وأنشئ خانة تجريبية باسم stage تطبيق الويب الاحتياطي .

6. تكوين النشر المستمر باستخدام GitHub Actions لكل فتحة مرحلة:

   1. في بوابة Azure، اذهب إلى تطبيق الويب الخاص بك primary الخاص بك.

   2. في القائمة اليسرى، حدد Deployment>Deployment slots.

   3. ابحث عن فتحة المسرح في القائمة، واختر الفتحة لفتح لوحة التفاصيل.

   4. في القائمة اليسرى، اختر مركز نشر النشر>.

   5. في تبويب Settings، قم بتعيين خيار Source على GitHub:

      

   6. إذا كنت تنشر من GitHub لأول مرة، اختر Authorize واتبع تعليمات التفويض. إذا كنت تريد التوزيع من مستودع مستخدم مختلف، فحدد تغيير الحساب.

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

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

      الإعداد	قيمة
      منظمة	<your-GitHub-organization>
      Repository	nodejs-docs-hello-world
      الفرع	أساسي

   8. حدد حفظ.

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

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

تعطيل المصادقة الأساسية في خدمة التطبيقات

يمكنك تقييد الوصول إلى نقاط نهاية FTP وSCM للمستخدمين المدعومين ب Microsoft Entra ID عبر تعطيل المصادقة الأساسية.

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

الأوامر التالية تعطل المصادقة الأساسية لتطبيق الويب الرئيسي وفتحة المرحلة، وكذلك لتطبيق الويب الاحتياطي وفتحة المرحلة. استبدل قيم المعلمات التالية <placeholder> بالمعلومات الخاصة بمواردك الخاصة.

1. تعطيل الوصول إلى FTP لمواقع الإنتاج وفتحات التجهيز لتطبيقك الرئيسي على الويب:

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

2. شغل الأوامر مرة أخرى لتطبيق الويب الاحتياطي .

3. تعطيل الوصول الأساسي للمصادقة إلى منفذ WebDeploy وموقع SCM لمواقع الإنتاج وفتحات المراحل لتطبيق الويب الأساسي الخاص بك:

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

4. شغل الأوامر مرة أخرى لتطبيق الويب الاحتياطي .

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

استخدم النشر المستمر عند تعطيل المصادقة الأساسية

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

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

إنشاء مبدأ الخدمة وبيانات اعتماده باستخدام GitHub Actions

تكوين النشر المستمر باستخدام GitHub Actions وخدمة رئيسية:

1. أنشئ المبدأ الأساسي لتطبيق الويب الأساسي وتطبيق الويب الاحتياطي:

   استبدل قيم المعلمات التالية <placeholder> بالمعلومات الخاصة بمواردك الخاصة.

   az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>
   

   الإخراج هو كائن JSON مع بيانات اعتماد تعيين الدور التي توفر الوصول إلى تطبيقات App Service.

   {
     "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
     "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
     "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
     "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
     "resourceManagerEndpointUrl": "https://management.azure.com/",
     "activeDirectoryGraphResourceId": "https://graph.windows.net/",
     "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
     "galleryEndpointUrl": "https://gallery.azure.com/",
     "managementEndpointUrl": "https://management.core.windows.net/"
   }
   

   يتضمن JSON سر عميلك، والذي يظهر فقط في الوقت الحالي.

   تلميح

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

2. انسخ كائن JSON حتى يكون لديك سجل لسر عميلك.

3. قدم بيانات اعتماد المديرين لخدمتك لعملية تسجيل الدخول Azure كجزء من سير عمل GitHub Action الخاص بك.

   يمكنك توفير القيم مباشرة في سير العمل أو تخزينها كأسرار في GitHub يتم الإشارة إليها في سير عملك. حفظ القيم كأسرار في GitHub هو الخيار الأكثر أمانا.

   1. افتح مستودع GitHub الخاص بتطبيقك.

   2. اذهب إلى الإعدادات>: أسرار الأمان> والمتغيرات >والإجراءات اللازمة.

   3. اختر سر مستودع جديد وأنشئ سريا لكل من الإعدادات التالية. استخدم القيم من مخرجات JSON الخاصة بك.

      الإعداد	قيمة	مثال
      AZURE_APP_ID	<application/client-id>	00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_PASSWORD	<client-secret>	ffffffff-5a5a-6b6b-7c7c-888888888888
      AZURE_TENANT_ID	<tenant-id>	aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID	<subscription-id>	cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

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

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

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

1. افتح مستودع GitHub الخاص بتطبيقك.

2. انتقل إلى <repo-name>/.github/workflows/ الدليل. يجب أن تشاهد مهام سير العمل التي تم إنشاؤها تلقائيا.

3. لكل ملف سير عمل، اختر التحرير (قلم رصاص).

4. استبدل محتويات ملف سير العمل بالمحتوى التالي. الكود يفترض أنك قد أنشأت أسرار GitHub الخاصة بك.

   في env القسم، قم بضبط الإعدادات التالية:

   • AZURE_WEBAPP_NAME: استبدل الاسم <web-app-name> المؤقت باسم تطبيق الويب الخاص بك.
   • NODE_VERSIONحدد نسخة العقدة التي ستستخدمها. : بالنسبة للعينة Node.js، القيمة هي '24.x'.
   • AZURE_WEBAPP_PACKAGE_PATHحدد المسار إلى مشروع تطبيق الويب الخاص بك. الافتراضي هو جذر المستودع، '.'.
   • AZURE_WEBAPP_SLOT_NAMEحدد اسم خانة التطبيق الخاصة بك. الاسم الشائع هو stage.

   
    name: Build and deploy Node.js app to Azure Web App
   
    on:
      push:
        branches:
          - main
      workflow_dispatch:
   
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
      NODE_VERSION: '24.x'                # Node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
      AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name
   
    jobs:
      build:
        runs-on: ubuntu-latest
   
        steps:
          - uses: actions/checkout@v4
   
          - name: Set up Node.js version
            uses: actions/setup-node@v4
            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@v4
            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@v4
            with:
              name: node-app
   
          - uses: azure/login@v2
            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@v3
            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
   

5. احفظ وقم بالتزام تغييرات ملف سير العمل مباشرة إلى الفرع الرئيسي من مستودعك.

   يقوم الالتزام بتشغيل إجراء GitHub لإعادة التشغيل ونشر الكود الخاص بك. هذه المرة، يستخدم المدعي الرئيسي للمصادقة.

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

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

نقل الكود من فتحة التجهيز إلى المحطة الإنتاجية

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

1. قم بتبديل التطبيق الرئيسي على الويب الخاص بك:

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

2. قم بتبديل تطبيق الويب الافتراضي الخاص بك:

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

3. بعد بضع دقائق، اذهب إلى نقطة نهاية الواجهة الأمامية لـ Azure في بوابة Azure، وتحقق من نجاح تبديل الفتحات.

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

تجنب الانقطاعات ومشاكل الاستمرارية باستخدام عمليات نشر متعددة المناطق

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

1. في بوابة Azure، اذهب إلى نسخة الواجهة الأمامية لـ Azure الخاصة بك.

2. في القائمة اليسرى، اختر مجموعات الإعدادات>الأصلية.

3. في قائمة مجموعات الأصل، اختر مجموعة الأصل التي تحتوي على الخانة التي تريد إزالتها مؤقتا.

4. في صفحة تحديث مجموعة الأصل ، حدد الخانة التي يجب إزالتها في قائمة أسماء المضيف الأصلية .

5. اختر المزيد من الإجراءات (...) >حذف، ثم اختر التحديث.

   

   قد يستغرق تطبيق التغيير عدة دقائق.

6. عندما تكون مستعدا للسماح بحركة المرور إلى الفتحة المحاللة، عد إلى لوحة مجموعة الأصل الخاصة بالتحديث .

7. في الأعلى، اختر + أضف نقطة أصل لإعادة إضافة خانة الأصل إلى مجموعة الأصل.

   

أنشئ مجموعات أصل إضافية وغير ارتباطات المسارات

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

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

لنأخذ في الاعتبار تكوينا له ثلاث مجموعات أصلية:

• تحتوي المجموعة Main-Origin على كل من التطبيقات الرئيسية والتطبيقات الاحتياطية، كل منهما في منطقته الخاصة.
• تحتوي المجموعة Primary-Origin فقط على تطبيق الويب الأساسي في المنطقة النشطة.
• تحتوي المجموعة Standby-Origin فقط على تطبيق الويب الاحتياطي في المنطقة السلبية.

افترض أن تطبيق الويب الأساسي يمر بتغيير. قبل بدء التغييرات، يتم تغيير ربط Main-Origin مسار المجموعة إلى المجموعة Secondary-Origin . يضمن هذا الإجراء أن جميع طرق المرور إلى تطبيق الويب الاحتياطي في منطقته المعنية بينما يمر التطبيق الرئيسي في منطقته بتغيير.

اتبع هذه الخطوات لتغيير ارتباط المسار لمجموعة الأصل:

1. في بوابة Azure، اذهب إلى نسخة الواجهة الأمامية لـ Azure الخاصة بك.

2. في القائمة اليسرى، اختر مجموعات الإعدادات>الأصلية.

3. في قائمة مجموعات المنشأ، حدد مجموعة أصل تعرض مؤشر غير مرتبط في عمود المسارات .

4. اختر المزيد من الإجراءات (...) >ربط نقطة النهاية والمسار.

   

5. في صفحة مسارات الشريك ، اختر مسارا أو أكثر للارتباط بمجموعة الأصل، ثم اختر المرتبط.

   

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

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

المحتوى ذو الصلة

• نشر تطبيق ويب متعدد المناطق عالي التوفر
• راجع بنية الأساس لتطبيق ويب عالي التوفر مع تكرار مناطق