اقرأ باللغة الإنجليزية

مشاركة عبر

أتمتة توزيع الموارد لتطبيق الوظيفة في وظائف Azure

  • مقالة
  • ١٨‏/٠٤‏/١٤٤٦ هـ
Choose a hosting option for your function app

يمكنك استخدام ملف Bicep أو قالب Azure Resource Manager (ARM) لأتمتة عملية نشر تطبيق الوظائف. أثناء النشر، يمكنك استخدام موارد Azure الموجودة أو إنشاء موارد جديدة. تساعدك الأتمتة في هذه السيناريوهات:

  • دمج عمليات توزيع الموارد مع التعليمات البرمجية المصدر في Azure Pipelines والنشرات المستندة إلى إجراءات GitHub.
  • استعادة تطبيق دالة والموارد ذات الصلة من نسخة احتياطية.
  • نشر مخطط تطبيق عدة مرات.

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

يعتمد رمز القالب المطلوب على خيارات الاستضافة المطلوبة لتطبيق الوظائف. تدعم هذه المقالة خيارات الاستضافة التالية:

خيار الاستضافة نوع التوزيع لمعرفة المزيد، راجع...
خطة استهلاك وظائف Azure تعليمة برمجية فقط خطة الاستهلاك
خطة استهلاك Azure Functions Flex تعليمة برمجية فقط خطة استهلاك Flex
خطة Azure Functions Elastic Premium التعليمات البرمجية | وعاء خطة متميزة
خطة Azure Functions Dedicated (App Service) التعليمات البرمجية | وعاء خطة مخصصة
Azure Container Apps الحاوية فقط استضافة تطبيقات الحاوية لوظائف Azure
Azure Arc التعليمات البرمجية | وعاء App Service وFunctions وLogic Apps على Azure Arc (معاينة)

عند استخدام هذه المقالة، ضع هذه الاعتبارات في الاعتبار:

  • لا توجد طريقة متعارف عليه لهيكلة قالب ARM.

  • يمكن تقسيم توزيع Bicep إلى ملفات Bicep متعددة.

  • تفترض هذه المقالة أن لديك فهما أساسيا لإنشاء ملفات Bicep أو تأليف قوالب Azure Resource Manager.

  • يتم عرض الأمثلة كأقسام فردية لموارد معينة. للحصول على مجموعة واسعة من ملفات Bicep الكاملة وأمثلة قالب ARM، راجع أمثلة نشر تطبيق الوظائف هذه.
  • يتم عرض الأمثلة كأقسام فردية لموارد معينة. للحصول على مجموعة واسعة من ملفات Bicep الكاملة وأمثلة قالب ARM، راجع أمثلة توزيع تطبيق Flex Consumption هذه.
  • يتم عرض الأمثلة كأقسام فردية لموارد معينة.

الموارد المطلوبة

يجب إنشاء هذه الموارد أو تكوينها لنشر مستضاف على Azure Functions:

Resource المتطلبات مرجع بناء الجملة والخصائص
A حساب تخزين المطلوب Microsoft.Storage/storageAccounts
مكوّن تحليلات التطبيق مستحسن Microsoft.Insights/مكوّنات*
خطة الاستضافة المطلوب Microsoft.Web/مزارع الخادم
تطبيق دالة المطلوب Microsoft.Web/sites

يجب إنشاء هذه الموارد أو تكوينها لنشر مستضاف على Azure Functions:

Resource المتطلبات مرجع بناء الجملة والخصائص
A حساب تخزين المطلوب Microsoft.Storage/storageAccounts
مكوّن تحليلات التطبيق مستحسن Microsoft.Insights/مكوّنات*
تطبيق دالة المطلوب Microsoft.Web/sites

عادة ما يتكون النشر المستضاف من Azure Container Apps من هذه الموارد:

Resource المتطلبات مرجع بناء الجملة والخصائص
A حساب تخزين المطلوب Microsoft.Storage/storageAccounts
مكوّن تحليلات التطبيق مستحسن Microsoft.Insights/مكوّنات*
بيئة مدارة المطلوب Microsoft.App/managedEnvironments
تطبيق دالة المطلوب Microsoft.Web/sites

عادة ما يتكون النشر المستضاف من Azure Arc من هذه الموارد:

Resource المتطلبات مرجع بناء الجملة والخصائص
A حساب تخزين المطلوب Microsoft.Storage/storageAccounts
مكوّن تحليلات التطبيق مستحسن Microsoft.Insights/components1
بيئة App Service Kubernetes المطلوب Microsoft.ExtendedLocation/customLocations
تطبيق دالة المطلوب Microsoft.Web/sites

*إذا لم يكن لديك بالفعل مساحة عمل Log Analytics التي يمكن استخدامها من قبل مثيل Application Insights الخاص بك، فستحتاج أيضا إلى إنشاء هذا المورد.

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

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

  • تم تصميم الأمثلة للتنفيذ في سياق مجموعة موارد موجودة.
  • تتطلب كل من Application Insights وسجلات التخزين أن يكون لديك مساحة عمل Azure Log Analytics موجودة. يمكن مشاركة مساحات العمل بين الخدمات، وكقاعدة عامة، يجب إنشاء مساحة عمل في كل منطقة جغرافية لتحسين الأداء. للحصول على مثال حول كيفية إنشاء مساحة عمل Log Analytics، راجع إنشاء مساحة عمل Log Analytics. يمكنك العثور على معرف مورد مساحة العمل المؤهل بالكامل في صفحة مساحة عمل في مدخل Microsoft Azure ضمن Settings>Properties>Resource ID.
  • تفترض هذه المقالة أنك قمت بالفعل بإنشاء بيئة مدارة في Azure Container Apps. تحتاج إلى كل من اسم ومعرف البيئة المدارة لإنشاء تطبيق دالة مستضاف على تطبيقات الحاوية.
  • تفترض هذه المقالة أنك قمت بالفعل بإنشاء موقع مخصص ممكن لخدمة التطبيقات على مجموعة Kubernetes الممكنة في Azure Arc. تحتاج إلى كل من معرف الموقع المخصص ومعرف بيئة Kubernetes لإنشاء تطبيق دالة مستضاف في موقع Azure Arc المخصص.

