البرنامج التعليمي: إنشاء تطبيق n-tier آمن في Azure App Service

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

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

• تطبيق متعدد المناطق من الطبقة N
• تخطيط نمط تطبيق الويب الموثوق به (.NET) .

تصميم السيناريو

يوضح الرسم التخطيطي التالي البنية التي ستقوم بإنشائها أثناء هذا البرنامج التعليمي.

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

إشعار

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

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

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

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

• إنشاء شبكة ظاهرية وشبكات فرعية لتكامل الشبكة الظاهرية لخدمة التطبيقات.
• إنشاء مناطق DNS خاصة.
• إنشاء نقاط نهاية خاصة.
• تكوين تكامل الشبكة الظاهرية في App Service.
• تعطيل المصادقة الأساسية في خدمة التطبيق.
• النشر باستمرار إلى تطبيق ويب خلفي مؤمن.

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

يستخدم البرنامج التعليمي نموذجين Node.js التطبيقات التي تتم استضافتها على GitHub. إذا لم يكن لديك حساب GitHub بالفعل، فبادر بإنشاء حساب مجانا.

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

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

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

  

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

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

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

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

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

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

1. أنشئ مجموعة موارد لإدارة جميع الموارد التي تقوم بإنشائها في هذا البرنامج التعليمي.

   # Save resource group name and region as variables for convenience
   groupName=myresourcegroup
   region=eastus
   az group create --name $groupName --location $region
   

2. قم بإنشاء خطة خدمة التطبيق. استبدل <app-service-plan-name> باسم فريد. تعديل المعلمة --sku إذا كنت بحاجة إلى استخدام SKU مختلف. تأكد من أنك لا تستخدم المستوى المجاني لأن SKU لا يدعم ميزات الشبكات المطلوبة.

   # Save App Service plan name as a variable for convenience
   aspName=<app-service-plan-name>
   az appservice plan create --name $aspName --resource-group $groupName --is-linux --location $region --sku P1V3
   

3. إنشاء تطبيقات الويب. استبدل <frontend-app-name> و <backend-app-name> باسمين فريدين عموميين (الأحرف الصالحة هي a-zو 0-9و -). لهذا البرنامج التعليمي، يتم تزويدك بعينة من تطبيقات Node.js. إذا كنت ترغب في استخدام تطبيقاتك الخاصة، فقم بتغيير المعلمة --runtime وفقا لذلك. قم بتشغيل az webapp list-runtimes لقائمة أوقات التشغيل المتوفرة.

   az webapp create --name <frontend-app-name> --resource-group $groupName --plan $aspName --runtime "NODE:18-lts"
   az webapp create --name <backend-app-name> --resource-group $groupName --plan $aspName --runtime "NODE:18-lts"
   

2. إنشاء البنية الأساسية للشبكة

ستقوم بإنشاء موارد الشبكة التالية:

• شبكة ظاهرية.
• شبكة فرعية لتكامل الشبكة الظاهرية لخدمة التطبيقات.
• شبكة فرعية لنقطة النهاية الخاصة.
• منطقة DNS خاصة.
• نقطة نهاية خاصة.

1. أنشئ شبكة ظاهرية. استبدل <virtual-network-name> باسم فريد.

   # Save vnet name as variable for convenience
   vnetName=<virtual-network-name>
   az network vnet create --resource-group $groupName --location $region --name $vnetName --address-prefixes 10.0.0.0/16
   

2. إنشاء شبكة فرعية لتكامل الشبكة الظاهرية لخدمة التطبيقات.

   az network vnet subnet create --resource-group $groupName --vnet-name $vnetName --name vnet-integration-subnet --address-prefixes 10.0.0.0/24 --delegations Microsoft.Web/serverfarms --disable-private-endpoint-network-policies false
   

   بالنسبة ل App Service، يوصى بأن يكون للشبكة الفرعية لتكامل الشبكة الظاهرية كتلة /26 CIDR كحد أدنى. /24أكثر من كافي. يحدد --delegations Microsoft.Web/serverfarms أنه تم تفويض الشبكة الفرعية لتكامل الشبكة الظاهرية لخدمة التطبيقات.

