التوزيع إلى App Service باستخدام مسارات Azure

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019

استخدم Azure Pipelines لتوزيع تطبيق الويب الخاص بك تلقائيًا إلى Azure App Service على كل بنية ناجحة. يتيح لك Azure Pipelines الإنشاء والاختبار والنشر باستخدام التكامل المستمر (CI) والتسليم المستمر (CD) باستخدام Azure DevOps.

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

ستستخدم مهمة Azure Web App (AzureWebApp) للنشر إلى Azure App Service في البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك. بالنسبة للسيناريوهات الأكثر تعقيدا مثل الحاجة إلى استخدام معلمات XML في التوزيع الخاص بك، يمكنك استخدام مهمة توزيع Azure App Service (AzureRmWebAppDeployment).

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

• حساب Azure مع اشتراك نشط. أنشئ حساباً مجاناً.
• مؤسسة Azure DevOps أنشئ حسابًا مجانًا.
• القدرة على تشغيل البنية الأساسية لبرنامج ربط العمليات التجارية على العوامل المستضافة من Microsoft. يمكنك إما شراء وظيفة موازية أو يمكنك طلب مستوى مجاني.
• تطبيق Azure App Service يعمل مع تعليمات برمجية مستضافة على GitHub أو Azure Repos.
  • .NET: إنشاء تطبيق ويب ASP.NET Core في Azure
  • ASP.NET: إنشاء تطبيق ويب ASP.NET Framework في Azure
  • JavaScript: إنشاء عقدة Node.js في Azure App Service
  • Java: إنشاء تطبيق Java على خدمة تطبيق Azure
  • Python: إنشاء تطبيق Python في Azure App Service

1. إنشاء مسار لمكدس الذاكرة المؤقتة

تفترض أمثلة التعليمات البرمجية في هذا القسم أنك تنشر تطبيق ويب ASP.NET. يمكنك تكييف التعليمات لأطر أخرى.

تعرف على المزيد حول دعم النظام البنائي لـ Azure Pipelines.

YAML

1. سجل الدخول إلى مؤسسة Azure DevOps، وانتقل إلى مشروعك.

2. انتقل إلى Pipelines، ثم حدد New pipeline.

3. عند المطالبة، حدد موقع التعليمات البرمجية المصدر: إما Azure Repos Git أو GitHub.

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

4. عند ظهور قائمة المستودعات، حدد المستودع.

5. قد تتم إعادة توجيهك إلى GitHub لتثبيت تطبيق Azure Pipelines. إذا كان الأمر كذلك، فحدد Approve & install.

6. في علامة التبويب تكوين، حدد ASP.NET Core.

7. عند ظهور المسار الجديد، ألق نظرة على YAML لمعرفة ما يفعله. عندما تكون جاهزًا، حدد حفظ وتشغيل.

كلاسيكي

الشروع في العمل:

1. أنشئ مسارًا وحدد قالب ASP.NET Core. يضيف هذا التحديد تلقائيًا المهام المطلوبة لإنشاء التعليمات البرمجية في مستودع العينة.

2. احفظ المسار وضع البنية في قائمة الانتظار لرؤيتها قيد التنفيذ.

   ينشر قالب ASP.NET Core pipeline ملف ZIP للتوزيع كأداة Azure لمهمة النشر لاحقا.

2. إضافة مهمة التوزيع

YAML

1. انقر فوق نهاية ملف YAML، ثم حدد إظهار المساعد.'

2. استخدم مساعد المهام لإضافة مهمة Azure Web App.

   

   بدلا من ذلك، يمكنك إضافة مهمة توزيع Azure App Service (AzureRmWebAppDeployment).

3. اختر اشتراك Azure الخاص بك. تأكد من تخويل اتصالك. ينشئ التخويل اتصال الخدمة المطلوب.

4. حدد نوع التطبيق واسم التطبيق ومكدس وقت التشغيل استنادا إلى تطبيق App Service. يجب أن يبدو YAML الكامل مشابها للتعليمات البرمجية التالية.

   variables:
     buildConfiguration: 'Release'
   
   steps:
   - script: dotnet build --configuration $(buildConfiguration)
     displayName: 'dotnet build $(buildConfiguration)'
   - task: DotNetCoreCLI@2
     inputs:
       command: 'publish'
       publishWebProjects: true
   - task: AzureWebApp@1
     inputs:
       azureSubscription: '<service-connection-name>'
       appType: 'webAppLinux'
       appName: '<app-name>'
       package: '$(System.DefaultWorkingDirectory)/**/*.zip'
   

   • azureSubscription: اسم اتصال الخدمة المعتمد باشتراك Azure الخاص بك.
   • appName: اسم تطبيقك الحالي.
   • package: مسار الملف إلى الحزمة أو مجلد يحتوي على محتويات خدمة التطبيق. يتم دعم أحرف البدل.