«Create storage account»

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

هام

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

ينشئ قسم المثال هذا حساب تخزين V2 للأغراض العامة القياسية:

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
  properties: {
    supportsHttpsTrafficOnly: true
    defaultToOAuthAuthentication: true
    allowBlobPublicAccess: false
  }
}

لمزيد من السياق، راجع ملف main.bicep الكامل في مستودع القوالب.

لمزيد من السياق، راجع ملف storage-account.bicep الكامل في مستودع العينة.

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

حاوية التوزيع

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

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

يوضح هذا المثال كيفية إنشاء حاوية في حساب التخزين:

resource blobServices 'blobServices' = if (!empty(containers)) {
  name: 'default'
  properties: {
    deleteRetentionPolicy: deleteRetentionPolicy
  }
  resource container 'containers' = [for container in containers: {
    name: container.name
    properties: {
      publicAccess: contains(container, 'publicAccess') ? container.publicAccess : 'None'
    }
  }]
}

للحصول على القصاصة البرمجية في السياق، راجع مثال التوزيع هذا.

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

تمكين سجلات التخزين

نظرا لاستخدام حساب التخزين لبيانات تطبيق الوظائف المهمة، يجب عليك مراقبة الحساب لتعديل هذا المحتوى. لمراقبة حساب التخزين الخاص بك، تحتاج إلى تكوين سجلات موارد Azure Monitor ل Azure Storage. في هذا المثال، يتم استخدام مساحة عمل Log Analytics المسماة myLogAnalytics كوجهة لهذه السجلات.

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' existing = {
  name:'default'
  parent:storageAccountName
}

resource storageDataPlaneLogs 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: '${storageAccountName}-logs'
  scope: blobService
  properties: {
    workspaceId: myLogAnalytics.id
    logs: [
      {
        category: 'StorageWrite'
        enabled: true
      }
    ]
    metrics: [
      {
        category: 'Transaction'
        enabled: true
      }
    ]
  }
}

يمكن استخدام نفس مساحة العمل هذه لمورد Application Insights المحدد لاحقا. لمزيد من المعلومات، بما في ذلك كيفية العمل مع هذه السجلات، راجع مراقبة تخزين Azure.

إنشاء Application Insights

يجب أن تستخدم Application Insights لمراقبة عمليات تنفيذ تطبيق الوظائف. يتطلب Application Insights الآن مساحة عمل Azure Log Analytics، والتي يمكن مشاركتها. تفترض هذه الأمثلة أنك تستخدم مساحة عمل موجودة ولديك معرف المورد المؤهل بالكامل لمساحة العمل. لمزيد من المعلومات، راجع مساحة عمل Azure Log Analytics.

في هذا القسم المثال، يتم تعريف مورد Application Insights بالنوع Microsoft.Insights/components والنوع web:

resource applicationInsight 'Microsoft.Insights/components@2020-02-02' = {
  name: applicationInsightsName
  location: appInsightsLocation
  tags: tags
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: '<FULLY_QUALIFIED_RESOURCE_ID>'
  }
}

لمزيد من السياق، راجع ملف main.bicep الكامل في مستودع القوالب.

يجب توفير الاتصال بتطبيق الوظائف باستخدام APPLICATIONINSIGHTS_CONNECTION_STRING إعداد التطبيق. لمزيد من المعلومات، راجع تكوين التطبيق.

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

إنشاء خطة الاستضافة

يجب أن تكون التطبيقات المستضافة في خطة استهلاك Azure Functions Flex أو خطة Premium أو خطة مخصصة (App Service) محددة بشكل صريح.

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

خطة استهلاك Flex هي نوع خاص من serverfarm الموارد. يمكنك تحديده باستخدام FC1 لقيمة الخاصية Name في الخاصية sku بقيمة tierFlexConsumption.

ينشئ قسم المثال هذا خطة استهلاك Flex:

resource flexFuncPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: planName
  location: location
  tags: tags
  kind: 'functionapp'
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true
  }
}

لمزيد من السياق، راجع ملف function.bicep الكامل في مستودع نموذج خطة Flex Consumption.

نظرا لأن خطة Flex Consumption تدعم حاليا Linux فقط، يجب عليك أيضا تعيين الخاصية reserved إلى true.

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

الخطة المتميزة هي نوع خاص من مورد serverfarm. يمكنك تحديده باستخدام أو EP1EP2أو EP3 لقيمة الخاصية Name في الخاصية sku . تعتمد الطريقة التي تحدد بها خطة استضافة الوظائف على ما إذا كان تطبيق الوظائف يعمل على Windows أو على Linux. ينشئ EP1 قسم المثال هذا خطة:

لتشغيل تطبيقك على Linux، يجب عليك أيضا تعيين خاصية "reserved": true للمورد serverfarms :

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'EP1'
    tier: 'ElasticPremium'
    family: 'EP'
  }
  kind: 'elastic'
  properties: {
    maximumElasticWorkerCount: 20
    reserved: true
  }
}