3. إنشاء شبكة فرعية أخرى لنقاط النهاية الخاصة.

   az network vnet subnet create --resource-group $groupName --vnet-name $vnetName --name private-endpoint-subnet --address-prefixes 10.0.1.0/24 --disable-private-endpoint-network-policies true
   

   بالنسبة للشبكات الفرعية الخاصة بنقطة النهاية، يجب تعطيل نهج شبكة نقطة النهاية الخاصة عن طريق تعيين --disable-private-endpoint-network-policies إلى true.

4. إنشاء منطقة DNS الخاصة.

   az network private-dns zone create --resource-group $groupName --name privatelink.azurewebsites.net
   

   لمزيد من المعلومات حول هذه الإعدادات، راجع تكوين Azure Private Endpoint DNS.

   إشعار

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

5. ربط منطقة DNS الخاصة بالشبكة الظاهرية.

   az network private-dns link vnet create --resource-group $groupName --name myDnsLink --zone-name privatelink.azurewebsites.net --virtual-network $vnetName --registration-enabled False
   

6. في الشبكة الفرعية لنقطة النهاية الخاصة بالشبكة الظاهرية ، قم بإنشاء نقطة نهاية خاصة لتطبيق الويب الخلفي. استبدل <backend-app-name> باسم تطبيق الويب الخلفي.

   # Get backend web app resource ID
   resourceId=$(az webapp show --resource-group $groupName --name <backend-app-name> --query id --output tsv)
   az network private-endpoint create --resource-group $groupName --name myPrivateEndpoint --location $region --connection-name myConnection --private-connection-resource-id $resourceId --group-id sites --vnet-name $vnetName --subnet private-endpoint-subnet
   

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

   az network private-endpoint dns-zone-group create --resource-group $groupName --endpoint-name myPrivateEndpoint --name myZoneGroup --private-dns-zone privatelink.azurewebsites.net --zone-name privatelink.azurewebsites.net
   

8. عند إنشاء نقطة نهاية خاصة لخدمة التطبيقات، يتم تعطيل الوصول العام ضمنيا. إذا حاولت الوصول إلى تطبيق الويب الخلفي باستخدام عنوان URL الافتراضي الخاص به، فسيتم رفض وصولك. من مستعرض، انتقل إلى <backend-app-name>.azurewebsites.net لتأكيد هذا السلوك.

   

   لمزيد من المعلومات حول قيود الوصول إلى App Service مع نقاط النهاية الخاصة، راجع قيود الوصول إلى Azure App Service.

3. تكوين تكامل الشبكة الظاهرية في تطبيق الويب الأمامي

قم بتمكين تكامل الشبكة الظاهرية على تطبيقك. استبدل <frontend-app-name> باسم تطبيق الويب الأمامي.

az webapp vnet-integration add --resource-group $groupName --name <frontend-app-name> --vnet $vnetName --subnet vnet-integration-subnet

يسمح تكامل الشبكة الظاهرية لنسبة استخدام الشبكة الصادرة بالتدفق مباشرة إلى الشبكة الظاهرية. بشكل ظاهري، يتم توجيه حركة مرور IP المحلية المحددة في RFC-1918 فقط إلى الشبكة الظاهرية، وهو ما تحتاجه لنقاط النهاية الخاصة. لتوجيه نسبة استخدام الشبكة بالكامل إلى الشبكة الظاهرية، راجع إدارة توجيه تكامل الشبكة الظاهرية. يمكن أيضاً استخدام توجيه جميع حركات المرور إذا كنت تريد توجيه نسبة استخدام الشبكة على الإنترنت عبر شبكتك الظاهرية، على سبيل المثال من خلال Azure Virtual Network NAT أو Azure Firewall.

4. تمكين النشر إلى تطبيق الويب الخلفي من الإنترنت

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

1. تمكين الوصول العام لتطبيق الويب الخلفي.

   az webapp update --resource-group $groupName --name <backend-app-name> --set publicNetworkAccess=Enabled
   

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

   az resource update --resource-group $groupName --name <backend-app-name> --namespace Microsoft.Web --resource-type sites --set properties.siteConfig.ipSecurityRestrictionsDefaultAction=Deny
   

3. تعيين إجراء القاعدة غير المتطابقة لموقع SCM للسماح بكافة نسبة استخدام الشبكة.

   az resource update --resource-group $groupName --name <backend-app-name> --namespace Microsoft.Web --resource-type sites --set properties.siteConfig.scmIpSecurityRestrictionsDefaultAction=Allow
   