كلاسيكي

الشروع في العمل:

1. أنشئ مسار إصدار عن طريق تحديد Releases من القائمة اليسرى وحدد New pipeline.

2. حدد قالب توزيع Azure App Service لمرحلتك. يضيف هذا تلقائيًا المهام الضرورية.

   إشعار

   إذا كنت تقوم بنشر تطبيق Node.js إلى App Service على Windows، فحدد قالب Deploy Node.js App to Azure App Service . الاختلاف الوحيد بين هذه القوالب هو أن قالب Node.js يقوم بتكوين المهمة لإنشاء ملف تكوين web يحتوي على معلمة تبدأ خدمة iisnode.

3. لربط مسار الإصدار هذا ب Azure artifact من الخطوة السابقة، حدد Add an artifact>Build.

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

5. احفظ مسار الإصدار وأنشئ إصدارًا لرؤيته قيد التنفيذ.

مثال: نشر تطبيق .NET

YAML

لنشر حزمة ويب .zip (على سبيل المثال، من تطبيق ويب ASP.NET) إلى Azure Web App، استخدم القصاصة البرمجية التالية لنشر البنية إلى تطبيق.

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
- task: AzureWebApp@1
  inputs:
    azureSubscription: '<service-connection-name>'
    appType: 'webAppLinux'
    appName: '<app-name>'
    package: '$(System.DefaultWorkingDirectory)/**/*.zip'

• azureSubscription: اشتراك Azure الخاص بك.
• appType: نوع تطبيق الويب الخاص بك.
• appName: اسم خدمة التطبيق الحالية.
• package: مسار الملف إلى الحزمة أو مجلد يحتوي على محتويات خدمة التطبيق. يتم دعم أحرف البدل.

كلاسيكي

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

• في صفحة Pipelines ، أنشئ تطبيقك واختبره باستخدام القالب الذي تختاره، مثل ASP.NET Core، Node.js مع Grunt أو Maven أو غيرها، وانشر أداة.
• في صفحة Release، استخدم قالب توزيع Azure App Service العام لنشر البيانات الاصطناعية.

قد تكون هناك قوالب للغات برمجة معينة للاختيار من بينها.

مثال: النشر إلى تطبيق ظاهري

YAML

بشكل افتراضي، يحدث التوزيع الخاص بك للتطبيق الجذر في Azure Web App. يمكنك النشر إلى تطبيق ظاهري معين باستخدام VirtualApplication خاصية مهمة توزيع (AzureRmWebAppDeployment) Azure App Service:

- task: AzureRmWebAppDeployment@4
  inputs:
    VirtualApplication: '<name of virtual application>'

• VirtualApplication: اسم التطبيق الظاهري الذي تم تكوينه في مدخل Microsoft Azure. لمزيد من المعلومات، راجع تكوين تطبيق App Service في مدخل Microsoft Azure .

كلاسيكي

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

مثال: النشر إلى فتحة

YAML

يوضح المثال التالي كيفية التوزيع إلى فتحة التدريج، ثم التبديل إلى فتحة التشغيل:

- task: AzureWebApp@1
  inputs:
    azureSubscription: '<service-connection-name>'
    appType: webAppLinux
    appName: '<app-name>'
    deployToSlotOrASE: true
    resourceGroupName: '<name of resource group>'
    slotName: staging
    package: '$(Build.ArtifactStagingDirectory)/**/*.zip'

- task: AzureAppServiceManage@0
  inputs:
    azureSubscription: '<service-connection-name>'
    appType: webAppLinux
    WebAppName: '<app-name>'
    ResourceGroupName: '<name of resource group>'
    SourceSlot: staging
    SwapWithProduction: true

• azureSubscription: اشتراك Azure الخاص بك.
• appType: (اختياري) استخدم webAppLinux للتوزيع إلى تطبيق ويب على Linux.
• appName: اسم خدمة التطبيق الحالية.
• deployToSlotOrASE: منطقي. التوزيع إلى فتحة نشر موجودة أو بيئة خدمة تطبيقات Azure.
• ResourceGroupName: اسم مجموعة الموارد. مطلوب إذا كان deployToSlotOrASE صحيحًا.
• slotName: اسم الفتحة، الذي يتم تعيينه افتراضيا إلى production. مطلوب إذا كان deployToSlotOrASE صحيحًا.
• package: مسار الملف إلى الحزمة أو مجلد يحتوي على محتويات خدمة التطبيق. يتم دعم أحرف البدل.
• SourceSlot: يتم إرسال الفتحة إلى التشغيل عندما SwapWithProduction يكون صحيحًا.
• SwapWithProduction: منطقي. استبدل نسبة استخدام فتحة المصدر بالتشغيل.