لمزيد من السياق، راجع ملف main.bicep الكامل في مستودع القوالب.

لمزيد من المعلومات حول sku العنصر، راجع SkuDefinition قوالب المثال أو راجعها.

في خطة Dedicated (App Service)، يعمل تطبيق الوظائف على أجهزة ظاهرية مخصصة على وحدات SKU الأساسية والقياسية والمتميزة في خطط App Service، على غرار تطبيقات الويب. لمزيد من المعلومات، راجع الخطة المخصصة.

للحصول على عينة ملف Bicep/قالب Azure Resource Manager، راجع تطبيق الوظيفة على خطة Azure App Service.

في Functions، الخطة المخصصة هي مجرد خطة App Service عادية، والتي يتم تعريفها بواسطة مورد serverfarm. يجب توفير القيمة على الأقل name . للحصول على قائمة بأسماء الخطط المدعومة، راجع --sku الإعداد az appservice plan create في القائمة الحالية للقيم المدعومة لخطة مخصصة.

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

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    tier: 'Standard'
    name: 'S1'
    size: 'S1'
    family: 'S'
    capacity: 1
  }
  properties: {
    reserved: true
  }
}

لمزيد من السياق، راجع ملف main.bicep الكامل في مستودع القوالب.

إنشاء خطة الاستضافة

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

يمكنك تعريف خطة الاستهلاك بشكل صريح كنوع خاص من serverfarm الموارد، والتي تحددها باستخدام قيمة Dynamic الخاصيتين computeMode و sku . يوضح لك قسم المثال هذا كيفية تحديد خطة استهلاك بشكل صريح. تعتمد الطريقة التي تحدد بها خطة الاستضافة على ما إذا كان تطبيق الوظائف يعمل على Windows أو على Linux.

لتشغيل تطبيقك على Linux، يجب أيضاً تعيين الخاصية "reserved": true للمورد serverfarms:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  sku: {
    name: 'Y1'
    tier: 'Dynamic'
    size: 'Y1'
    family: 'Y'
    capacity: 0
  }
  properties: {
    computeMode: 'Dynamic'
    reserved: true
  }
}

لمزيد من السياق، راجع ملف main.bicep الكامل في مستودع القوالب.

بيئة Kubernetes

يمكن نشر Azure Functions في Kubernetes الممكنة في Azure Arc إما كمشروع تعليمة برمجية أو تطبيق وظائف في حاوية.

لإنشاء موارد التطبيق والتخطيط، يجب أن تكون قد أنشأت بالفعل بيئة Kubernetes لخدمة التطبيقات لمقطع تخزين Kubernetes الممكّنة بواسطة Azure Arc. تفترض الأمثلة في هذه المقالة أن لديك معرف المورد للموقع المخصص (customLocationId) وبيئة App Service Kubernetes (kubeEnvironmentId) التي تقوم بنشرها، والتي تم تعيينها في هذا المثال:

param kubeEnvironmentId string
param customLocationId string

يجب أن تشير كل من المواقع والخطط إلى الموقع المخصص من خلال حقل extendedLocation. كما هو موضح في هذا المثال المقتطع، extendedLocation يقع خارج properties، كنظير إلى kind و location:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  ...
  {
    extendedLocation: {
      name: customLocationId
    }
  }
}

يجب أن يستخدم مورد الخطة قيمة Kubernetes (K1) ل SKU، kind ويجب أن يكون linux,kubernetesالحقل ، ويجب أن تكون trueالخاصية reserved ، لأنها توزيع Linux. يجب عليك أيضا تعيين extendedLocation و kubeEnvironmentProfile.id إلى معرف الموقع المخصص ومعرف بيئة Kubernetes، على التوالي، والتي قد تبدو مثل هذا القسم المثال:

resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-01' = {
  name: hostingPlanName
  location: location
  kind: 'linux,kubernetes'
  sku: {
    name: 'K1'
    tier: 'Kubernetes'
  }
  extendedLocation: {
    name: customLocationId
  }
  properties: {
    kubeEnvironmentProfile: {
      id: kubeEnvironmentId
    }
    reserved: true
  }
}

إنشاء تطبيق الدالة

يتم تعريف مورد تطبيق الدالة بواسطة مورد من النوع Microsoft.Web/siteskind ويتضمن functionapp، كحد أدنى.

تعتمد الطريقة التي تحدد بها مورد تطبيق الوظائف على ما إذا كنت تستضيف على Linux أو على Windows:

عند تشغيل تطبيق الوظائف على Linux، يجب عليك:

  • عيّن kind إلى functionapp,linux.
  • عيّن reserved إلى true.
  • قم بتعيين الخاصية linuxFxVersion ضمن siteConfig إلى القيمة الصحيحة لمكدس وقت التشغيل بتنسيق <runtime>|<runtimeVersion>. لمزيد من المعلومات، راجع مرجع إعداد موقع linuxFxVersion.

للحصول على قائمة بإعدادات التطبيق المطلوبة عند التشغيل على Linux، راجع تكوين التطبيق.

للحصول على نموذج ملف Bicep أو قالب ARM، راجع تطبيق الوظائف المستضاف على قالب خطة استهلاك Linux.

عند تشغيل تطبيق الوظائف على Linux، يجب عليك:

  • عيّن kind إلى functionapp,linux.
  • عيّن reserved إلى true.
  • قم بتعيين الخاصية linuxFxVersion ضمن siteConfig إلى القيمة الصحيحة لمكدس وقت التشغيل بتنسيق <runtime>|<runtimeVersion>. لمزيد من المعلومات، راجع مرجع إعداد موقع linuxFxVersion.