5. تأمين وصول FTP وSCM

الآن بعد أن أصبح موقع SCM الخلفي متاحا للجمهور، تحتاج إلى تأمينه بأمان أفضل.

1. تعطيل وصول FTP لكل من تطبيقات الويب الأمامية والخلفية. استبدل <frontend-app-name> و <backend-app-name> بأسماء التطبيقات الخاصة بك.

   az resource update --resource-group $groupName --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<frontend-app-name> --set properties.allow=false
   az resource update --resource-group $groupName --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<backend-app-name> --set properties.allow=false
   

2. تعطيل الوصول الأساسي للمصادقة إلى منافذ WebDeploy ومواقع أدوات SCM/المتقدمة لكلا تطبيقي الويب. استبدل <frontend-app-name> و <backend-app-name> بأسماء التطبيقات الخاصة بك.

   az resource update --resource-group $groupName --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<frontend-app-name> --set properties.allow=false
   az resource update --resource-group $groupName --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<backend-app-name> --set properties.allow=false
   

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

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

1. انتقل إلى تطبيق نموذج الواجهة الخلفية Node.js. هذا التطبيق هو تطبيق مرحبًا بالعالم بسيط.

2. حدد الزر Fork في أعلى اليمين في صفحة GitHub.

3. حدد المالك واترك اسم المستودع الافتراضي.

4. حدد Create fork.

5. كرر نفس العملية لتطبيق نموذج الواجهة الأمامية Node.js. هذا التطبيق هو تطبيق ويب أساسي يصل إلى عنوان URL بعيد.

6. إنشاء كيان خدمة. استبدل <subscription-id>و <frontend-app-name>و <backend-app-name> بقيمك.

   az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/$groupName/providers/Microsoft.Web/sites/<frontend-app-name> /subscriptions/<subscription-id>/resourceGroups/$groupName/providers/Microsoft.Web/sites/<backend-app-name> --sdk-auth
   

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

7. لتخزين بيانات اعتماد كيان الخدمة كأسرار GitHub، انتقل إلى أحد مستودعات العينات المتشعبة في GitHub وانتقل إلى الإعدادات> البيانات>السرية والمتغيراتالإجراءات.>

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

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

9. كرر هذه العملية لمستودع العينة المتشعب الآخر.

10. لإعداد النشر المستمر باستخدام GitHub Actions، سجل الدخول إلى مدخل Microsoft Azure.

11. انتقل إلى صفحة نظرة عامة لتطبيق الويب الأمامي.

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

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

    

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

15. إذا كنت تستخدم نموذج التطبيق Node.js الذي تم نسخه كجزء من المتطلبات الأساسية، فاستخدم الإعدادات التالية للمؤسسة والمستودع والفرع.

    الإعداد	القيمة‬
    المنظمة	<your-GitHub-organization>
    المستودع	nodejs-frontend
    فرع	أساسي

16. حدد حفظ.

17. كرر نفس الخطوات لتطبيق الويب الخلفي. يتم إعطاء إعدادات مركز النشر في الجدول التالي.

    الإعداد	القيمة‬
    المنظمة	<your-GitHub-organization>
    المستودع	nodejs-backend
    فرع	أساسي

7. استخدام كيان خدمة لنشر إجراءات GitHub

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

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
   
   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:
         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 }}
             package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
   
         - name: logout
           run: |
             az logout
   

3. كرر هذه العملية لملف سير العمل في مستودع GitHub المتشعب الآخر.

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

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

8. التحقق من صحة الاتصالات والوصول إلى التطبيق

1. استعرض للوصول إلى تطبيق الويب الأمامي باستخدام عنوان URL الخاص به: https://<frontend-app-name>.azurewebsites.net.

2. في مربع النص، أدخل عنوان URL لتطبيق الويب الخلفي: https://<backend-app-name>.azurewebsites.net. إذا قمت بإعداد الاتصالات بشكل صحيح، يجب أن تحصل على الرسالة "مرحبا من تطبيق الويب الخلفي!"، وهو المحتوى الكامل لتطبيق الويب الخلفي. يتم توجيه جميع نسبة استخدام الشبكة الصادرة من تطبيق الويب الأمامي من خلال الشبكة الظاهرية. يتصل تطبيق الويب الأمامي بشكل آمن بتطبيق الويب الخلفي من خلال نقطة النهاية الخاصة. إذا حدث خطأ ما في اتصالاتك، يتعطل تطبيق الويب الأمامي.