كلاسيكي

استخدم الخيار Deploy to Slot أو App Service Environment في مهمة Azure Web App لتحديد الفتحة التي سيتم التوزيع إليها. لتبديل الفتحات، استخدم مهمة إدارة Azure App Service.

مثال: النشر إلى تطبيقات ويب متعددة

YAML

يمكنك استخدام المهام في ملف YAML لإعداد مسار عمليات التوزيع. باستخدام المهام، يمكنك التحكم في ترتيب التوزيع إلى تطبيقات ويب متعددة.

jobs:
- job: buildandtest
  pool:
    vmImage: ubuntu-latest
 
  steps:
  # publish an artifact called drop
  - task: PublishPipelineArtifact@1
    inputs:
      targetPath: '$(Build.ArtifactStagingDirectory)' 
      artifactName: drop
  
  # deploy to Azure Web App staging
  - task: AzureWebApp@1
    inputs:
      azureSubscription: '<service-connection-name>'
      appType: <app type>
      appName: '<staging-app-name>'
      deployToSlotOrASE: true
      resourceGroupName: <group-name>
      slotName: 'staging'
      package: '$(Build.ArtifactStagingDirectory)/**/*.zip'

- job: deploy
  dependsOn: buildandtest
  condition: succeeded()

  pool: 
    vmImage: ubuntu-latest  
  
  steps:
    # download the artifact drop from the previous job
  - task: DownloadPipelineArtifact@2
    inputs:
      source: 'current'
      artifact: 'drop'
      path: '$(Pipeline.Workspace)'

  - task: AzureWebApp@1
    inputs:
      azureSubscription: '<service-connection-name>'
      appType: <app type>
      appName: '<production-app-name>'
      resourceGroupName: <group-name>
      package: '$(Pipeline.Workspace)/**/*.zip'

كلاسيكي

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

مثال: إجراء استبدالات متغيرة

بالنسبة لمعظم مكدسات اللغة، يمكن تعيين إعدادات التطبيق وسلاسل الاتصال كمتغيرات بيئة في وقت التشغيل.

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

YAML

تعرض القصاصة البرمجية التالية مثالا على استبدال المتغيرات باستخدام مهمة توزيع خدمة تطبيقات Azure (AzureRmWebAppDeployment):

jobs:
- job: test
  variables:
    connectionString: <test-stage connection string>
  steps:
  - task: AzureRmWebAppDeployment@4
    inputs:
      azureSubscription: '<Test stage Azure service connection>'
      WebAppName: '<name of test stage web app>'
      enableXmlVariableSubstitution: true

- job: prod
  dependsOn: test
  variables:
    connectionString: <prod-stage connection string>
  steps:
  - task: AzureRmWebAppDeployment@4
    inputs:
      azureSubscription: '<Prod stage Azure service connection>'
      WebAppName: '<name of prod stage web app>'
      enableXmlVariableSubstitution: true

كلاسيكي

للتغيير connectionString باستخدام استبدال متغير:

1. إنشاء مسار للإصدار مع مرحلتين.
2. ربط البيانات الاصطناعية للإصدار بالبنية التي تنتج حزمة الويب.
3. حدد connectionString كمتغير في كل مرحلة من المراحل. تعيين القيمة المناسبة.
4. حدد خيار استبدال متغير XML ضمن تحويلات الملفات وخيارات استبدال المتغير لمهمة Azure App Service Deploy.

مثال: التوزيع بشكل مشروط

YAML

للقيام بذلك في YAML، يمكنك استخدام إحدى التقنيات التالية:

• اعزل خطوات التوزيع في مهمة منفصلة، وأضف شرطًا إلى تلك المهمة.
• إضافة شرط إلى الخطوة.

يوضح المثال التالي كيفية استخدام شروط الخطوة لتوزيع البنيات التي تنشأ من الفرع الرئيسي فقط:

- task: AzureWebApp@1
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
  inputs:
    azureSubscription: '<service-connection-name>'
    appName: '<app-name>'

لمعرفة المزيد حول الشروط، راجع تحديد الشروط.

كلاسيكي

في مسار الإصدار الخاص بك، يمكنك تنفيذ العديد من الفحوصات والشروط للتحكم في التوزيع:

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

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