للحصول على قائمة بإعدادات التطبيق المطلوبة عند التشغيل على Linux، راجع تكوين التطبيق.

يحل Flex Consumption محل العديد من إعدادات التطبيق القياسية وخصائص تكوين الموقع المستخدمة في عمليات توزيع قالب Bicep وARM. لمزيد من المعلومات، راجع تكوين التطبيق.

resource flexFuncApp 'Microsoft.Web/sites@2024-04-01' = {
  name: appName
  location: location
  tags: tags
  kind: 'functionapp,linux'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    serverFarmId: flexFuncPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage__accountName'
          value: storage.name
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: appInsights.properties.ConnectionString
        }
      ]
    }
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
          authentication: {
            type: 'SystemAssignedIdentity'
          }
        }
      }
      scaleAndConcurrency: {
        maximumInstanceCount: maximumInstanceCount
        instanceMemoryMB: instanceMemoryMB
      }
      runtime: { 
        name: functionAppRuntime
        version: functionAppRuntimeVersion
      }
    }
  }
}

لمزيد من السياق، راجع ملف function.bicep الكامل في مستودع نموذج خطة Flex Consumption.

ملاحظة

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

قم بتعيين الخاصية serverFarmId على التطبيق بحيث تشير إلى معرف المورد للخطة. تأكد من أن تطبيق الوظيفة يحتوي على إعداد dependsOn يشير أيضاً إلى الخطة.

resource functionApp 'Microsoft.Web/sites@2021-02-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp,linux'
  properties: {
    reserved: true
    serverFarmId: hostingPlan.id
    siteConfig: {
      linuxFxVersion: 'node|14'
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'WEBSITE_CONTENTSHARE'
          value: toLower(functionAppName)
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
      ]
    }
  }
}

للحصول على مثال كامل من طرف إلى طرف، راجع ملف main.bicep هذا.

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp,linux'
  properties: {
    reserved: true
    serverFarmId: hostingPlan.id
    siteConfig: {
      alwaysOn: true
      linuxFxVersion: 'node|14'
      appSettings: [
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};EndpointSuffix=${environment().suffixes.storage};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
      ]
    }
  }
}

للحصول على مثال كامل من طرف إلى طرف، راجع ملف main.bicep هذا.

مصادر التوزيع

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

هام

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

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

يمكن لملف Bicep أو قالب ARM اختياريا أيضا تحديد توزيع للتعليمات البرمجية للدالة الخاصة بك، والتي يمكن أن تتضمن هذه الطرق:

تحافظ خطة Flex Consumption على التعليمات البرمجية للمشروع في ملف الحزمة المضغوطة في حاوية تخزين blob المعروفة باسم حاوية النشر. يمكنك تكوين كل من حساب التخزين والحاوية المستخدمة للنشر. للحصول على مزيد من المعلومات، راجع التوزيع.

يجب استخدام نشر واحد لنشر حزمة التعليمات البرمجية الخاصة بك إلى حاوية التوزيع. أثناء توزيع ARM أو Bicep، يمكنك القيام بذلك عن طريق تعريف مصدر حزمة يستخدم الملحق /onedeploy . إذا اخترت بدلا من ذلك تحميل الحزمة مباشرة إلى الحاوية، فلن يتم نشر الحزمة تلقائيا.

حاوية التوزيع

يتم تعيين حساب التخزين المحدد والحاوية المستخدمة في عمليات النشر وطريقة المصادقة وبيانات الاعتماد في functionAppConfig.deployment.storage عنصر properties الموقع. يجب أن تكون الحاوية وأي إعدادات تطبيق موجودة عند إنشاء التطبيق. للحصول على مثال حول كيفية إنشاء حاوية التخزين، راجع حاوية النشر.

يستخدم هذا المثال هوية مدارة معينة من قبل النظام للوصول إلى حاوية تخزين blob المحددة، والتي تم إنشاؤها في مكان آخر في النشر:

deployment: {
  storage: {
    type: 'blobContainer'
    value: '${storage.properties.primaryEndpoints.blob}${deploymentStorageContainerName}'
    authentication: {
      type: 'SystemAssignedIdentity'
    }
  }
}

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

// Allow access from function app to storage account using a managed identity
resource storageRoleAssignment 'Microsoft.Authorization/roleAssignments@2020-04-01-preview' = {
  name: guid(storage.id, storageRoleDefinitionId)
  scope: storage
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', storageRoleDefinitionId)
    principalId: flexFuncApp.identity.principalId
    principalType: 'ServicePrincipal'
  }
}

للحصول على مثال مرجعي كامل، راجع ملف Bicep هذا.

يتطلب هذا المثال معرفة قيمة GUID للدور الذي يتم تعيينه. يمكنك الحصول على قيمة المعرف هذه لأي اسم دور مألوف باستخدام الأمر az role definition list ، كما في هذا المثال:

az role definition list --output tsv --query "[?roleName=='Storage Blob Data Owner'].{name:name}"

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

حزمة التوزيع

تستخدم خطة Flex Consumption توزيعا واحدا لنشر مشروع التعليمات البرمجية. حزمة التعليمات البرمجية نفسها هي نفسها التي ستستخدمها لنشر zip في خطط استضافة الوظائف الأخرى. ومع ذلك، يجب أن يكون released-package.zipاسم ملف الحزمة نفسه .

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

يضيف هذا المثال مصدر نشر واحدا إلى تطبيق موجود:

@description('The name of the function app.')
param functionAppName string

@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location

@description('The zip content URL for released-package.zip.')
param packageUri string

resource functionAppName_OneDeploy 'Microsoft.Web/sites/extensions@2022-09-01' = {
  name: '${functionAppName}/onedeploy'
  location: location
  properties: {
    packageUri: packageUri
    remoteBuild: false 
  }
}

يمكن لملف Bicep أو قالب ARM اختياريا أيضا تحديد توزيع للتعليمات البرمجية للدالة باستخدام حزمة توزيع مضغوطة.

لتوزيع التطبيق بنجاح باستخدام Azure Resource Manager، من المهم فهم كيفية توزيع الموارد في Azure. في معظم الأمثلة، يتم تطبيق تكوينات المستوى الأعلى باستخدام siteConfig. من المهم تعيين هذه التكوينات في مستوى أعلى؛ لأنها تنقل المعلومات إلى مشغل وقت تشغيل وتوزيع المحرك. مطلوب معلومات المستوى الأعلى قبل تطبيق المورد التابع sourcecontrols/web . على الرغم من أنه من الممكن تكوين هذه الإعدادات في المورد على مستوى config/appSettings التابع، في بعض الحالات يجب نشر تطبيق الوظائف قبلconfig/appSettings تطبيقه.

حزمة توزيع Zip

يعد توزيع Zip طريقة موصى بها لنشر التعليمات البرمجية لتطبيق الوظائف. بشكل افتراضي، تعمل الوظائف التي تستخدم توزيع zip في حزمة التوزيع نفسها. لمزيد من المعلومات، بما في ذلك متطلبات حزمة التوزيع، راجع توزيع Zip ل Azure Functions. عند استخدام أتمتة توزيع الموارد، يمكنك الرجوع إلى حزمة توزيع .zip في قالب Bicep أو ARM.

لاستخدام توزيع zip في القالب الخاص بك، قم بتعيين WEBSITE_RUN_FROM_PACKAGE الإعداد في التطبيق إلى 1 وتضمين /zipDeploy تعريف المورد.

بالنسبة لخطة الاستهلاك على Linux، قم بدلا من ذلك بتعيين URI لحزمة التوزيع مباشرة في WEBSITE_RUN_FROM_PACKAGE الإعداد، كما هو موضح في هذا المثال القالب.

يضيف هذا المثال مصدر نشر مضغوط إلى تطبيق موجود:

@description('The name of the function app.')
param functionAppName string

@description('The location into which the resources should be deployed.')
param location string = resourceGroup().location

@description('The zip content url.')
param packageUri string

resource functionAppName_ZipDeploy 'Microsoft.Web/sites/extensions@2021-02-01' = {
  name: '${functionAppName}/ZipDeploy'
  location: location
  properties: {
    packageUri: packageUri
  }
}

ضع الأشياء التالية في الاعتبار عند تضمين موارد توزيع zip في القالب الخاص بك:

  • packageUri يجب أن يكون موقعا يمكن الوصول إليه بواسطة Functions. ضع في اعتبارك استخدام تخزين Azure blob مع توقيع وصول مشترك (SAS). بعد انتهاء صلاحية SAS، لا يمكن للدالات الوصول إلى المشاركة الخاصة بالنشر. عند إعادة إنشاء SAS الخاص بك، تذكر تحديث WEBSITE_RUN_FROM_PACKAGE الإعداد بقيمة URI الجديدة.

  • عند الإعداد WEBSITE_RUN_FROM_PACKAGE إلى URI، يجب مزامنة المشغلات يدويا.

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

  • لا تدعم الوظائف Web Deploy (msdeploy) لتوزيع الحزمة. يجب عليك بدلا من ذلك استخدام توزيع zip في مسارات التوزيع والأتمتة. لمزيد من المعلومات، راجع توزيع Zip ل Azure Functions.

الإصدارات البعيدة

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

هناك سيناريوهات تتطلب منك إعادة إنشاء تطبيقك عن بعد. أحد الأمثلة على ذلك هو عندما تحتاج إلى تضمين حزم خاصة ب Linux في Python أو Node.js التطبيقات التي طورتها على كمبيوتر Windows. في هذه الحالة، يمكنك تكوين Functions لتنفيذ بنية عن بعد على التعليمات البرمجية الخاصة بك بعد نشر الرمز البريدي.

تعتمد الطريقة التي تطلب بها إنشاء عن بعد على نظام التشغيل الذي تقوم بالنشر إليه:

لتمكين نفس عمليات الإنشاء التي تحصل عليها مع التكامل المستمر، أضف SCM_DO_BUILD_DURING_DEPLOYMENT=true إلى إعدادات التطبيق في التعليمات البرمجية WEBSITE_RUN_FROM_PACKAGE للتوزيع الخاص بك وقم بإزالة بالكامل.

ENABLE_ORYX_BUILD يتم تعيين الإعداد إلى true بشكل افتراضي. إذا كانت لديك مشكلات في إنشاء تطبيق وظائف .NET أو Java، فقم بتعيينه بدلا من ذلك إلى false.

يمكن تشغيل تطبيقات الوظائف التي تم إنشاؤها عن بعد على Linux من حزمة.

حاويات Linux

إذا كنت تقوم بنشر تطبيق وظائف في حاوية إلى Azure Functions Premium أو خطة مخصصة، يجب عليك:

إذا كانت بعض الإعدادات مفقودة، فقد يفشل توفير التطبيق مع خطأ HTTP/500 هذا:

Function app provisioning failed.