3. حاول التنقل مباشرة إلى تطبيق الويب الخلفي باستخدام عنوان URL الخاص به: https://<backend-app-name>.azurewebsites.net. يجب أن ترى الرسالة Web App - Unavailable. إذا كان بإمكانك الوصول إلى التطبيق، فتأكد من تكوين نقطة النهاية الخاصة ومن تعيين قيود الوصول لتطبيقك لرفض كل حركة المرور لتطبيق الويب الرئيسي.

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

   az webapp ssh --resource-group $groupName --name <frontend-app-name>
   

5. عند فتح shell في المتصفح الخاص بك، قم بتشغيل nslookup لتأكيد الوصول إلى تطبيق الويب الخلفي باستخدام IP الخاص لتطبيق الويب الخلفي. يمكنك أيضا تشغيل curl للتحقق من صحة محتوى الموقع مرة أخرى. استبدل <backend-app-name> باسم تطبيق الويب الخلفي.

   nslookup <backend-app-name>.azurewebsites.net
   curl https://<backend-app-name>.azurewebsites.net
   

   

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

   

6. كرر نفس الشيء nslookup والأوامر curl من محطة طرفية أخرى (واحدة ليست جلسة SSH على مثيلات الواجهة الأمامية).

   

   إرجاع nslookup IP العام لتطبيق الويب الخلفي. نظرا إلى تعطيل الوصول العام إلى تطبيق الويب الخلفي، إذا حاولت الوصول إلى عنوان IP العام، فستحصل على خطأ رفض الوصول. يعني هذا الخطأ أنه لا يمكن الوصول إلى هذا الموقع من الإنترنت العام، وهو السلوك المقصود. nslookup لا يتم حل إلى IP الخاص لأنه لا يمكن حل ذلك إلا من داخل الشبكة الظاهرية من خلال منطقة DNS الخاصة. يوجد تطبيق الويب الأمامي فقط داخل الشبكة الظاهرية. إذا حاولت التشغيل curl على تطبيق الويب الخلفي من المحطة الطرفية الخارجية، فإن HTML الذي يتم إرجاعه يحتوي على Web App - Unavailable. يعرض هذا الخطأ HTML لصفحة الخطأ التي رأيتها سابقا عندما حاولت الانتقال إلى تطبيق الويب الخلفي في المستعرض.

9. حذف الموارد

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

az group delete --name myresourcegroup

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

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

• هل هناك بديل للتوزيع باستخدام كيان الخدمة؟
• ماذا يحدث عند تكوين نشر GitHub Actions في App Service؟
• هل من الآمن ترك SCM الخلفي متاحا للجمهور؟
• هل هناك طريقة للنشر دون فتح موقع SCM الخلفي على الإطلاق؟
• كيف يمكنني نشر هذه البنية مع ARM/Bicep؟

هل هناك بديل للتوزيع باستخدام كيان الخدمة؟

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

ماذا يحدث عند تكوين نشر GitHub Actions في App Service؟

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

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

هل من الآمن ترك SCM الخلفي متاحا للجمهور؟

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

هل هناك طريقة للنشر دون فتح موقع SCM الخلفي على الإطلاق؟

إذا كنت قلقا بشأن تمكين الوصول العام إلى موقع SCM، أو إذا كنت مقيدا بالنهج، ففكر في خيارات نشر App Service الأخرى مثل التشغيل من حزمة ZIP.

كيف يمكنني نشر هذه البنية مع ARM/Bicep؟

يمكن نشر الموارد التي أنشأتها في هذا البرنامج التعليمي باستخدام قالب ARM/Bicep. يسمح لك التطبيق المتصل بقالب Bicep لتطبيق الويب الخلفي بإنشاء حل تطبيق N-tier آمن.

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

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

دمج تطبيقك مع شبكة Azure الافتراضية

ميزات شبكة خدمة التطبيقات

تخطيط نمط تطبيق الويب الموثوق به (.NET)