مثال: النشر باستخدام Web Deploy

يمكن نشر مهمة توزيع Azure App Service (AzureRmWebAppDeployment) إلى App Service باستخدام Web Deploy.

YAML

trigger:
- main

pool:
  vmImage: windows-latest

variables:
  buildConfiguration: 'Release'

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(buildConfiguration)'
    zipAfterPublish: true
- task: AzureRmWebAppDeployment@4
  inputs:
    ConnectionType: 'AzureRM'
    azureSubscription: '<service-connection-name>'
    appType: 'webApp'
    WebAppName: '<app-name>'
    packageForLinux: '$(System.DefaultWorkingDirectory)/**/*.zip'
    enableCustomDeployment: true
    DeploymentType: 'webDeploy'

كلاسيكي

في مسار الإصدار، بافتراض أنك تستخدم قالب توزيع Azure App Service:

1. حدد علامة التبويب Tasks، ثم حدد Deploy Azure App Service. هذه هي AzureRmWebAppDeployment المهمة.

2. في مربع الحوار، تأكد من تعيين نوع الاتصال ion إلى Azure Resource Manager.

3. في مربع الحوار، قم بتوسيع Additional Deployment Options وحدد Select deployment method. تأكد من تحديد Web Deploy كطريقة نشر.

4. احفظ مسار الإصدار.

إشعار

AzureRmWebAppDeployment@3 مع المهام وAzureRmWebAppDeployment@4، يجب استخدام نوع اتصال Azure Resource Manager أو AzureRMعند النشر باستخدام Web Deploy. ويستخدم ملفات تعريف النشر للنشر عند تمكين المصادقة الأساسية لتطبيقك، ولكنه يستخدم مصادقة معرف إنترا الأكثر أمانا عند تعطيل المصادقة الأساسية.

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

ما الفرق بين AzureWebApp المهام و AzureRmWebAppDeployment ؟

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

يمكن لمهمة Azure App Service Deploy (AzureRmWebAppDeployment) معالجة المزيد من السيناريوهات المخصصة، مثل:

• تعديل إعدادات التكوين داخل حزم الويب وملفات معلمات XML.
• النشر باستخدام Web Deploy، إذا كنت معتادا على عملية نشر IIS.
• النشر إلى التطبيقات الظاهرية.
• النشر إلى أنواع التطبيقات الأخرى، مثل تطبيقات الحاوية أو تطبيقات الوظائف أو WebJobs أو تطبيقات API وتطبيقات الأجهزة المحمولة.

إشعار

يتم أيضًا دعم تحويلات الملفات واستبدال المتغيرات بواسطة مهمة تحويل الملفات المنفصلة للاستخدام في Azure Pipelines. يمكنك استخدام مهمة تحويل الملف لتطبيق تحويلات الملفات والاستبدالات المتغيرة على أي ملفات تكوين ومعلمات.

أحصل على الرسالة "تم توفير حزمة خدمة التطبيقات أو مسار المجلد غير صالح."

في مسارات YAML، اعتمادا على البنية الأساسية لبرنامج ربط العمليات التجارية الخاصة بك، قد يكون هناك عدم تطابق بين مكان حفظ حزمة الويب المضمنة ومكان البحث عن مهمة التوزيع. على سبيل المثال، AzureWebApp تلتقط المهمة حزمة الويب للنشر. على سبيل المثال، تبحث مهمة AzureWebApp في $(System.DefaultWorkingDirectory)/**/*.zip. إذا تم إيداع حزمة الويب في مكان آخر، فعدل قيمة package.

أتلقى الرسالة "يتم دعم خيارات النشر باستخدام webdeploy فقط عند استخدام عامل Windows."

يحدث هذا الخطأ في مهمة AzureRmWebAppDeployment عند تكوين المهمة للنشر باستخدام Web Deploy، ولكن عاملك لا يقوم بتشغيل Windows. تحقق من أن YAML الخاص بك يحتوي على شيء مشابه للتعليمات البرمجية التالية:

pool:
  vmImage: windows-latest

لا يعمل Web Deploy عند تعطيل المصادقة الأساسية

للحصول على معلومات استكشاف الأخطاء وإصلاحها حول الحصول على مصادقة معرف Microsoft Entra للعمل مع AzureRmWebAppDeployment المهمة، راجع لا يمكنني نشر الويب إلى خدمة تطبيقات Azure باستخدام مصادقة معرف Microsoft Entra من وكيل Windows الخاص بي

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

• قم بتخصيص مسار Azure DevOps لديك.