لمزيد من المعلومات، راجع تكوين التطبيق.

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      appSettings: [
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'FUNCTIONS_WORKER_RUNTIME'
          value: 'node'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~14'
        }
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_URL'
          value: dockerRegistryUrl
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_USERNAME'
          value: dockerRegistryUsername
        }
        {
          name: 'DOCKER_REGISTRY_SERVER_PASSWORD'
          value: dockerRegistryPassword
        }
        {
          name: 'WEBSITES_ENABLE_APP_SERVICE_STORAGE'
          value: 'false'
        }
      ]
      linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
    }
  }
  dependsOn: [
    storageAccount
  ]
}

عند نشر الوظائف الحاوية إلى Azure Container Apps، يجب أن يكون القالب الخاص بك:

  • kind تعيين الحقل إلى قيمة functionapp,linux,container,azurecontainerapps.
  • managedEnvironmentId قم بتعيين خاصية الموقع إلى URI المؤهل بالكامل لبيئة Container Apps.
  • إضافة ارتباط مورد في مجموعة الموقع dependsOn عند إنشاء مورد في نفس الوقت الذي يتم فيه إنشاء Microsoft.App/managedEnvironments الموقع.

قد يبدو تعريف تطبيق وظائف حاوية تم نشره من سجل حاوية خاص إلى بيئة Container Apps موجودة مثل هذا المثال:

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  kind: 'functionapp,linux,container,azurecontainerapps'
  location: location
  properties: {
    serverFarmId: hostingPlanName
    siteConfig: {
      linuxFxVersion: 'DOCKER|myacr.azurecr.io/myimage:mytag'
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
      ]
    }
    managedEnvironmentId: managedEnvironmentId
  }
  dependsOn: [
    storageAccount
    hostingPlan
  ]
}

عند نشر الدالات إلى Azure Arc، تعتمد القيمة التي قمت بتعيينها لحقل kind مورد تطبيق الوظائف على نوع النشر:

نوع التوزيع kind قيمة الحقل
نشر التعليمات البرمجية فقط functionapp,linux,kubernetes
نشر الحاوية functionapp,linux,kubernetes,container

يجب عليك أيضا تعيين customLocationId كما فعلت لمورد خطة الاستضافة.

قد يبدو تعريف تطبيق الوظائف المعبأة في حاويات، باستخدام صورة التشغيل السريع .NET 6، مثل هذا المثال:

resource functionApp 'Microsoft.Web/sites@2022-03-01' = {
  name: functionAppName
  kind: 'kubernetes,functionapp,linux,container'
  location: location
  extendedLocation: {
    name: customLocationId
  }
  properties: {
    serverFarmId: hostingPlanName
    siteConfig: {
      linuxFxVersion: 'DOCKER|mcr.microsoft.com/azure-functions/4-dotnet-isolated6.0-appservice-quickstart'
      appSettings: [
        {
          name: 'FUNCTIONS_EXTENSION_VERSION'
          value: '~4'
        }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${storageAccount.listKeys().keys[0].value}'
        }
        {
          name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
          value: applicationInsightsName.properties.ConnectionString
        }
      ]
      alwaysOn: true
    }
  }
  dependsOn: [
    storageAccount
    hostingPlan
  ]
}

تكوين التطبيق

في خطة Flex Consumption، يمكنك تكوين تطبيق الوظائف في Azure بنوعين من الخصائص:

التكوين Microsoft.Web/sites خاصية
تكوين التطبيق functionAppConfig
إعدادات التطبيق siteConfig.appSettings مجموعة

يتم الاحتفاظ بتكوينات التطبيق هذه في functionAppConfig:

سلوك إعداد في functionAppConfig
مثيلات جاهزة دائما scaleAndConcurrency.alwaysReady
مصدر التوزيع deployment
حجم ذاكرة المثيل scaleAndConcurrency.instanceMemoryMB
تزامن مشغل HTTP scaleAndConcurrency.triggers.http.perInstanceConcurrency
وقت تشغيل اللغة runtime.name
إصدار اللغة runtime.version
الحد الأقصى لعدد المثيلات scaleAndConcurrency.maximumInstanceCount

تدعم خطة Flex Consumption أيضا إعدادات التطبيق التالية:

توفر الوظائف الخيارات التالية لتكوين تطبيق الوظائف في Azure:

التكوين Microsoft.Web/sites خاصية
إعدادات الموقع siteConfig
إعدادات التطبيق siteConfig.appSettings مجموعة

إعدادات الموقع هذه مطلوبة على الخاصية siteConfig :

إعدادات الموقع هذه مطلوبة فقط عند استخدام الهويات المدارة للحصول على الصورة من مثيل Azure Container Registry:

إعدادات التطبيق هذه مطلوبة (أو مستحسنة) لنظام تشغيل معين وخيار استضافة:

هذه الإعدادات مطلوبة فقط عند النشر من سجل حاوية خاص:

هذه الإعدادات مطلوبة فقط عند النشر من سجل حاوية خاص:

إعدادات التطبيق هذه مطلوبة لنشر الحاوية:

هذه الإعدادات مطلوبة فقط عند النشر من سجل حاوية خاص:

ضع هذه الاعتبارات في الاعتبار عند العمل مع إعدادات الموقع والتطبيق باستخدام ملفات Bicep أو قوالب ARM:

  • يحتوي الإعداد الاختياري alwaysReady على صفيف من كائن واحد أو أكثر {name,instanceCount} ، مع عنصر واحد لكل مجموعة مقياس لكل وظيفة. هذه هي مجموعات المقياس المستخدمة لاتخاذ قرارات تغيير الحجم الجاهزة دائما. يعين هذا المثال أعدادا جاهزة دائما لكل من http المجموعة ودالة واحدة تسمى helloworld، وهي من نوع مشغل غير مجمع:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • هناك اعتبارات مهمة للوقت الذي يجب تعيينه WEBSITE_CONTENTSHARE في نشر تلقائي. للحصول على إرشادات مفصلة، راجع WEBSITE_CONTENTSHARE المرجع.
  • بالنسبة إلى عمليات نشر الحاوية، قم أيضا بتعيين WEBSITES_ENABLE_APP_SERVICE_STORAGE إلى false، حيث يتم توفير محتوى التطبيق الخاص بك في الحاوية نفسها.

  • يجب عليك دائما تعريف إعدادات التطبيق كمجموعة siteConfig/appSettings من المورد الذي Microsoft.Web/sites يتم إنشاؤه، كما هو الحال في الأمثلة الواردة في هذه المقالة. يضمن هذا التعريف الإعدادات التي يحتاج تطبيق الوظائف إلى تشغيلها متوفرة عند بدء التشغيل الأولي.

  • عند إضافة إعدادات التطبيق أو تحديثها باستخدام القوالب، تأكد من تضمين جميع الإعدادات الموجودة مع التحديث. يجب القيام بذلك لأن استدعاءات واجهة برمجة تطبيقات REST للتحديث الأساسي تحل محل المورد بأكمله /config/appsettings . إذا قمت بإزالة الإعدادات الموجودة، فلن يتم تشغيل تطبيق الوظائف. لتحديث إعدادات التطبيق الفردية برمجيا، يمكنك بدلا من ذلك استخدام Azure CLI أو Azure PowerShell أو مدخل Microsoft Azure لإجراء هذه التغييرات. لمزيد من المعلومات، راجع العمل مع إعدادات التطبيق.

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

عمليات نشر الفتحة

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

يتم تعريف مورد الفتحة بنفس طريقة تعريف مورد تطبيق الوظائف (Microsoft.Web/sites)، ولكن بدلا من ذلك يمكنك استخدام Microsoft.Web/sites/slots معرف المورد. للحصول على مثال للتوزيع (في كل من قوالب Bicep وARM) التي تنشئ كلا من الإنتاج وفتحة التقسيم المرحلي في خطة Premium، راجع Azure Function App مع فتحة نشر.

للتعرف على كيفية تبديل الفتحات باستخدام القوالب، راجع أتمتة باستخدام قوالب Resource Manager.

ضع الاعتبارات التالية في الاعتبار عند العمل مع عمليات توزيع الفتحات:

  • لا تقم بتعيين WEBSITE_CONTENTSHARE الإعداد بشكل صريح في تعريف فتحة التوزيع. يتم إنشاء هذا الإعداد لك عند إنشاء التطبيق في فتحة التوزيع.

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

عمليات النشر الآمنة

يمكنك إنشاء تطبيق الوظائف في عملية نشر حيث تم تأمين مورد واحد أو أكثر من خلال التكامل مع الشبكات الظاهرية. يتم تعريف تكامل الشبكة الظاهرية لتطبيق الوظائف الخاص بك بواسطة Microsoft.Web/sites/networkConfig مورد. يعتمد هذا التكامل على كل من تطبيق الوظائف المشار إليه وموارد الشبكة الظاهرية. قد يعتمد تطبيق الوظائف أيضا على موارد الشبكات الخاصة الأخرى، مثل نقاط النهاية والمسارات الخاصة. لمزيد من المعلومات، راجع خيارات شبكة Azure Functions.

توفر هذه المشاريع أمثلة مستندة إلى Bicep لكيفية نشر تطبيقات الوظائف في شبكة ظاهرية، بما في ذلك مع قيود الوصول إلى الشبكة:

عند إنشاء نشر يستخدم حساب تخزين آمن، يجب عليك تعيين WEBSITE_CONTENTSHARE الإعداد بشكل صريح وإنشاء مورد مشاركة الملف المسمى في هذا الإعداد. تأكد من إنشاء Microsoft.Storage/storageAccounts/fileServices/shares مورد باستخدام قيمة WEBSITE_CONTENTSHARE، كما هو موضح في هذا المثال (ملف Bicep لقالب|ARM). ستحتاج أيضا إلى تعيين خاصية vnetContentShareEnabled الموقع إلى صحيح.

ملاحظة

عندما لا تكون هذه الإعدادات جزءا من عملية نشر تستخدم حساب تخزين آمن، سترى هذا الخطأ أثناء التحقق من صحة التوزيع: Could not access storage account using provided connection string.

توفر هذه المشاريع كلا من أمثلة قالب Bicep وARM لكيفية نشر تطبيقات الوظائف في شبكة ظاهرية، بما في ذلك مع قيود الوصول إلى الشبكة:

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

إعدادات الشبكة المقيدة

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

الإعداد قيمة ‏‏الوصف
WEBSITE_CONTENTOVERVNET 1 إعداد التطبيق الذي يمكن تطبيق الوظائف من التوسع عندما يكون حساب التخزين مقيدا بشبكة ظاهرية. لمزيد من المعلومات، راجع تقييد حساب التخزين الخاص بك بشبكة ظاهرية.
vnetrouteallenabled 1 إعداد الموقع الذي يفرض على كل حركة المرور من تطبيق الوظائف استخدام الشبكة الظاهرية. لمزيد من المعلومات، راجع تكامل الشبكة الظاهرية الإقليمية. يحل إعداد الموقع هذا محل إعداد WEBSITE_VNET_ROUTE_ALLالتطبيق .

اعتبارات قيود الشبكة

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

مفاتيح الوصول إلى الدالة

يتم تعريف مفاتيح الوصول إلى الوظائف على مستوى المضيف كموارد Azure. وهذا يعني أنه يمكنك إنشاء مفاتيح المضيف وإدارتها في قوالب ARM وملفات Bicep. يتم تعريف مفتاح المضيف كمورد من النوع Microsoft.Web/sites/host/functionKeys. ينشئ هذا المثال مفتاح وصول على مستوى المضيف يسمى my_custom_key عند إنشاء تطبيق الوظائف:

resource functionKey 'Microsoft.Web/sites/host/functionKeys@2022-09-01' = {
  name: '${parameters('name')}/default/my_custom_key'
  properties: {
    name: 'my_custom_key'
  }
  dependsOn: [
    resourceId('Microsoft.Web/Sites', parameters('name'))
  ]
}

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

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

إنشاء القالب الخاص بك

يمكن للخبراء الذين لديهم قوالب Bicep أو ARM ترميز عمليات النشر يدويا باستخدام محرر نص بسيط. بالنسبة لبقيتنا، هناك عدة طرق لتسهيل عملية التطوير:

  • Visual Studio Code: هناك ملحقات متوفرة لمساعدتك في العمل مع كل من ملفات Bicep وقوالب ARM. يمكنك استخدام هذه الأدوات للمساعدة في التأكد من صحة التعليمات البرمجية الخاصة بك، وأنها توفر بعض التحقق الأساسي.

  • مدخل Azure: عند إنشاء تطبيق الوظائف والموارد ذات الصلة في المدخل، تحتوي شاشة المراجعة + الإنشاء النهائية على ارتباط تنزيل قالب للأتمتة.

    قم بتنزيل ارتباط القالب من عملية إنشاء Azure Functions في مدخل Microsoft Azure.

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

صلاحية القالب الخاص بك

عند إنشاء ملف قالب التوزيع يدويا، من المهم التحقق من صحة القالب قبل النشر. تتحقق جميع أساليب النشر من صحة بناء جملة القالب الخاص بك وترفع validation failed رسالة خطأ كما هو موضح في المثال التالي بتنسيق JSON:

{"error":{"code":"InvalidTemplate","message":"Deployment template validation failed: 'The resource 'Microsoft.Web/sites/func-xyz' is not defined in the template. Please see https://aka.ms/arm-template for usage details.'.","additionalInfo":[{"type":"TemplateViolation","info":{"lineNumber":0,"linePosition":0,"path":""}}]}}

يمكن استخدام الطرق التالية للتحقق من صحة القالب قبل النشر:

ترشد مهمة توزيع مجموعة موارد Azure الإصدار 2 التالية مع deploymentMode: 'Validation' Azure Pipelines للتحقق من صحة القالب.

- task: AzureResourceManagerTemplateDeployment@3
  inputs:
    deploymentScope: 'Resource Group'
    subscriptionId: # Required subscription ID
    action: 'Create Or Update Resource Group'
    resourceGroupName: # Required resource group name
    location: # Required when action == Create Or Update Resource Group
    templateLocation: 'Linked artifact'
    csmFile: # Required when  TemplateLocation == Linked Artifact
    csmParametersFile: # Optional
    deploymentMode: 'Validation'

يمكنك أيضا إنشاء مجموعة موارد اختبار للعثور على أخطاء الاختبار المسبق والتوزيع.

نشر قالبك

يمكنك استخدام أي من الطرق التالية لتوزيع ملف Bicep والقالب:

زر "Deploy to Azure"

ملاحظة

لا يدعم هذا الأسلوب توزيع ملفات Bicep الحالية.

دفع استبدل <url-encoded-path-to-azuredeploy-json> مع إصدار عنوان موقع الويب المرمّز من المسار الخام لazuredeploy.jsonملفك في GitHub.

وفيما يلي مثال يستخدم علامة markdown:

[![Deploy to Azure](https://azuredeploy.net/deploybutton.png)](https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>)

فيما يلي مثال يستخدم HTML:

<a href="https://portal.azure.com/#create/Microsoft.Template/uri/<url-encoded-path-to-azuredeploy-json>" target="_blank"><img src="https://azuredeploy.net/deploybutton.png"></a>

توزيع باستخدام PowerShell

تنشئ أوامر PowerShell التالية مجموعة موارد وتنشر ملف Bicep أو قالب ARM الذي ينشئ تطبيق وظائف بموارده المطلوبة. للتشغيل محليًّا، يجب أن يكون لديك Azure PowerShell مثبتة. لتسجيل الدخول إلى Azure، يجب أولا تشغيل Connect-AzAccount.

# Register Resource Providers if they're not already registered
Register-AzResourceProvider -ProviderNamespace "microsoft.web"
Register-AzResourceProvider -ProviderNamespace "microsoft.storage"

# Create a resource group for the function app
New-AzResourceGroup -Name "MyResourceGroup" -Location 'West Europe'

# Deploy the template
New-AzResourceGroupDeployment -ResourceGroupName "MyResourceGroup" -TemplateFile main.bicep  -Verbose

لاختبار هذا التوزيع، يمكنك استخدام قالب مثل هذاالذي ينشئ تطبيق الوظائف على Windows في خطة استهلاك.

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

اعرف المزيد حول كيفية تطوير وتكوين وظائف Azure.

الموارد الإضافية

‏‏الوثائق