Автоматизация развертывания ресурсов для приложения-функции в Azure Functions

Чтобы автоматизировать развертывание приложения-функции, используйте файл Bicep или шаблон Azure Resource Manager (шаблон ARM). Во время развертывания можно использовать существующие ресурсы Azure или создавать новые.

Используя автоматизацию развертывания, инфраструктуру как код (IaC) и непрерывную интеграцию и развертывание (CI/CD), вы можете воспользоваться этими преимуществами для рабочих приложений:

  • Согласованность. Определите инфраструктуру в коде, чтобы обеспечить согласованность развертываний в разных средах.
  • Управление версиями: отслеживайте изменения в конфигурации инфраструктуры и приложений в системе управления версиями вместе с кодом проекта.
  • Автоматизация: автоматизация развертывания, что сокращает количество ошибок вручную и сокращает процесс выпуска.
  • Масштабируемость: легко реплицировать инфраструктуру для нескольких сред, таких как разработка, тестирование и производство.
  • Аварийное восстановление: быстро создайте инфраструктуру после сбоев или во время миграции.

В этой статье показано, как автоматизировать создание ресурсов Azure и конфигураций развертывания для Azure Functions. Дополнительные сведения о непрерывном развертывании кода проекта см. в статье Continuous deployment for Azure Functions.

Код шаблона для создания необходимых Azure ресурсов зависит от требуемых параметров размещения для приложения-функции. В этой статье поддерживаются следующие варианты размещения:

Вариант размещения Тип развертывания Шаблоны с примерами
План потребления Flex Code-only Bicep
шаблон ARM
Terraform
План "Премиум" Код | Контейнер Bicep
шаблон ARM
Выделенный план Код | Контейнер Bicep
шаблон ARM
Приложения контейнеров Azure Container-only Bicep
План потребления (устаревшая версия) Code-only Bicep
шаблон ARM

Для новых бессерверных приложений-функций используйте план потребления Flex.
План потребления — это устаревший тарифный план для размещения. Для существующих приложений перейдите в план потребления Flex.

Убедитесь, что выбрали план размещения в верхней части статьи.

Important

Приложения-функции, которые по-прежнему работают под управлением среды выполнения версии 3 в Linux на плане потребления, перестанут работать после 30 сентября 2026 г. Чтобы избежать нарушения работы службы, перенесите приложение в среду выполнения версии 4.

Возможность размещения приложений-функций на Linux в плане с оплатой за потребление прекращается 30 сентября 2028 года. План потребления Linux не получает новых функций или языковых версий. Приложения, работающие на Windows в плане потребления, в настоящее время не затрагиваются. Перенесите ваши приложения на план потребления Flex до даты прекращения поддержки.

При использовании этой статьи следует учитывать следующие аспекты:

  • Нет канонического способа структурировать шаблон ARM.

  • Вы можете разделять развертывание Bicep на модули, используя несколько файлов Bicep и проверенные модули Azure (AVMs).

  • В этой статье предполагается, что у вас есть базовое представление о создании файлов Bicep или создании шаблонов Azure Resource Manager.

  • Примеры показаны в виде отдельных разделов для определенных ресурсов. Чтобы ознакомиться с обширным набором примеров полных файлов Bicep и шаблонов ARM, см. примеры развертывания Function App .
  • Примеры показаны в виде отдельных разделов для определенных ресурсов. Для Bicep отображаются проверенные модули Azure (AVM), если они доступны. Обширный набор полных примеров файлов Bicep и шаблонов ARM см. в примерах развертывания приложения Flex Consumption.
  • Примеры показаны в виде отдельных разделов для определенных ресурсов.

Обязательные ресурсы

Необходимо создать или настроить эти ресурсы для развертывания, размещенного на Azure Functions.

Resource Requirement Справочник по синтаксису и свойствам
Учетная запись хранения Required Microsoft. Storage/storageAccounts
Компонент Application Insights Recommended Microsoft. Insights/components*
План размещения Required Microsoft. Web/serverfarms
Функция приложения Required Microsoft. Веб-сайты

Необходимо создать или настроить эти ресурсы для развертывания, размещенного на Azure Functions.

Resource Requirement Справочник по синтаксису и свойствам
Учетная запись хранения Required Microsoft. Storage/storageAccounts
Компонент Application Insights Recommended Microsoft. Insights/components*
Функция приложения Required Microsoft. Веб-сайты

Развертывание, размещенное на платформе Azure Container Apps, обычно состоит из следующих ресурсов:

Resource Requirement Справочник по синтаксису и свойствам
Учетная запись хранения Required Microsoft. Storage/storageAccounts
Компонент Application Insights Recommended Microsoft. Insights/components*
Управляемая среда Required Microsoft.App/managedEnvironments
Функция приложения Required Microsoft. Веб-сайты

*Если у вас еще нет рабочей области Log Analytics, которую может использовать экземпляр Application Insights, необходимо также создать этот ресурс.

При развертывании нескольких ресурсов в одном файле Bicep или шаблоне ARM важно указать порядок создания ресурсов. Это требование приводит к зависимостям между ресурсами. Для таких зависимостей обязательно используйте dependsOn элемент для определения зависимости в зависимом ресурсе. Дополнительные сведения см. в разделе Определите порядок развертывания ресурсов в шаблонах ARM или Зависимости ресурсов в Bicep.

Prerequisites

  • Эти примеры работают в контексте существующей группы ресурсов.
  • Для журналов Application Insights и логов хранилища требуется существующая рабочая область Azure Log Analytics. Вы можете совместно использовать рабочие области между службами. Чтобы повысить производительность, создайте рабочую область в каждом географическом регионе. Пример создания рабочей области Log Analytics см. в статье Создание рабочей области Log Analytics. Полный идентификатор ресурса рабочей области можно найти на странице рабочей области на портале Azure в разделе "Параметры>свойства>ресурса".
  • В этой статье предполагается, что вы уже создали управляемую среду в приложениях контейнеров Azure. Для создания приложения-функции, размещенного в контейнерных приложениях, необходимо имя и идентификатор управляемой среды.

Создание учетной записи хранения

Для всех приложений-функций требуется учетная запись хранения Azure. Вам нужна учетная запись общего назначения, которая поддерживает BLOB-объекты, таблицы, очереди и файлы. Для получения дополнительной информации см. в документе требования к учетной записи для хранения Azure Functions.

Important

Учетная запись хранения используется для хранения важных данных приложения, иногда включая сам код приложения. Необходимо ограничить доступ от других приложений и пользователей к учетной записи хранения.

В этом примере создается универсальная учетная запись хранения типа Standard версии 2.

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
    minimumTlsVersion: 'TLS1_2'
  }
}

Дополнительные сведения см. в полном main.bicep файле в репозитории шаблонов.

Для получения более подробной информации см. полный файл storage-PrivateEndpoint.bicep в репозитории с примерами.

Для работы приложения-функции необходимо подключение к этой учетной записи хранения. Настройте это подключение с помощью AzureWebJobsStorage параметра. Дополнительные сведения см. в разделе "Конфигурация приложения".

Tip

Для повышения безопасности добавьте allowSharedKeyAccess: false в свойства учетной записи хранения и используйте подключения на основе управляемой идентификации вместо строковых подключений. Примеры плана потребления Flex в этой статье используют этот подход, включая AzureWebJobsStorage__* настройки на основе удостоверений и управляемое удостоверение, назначаемое системой. Дополнительные сведения см. в разделе Подключение к хранилищу узла с помощью удостоверения.

Tip

Для повышения безопасности установите значение allowSharedKeyAccessfalse в учетной записи хранения и используйте подключения на основе управляемых удостоверений вместо строк подключения. Дополнительные сведения см. в разделе Подключение к хранилищу узла с помощью удостоверения.

Important

Планы эластичного уровня "Премиум" и "Потребление" используют файлы Azure для общего доступа к содержимому, а файлы Azure в настоящее время не поддерживают подключения на основе управляемых удостоверений. Это ограничение означает, что эти конфигурации требуют доступа к учетной записи хранения с общим ключом, поэтому не задавайте для allowSharedKeyAccess значение false. Если необходимо использовать строки подключения, сохраните их в Azure Key Vault и используйте ссылки Key Vault в параметрах приложения вместо хранения ключей напрямую. Если вы хотите удалить зависимость файлов Azure, см. статью "Создание приложения без файлов Azure".

Контейнер развертывания

Чтобы развернуть приложение в рамках тарифа Flex Consumption, в качестве источника развертывания требуется контейнер в хранилище Azure Blob Storage. Вы можете использовать учетную запись хранения по умолчанию или указать отдельную учетную запись хранения. Дополнительные сведения см. в разделе "Настройка параметров развертывания".

При создании приложения необходимо настроить эту учетную запись развертывания, включая конкретный контейнер, используемый для развертываний. Дополнительные сведения о настройке развертываний см. в статье "Источники развертывания".

В этом примере показано, как создать контейнер в учетной записи хранения:

}

// Azure Functions Flex Consumption
module functionApp 'br/public:avm/res/web/site:0.16.0' = {
  name: 'functionapp'
  scope: rg
  params: {
    kind: 'functionapp,linux'
    name: functionAppName_resolved
    location: location
    tags: union(tags, { 'azd-service-name': 'api' })
    serverFarmResourceId: appServicePlan.outputs.resourceId
    managedIdentities: {
      systemAssigned: true
    }
    functionAppConfig: {
      deployment: {
        storage: {
          type: 'blobContainer'
          value: '${storage.outputs.primaryBlobEndpoint}${deploymentStorageContainerName}'
          authentication: {
            type: 'SystemAssignedIdentity'
          }

В этом примере показано, как использовать AVM для учетных записей хранения для создания контейнера хранилища BLOB вместе с созданием учетной записи хранения. В контексте см. этот пример развертывания.

Настройте другие параметры развертывания с помощью самого приложения.

Включение журналов хранилища

Так как учетная запись хранения используется для важных данных функционального приложения, отслеживайте изменения этого содержимого. Чтобы отслеживать учетную запись хранения, настройте журналы ресурсов Azure Monitor для службы хранилища Azure. В этом примере в качестве назначения для этих журналов используется рабочая область Log Analytics с именем myLogAnalytics.

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-05-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, определенного позже. Дополнительные сведения, включая работу с этими журналами, см. в разделе Monitoring Azure Storage.

Создайте 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 для задания ключа инструментирования, который больше не рекомендуется.

Создание плана размещения

Необходимо явно определить план размещения для приложений, размещенных в гибком плане потребления,Плане Premium или выделенном плане (служба приложений).

Flex Consumption — это план хостинга на основе Linux, который использует модель выставления счетов без сервера по принципу "плати за то, что используешь". План предусматривает поддержку частной сети, выбор размера памяти экземпляра и улучшенную поддержку управляемого удостоверения.

План потребления Flex — это особый serverfarm тип ресурса. Можно задать это, используя FC1 для значения свойства Name в свойстве sku со значением tierFlexConsumption.

В этом примере создается план потребления Flex:

  scaleAndConcurrency: {
    maximumInstanceCount: maximumInstanceCount
    instanceMemoryMB: instanceMemoryMB
  }
  runtime: { 
    name: functionAppRuntime
    version: functionAppRuntimeVersion
  }
}
siteConfig: {
  alwaysOn: false
}
configs: [{
  name: 'appsettings'
  properties:{

В этом примере используется AVM для планов службы приложений. В контексте см. этот пример развертывания.

Так как план потребления Flex в настоящее время поддерживает только Linux, необходимо также задать для свойства reserved значение true.

План "Премиум" предлагает такие же возможности масштабирования, как и план потребления, предоставляя выделенные ресурсы и дополнительные возможности. Дополнительные сведения см. в разделе Премиум-план Azure Functions.

План "Премиум" — это специальный тип ресурса serverfarm. Его можно указать с помощью EP1, EP2 либо EP3 для значения свойства Name в свойстве sku. Способ определения плана размещения функций зависит от того, работает ли приложение-функция на Windows или в Linux. Этот пример создает план EP1:

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

Дополнительные сведения см. в полном main.bicep файле в репозитории шаблонов.

Дополнительные сведения об объекте sku см. в SkuDefinition или ознакомьтесь с примерами шаблонов.

В плане "Выделенная служба приложений" приложение-функция работает на выделенных виртуальных машинах на базовых, стандартных и премиум номерах SKU в планах службы приложений, аналогичных веб-приложениям. Дополнительные сведения см. в разделе "Выделенный план".

Для примера файла Bicep или шаблона Azure Resource Manager, см. раздел Function app on Azure App Service plan.

В Функциях план "Dedicated" — это стандартный план службы приложений, который определяется ресурсом serverfarm. Необходимо указать значение как минимум name. Список имен поддерживаемых планов смотрите в параметре --sku в az appservice plan create для получения текущего списка поддерживаемых значений для выделенного плана.

Способ определения плана размещения зависит от того, работает ли приложение-функция на Windows или в Linux:

resource hostingPlanName 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: hostingPlanName
  location: location
  sku: {
    tier: 'Standard'
    name: 'S1'
    size: 'S1'
    family: 'S'
    capacity: 1
  }
}

Дополнительные сведения см. в полном main.bicep файле в репозитории шаблонов.

Создание плана размещения

Вам не нужно явно определять ресурс плана размещения потребления. Если пропустить это определение ресурса, портал автоматически создает или выбирает план на основе каждого региона при создании самого ресурса приложения-функции.

Вы можете явно определить план потребления в качестве специального serverfarm типа ресурса. Задайте для свойств computeMode и sku значение Dynamic. В этом примере показано, как явно определить план потребления. Способ определения плана размещения зависит от того, работает ли ваше приложение-функция на Windows или в Linux.

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

Дополнительные сведения см. в полном main.bicep файле в репозитории шаблонов.

Создайте функциональное приложение

Определите ресурс приложения-функции как ресурс типа Microsoft.Web/sites со свойством kind , который включает в себя functionapp.

Способ, которым вы определяете ресурс приложения-функции, зависит от того, размещается ли оно на Linux или на Windows:

Список параметров приложения, необходимых при выполнении Windows, см. в разделе Application configuration. Пример файла Bicep или шаблона Azure Resource Manager см. в шаблоне функционального приложения, размещенного в Windows в плане потребления.

Список параметров приложения, необходимых при выполнении Windows, см. в разделе Application configuration.

Flex Consumption заменяет многие стандартные параметры приложения и свойства конфигурации сайта, которые используются в развертываниях с помощью Bicep и шаблонов ARM. Дополнительные сведения см. в разделе "Конфигурация приложения".

        AzureWebJobsStorage__blobServiceUri: 'https://${storage.outputs.name}.blob.${environment().suffixes.storage}'
        AzureWebJobsStorage__queueServiceUri: 'https://${storage.outputs.name}.queue.${environment().suffixes.storage}'
        AzureWebJobsStorage__tableServiceUri: 'https://${storage.outputs.name}.table.${environment().suffixes.storage}'

        // Application Insights settings are always included
        APPLICATIONINSIGHTS_CONNECTION_STRING: applicationInsights.outputs.connectionString
        APPLICATIONINSIGHTS_AUTHENTICATION_STRING: 'Authorization=AAD'
    }
    }]
  }
}

// Consolidated Role Assignments
module rbacAssignments 'rbac.bicep' = {
  name: 'rbacAssignments'
  scope: rg
  params: {
    storageAccountName: storage.outputs.name
    appInsightsName: applicationInsights.outputs.name
    managedIdentityPrincipalId: functionApp.outputs.?systemAssignedMIPrincipalId ?? ''
    userIdentityPrincipalId: principalId
    allowUserIdentityPrincipal: !empty(principalId)
  }
}

// Outputs
output AZURE_LOCATION string = location
output AZURE_TENANT_ID string = tenant().tenantId
output AZURE_FUNCTION_NAME string = functionApp.outputs.name
output APPLICATIONINSIGHTS_CONNECTION_STRING string = applicationInsights.outputs.connectionString

В этом примере используется AVM для приложений-функций. В контексте см. этот пример развертывания.

Note

Если вы решили дополнительно определить план потребления, необходимо установить serverFarmId свойство в приложении таким образом, чтобы оно указывало на идентификатор ресурса плана. Убедитесь, что функциональное приложение имеет dependsOn параметр, который также ссылается на план. Если вы явно не определили план, он создается для вас.

Установите свойство serverFarmId в приложении, чтобы оно указывало на идентификатор ресурса плана. Убедитесь, что функциональное приложение имеет dependsOn параметр, который также ссылается на план.

resource functionAppName_resource 'Microsoft.Web/sites@2024-04-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlanName.id
    siteConfig: {
      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'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~20'
        }
      ]
    }
  }
}

Полный пример см. в файле main.bicep.

resource functionApp 'Microsoft.Web/sites@2024-04-01' = {
  name: functionAppName
  location: location
  kind: 'functionapp'
  properties: {
    serverFarmId: hostingPlan.id
    siteConfig: {
      alwaysOn: true
      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'
        }
        {
          name: 'WEBSITE_NODE_DEFAULT_VERSION'
          value: '~20'
        }
      ]
    }
  }
}

Полный пример см. в файле main.bicep.

Источники развертывания

linuxFxVersion Используйте параметр сайта, чтобы запросить определенный контейнер Linux для развертывания в приложении при его создании. Чтобы получить доступ к изображениям в частном репозитории, вам потребуется больше параметров. Дополнительные сведения см. в разделе "Конфигурация приложения".

Important

При создании собственных контейнеров необходимо сохранить базовый образ контейнера обновленным до последнего поддерживаемого базового образа. Поддерживаемые базовые образы для Azure Functions зависят от языка. См. репозитории базового образа Azure Functions.

Команда по функциям обязуется выпускать ежемесячные обновления для этих базовых образов. Регулярные обновления включают последние незначительные обновления версий и исправления безопасности для среды выполнения функций и языков. Необходимо регулярно обновлять контейнер из последнего базового образа и повторно развертывать обновленную версию контейнера. Дополнительные сведения см. в разделе "Обслуживание пользовательских контейнеров".

Файл Bicep или шаблон ARM также может определить развертывание для кода функции. Это развертывание может включать следующие методы:

План потребления Flex поддерживает код проекта в zip-сжатом файле пакета в контейнере хранилища блоб-объектов, известном как контейнер развертывания. Вы можете настроить учетную запись хранения и контейнер, используемые для развертывания. Дополнительные сведения см. в разделе "Развертывание".

Необходимо использовать одно развертывание для публикации пакета кода в контейнере развертывания. Во время развертывания шаблона ARM или Bicep можно выполнить этот шаг, определив источник пакета, использующий /onedeploy расширение. Если вы решили напрямую отправить пакет в контейнер, пакет не развертывается автоматически.

Контейнер развертывания

Задайте определенную учетную запись хранения и контейнер, используемый для развертываний, метод проверки подлинности и учетные данные в functionAppConfig.deployment.storage элементе properties сайта. Контейнер и все параметры приложения должны существовать при создании приложения. Пример создания контейнера хранилища см. в разделе "Контейнер развертывания".

В этом примере используется управляемая системная идентичность для доступа к указанному контейнеру хранилища BLOB-объектов, который создается в другом месте развертывания.

// Consolidated Role Assignments
module rbacAssignments 'rbac.bicep' = {
  name: 'rbacAssignments'
  scope: rg
  params: {
    storageAccountName: storage.outputs.name
    appInsightsName: applicationInsights.outputs.name
    managedIdentityPrincipalId: functionApp.outputs.?systemAssignedMIPrincipalId ?? ''
    userIdentityPrincipalId: principalId
    allowUserIdentityPrincipal: !empty(principalId)
  }
}

// Outputs
output AZURE_LOCATION string = location
output AZURE_TENANT_ID string = tenant().tenantId
output AZURE_FUNCTION_NAME string = functionApp.outputs.name
output APPLICATIONINSIGHTS_CONNECTION_STRING string = applicationInsights.outputs.connectionString

В этом примере используется AVM для приложений-функций. В контексте см. этот пример развертывания.

При использовании управляемых удостоверений необходимо также включить функциональное приложение, чтобы получить доступ к учетной записи хранения с помощью управляемого удостоверения, как показано в этом примере:

module storageRoleAssignment_User 'br/public:avm/ptn/authorization/resource-role-assignment:0.1.2' = if (allowUserIdentityPrincipal && !empty(userIdentityPrincipalId)) {
  name: 'storageRoleAssignment-User-${uniqueString(storageAccount.id, userIdentityPrincipalId)}'
  params: {
    resourceId: storageAccount.id
    roleDefinitionId: roleDefinitions.storageBlobDataOwner
    principalId: userIdentityPrincipalId
    principalType: 'User'
    description: 'Storage Blob Data Owner role for user identity (development/testing)'
    roleName: 'Storage Blob Data Owner'
  }
}

В этом примере используется AVM для назначения ролей на уровне ресурсов. В контексте см. этот пример развертывания.

В этом примере необходимо знать значение 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 использует одно развертывание для развертывания проекта кода. Сам пакет кода совпадает с пакетом, используемым для 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 может также опционально включать развертывание вашего кода функции с помощью пакета zip-развертывания.

Чтобы успешно развернуть приложение с помощью Azure Resource Manager, необходимо понять, как развертываются ресурсы в Azure. В большинстве примеров применяются конфигурации верхнего уровня с помощью siteConfig. Задайте эти конфигурации на верхнем уровне, так как они передают сведения в среду выполнения функций и подсистему развертывания. Для применения дочернего sourcecontrols/web ресурса подсистеме развертывания требуются сведения верхнего уровня. Хотя эти параметры можно настроить в ресурсе дочернего уровня config/appSettings, в некоторых случаях необходимо развернуть приложение-функцию перед применением config/appSettings.

Пакет развертывания ZIP

Развертывание ZIP-файла — это рекомендуемый способ развертывания кода приложения-функции. По умолчанию функции, использующие zip-развертывание, выполняются в самом пакете развертывания. Дополнительные сведения, включая требования к пакету развертывания, см. в разделе Zip deployment for Azure Functions. При использовании автоматизации развертывания ресурсов можно ссылаться на пакет развертывания .zip в Bicep или шаблоне ARM.

Чтобы использовать развертывание zip в шаблоне, установите параметр WEBSITE_RUN_FROM_PACKAGE в приложении на 1 и добавьте определение ресурса /zipDeploy.

Для плана потребления в Linux вместо этого задайте URI пакета развертывания непосредственно в параметре , как показано в этом примерном шаблоне .

В этом примере в существующее приложение добавляется источник zip-развертывания:

@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@2024-04-01' = {
  name: '${functionAppName}/ZipDeploy'
  location: location
  properties: {
    packageUri: packageUri
  }
}

При включении ресурсов zip-развертывания в шаблон следует учитывать следующие рекомендации.

  • Планы потребления в Linux не поддерживают WEBSITE_RUN_FROM_PACKAGE = 1. Вместо этого необходимо непосредственно в параметре WEBSITE_RUN_FROM_PACKAGE задать универсальный код ресурса (URI) пакета развертывания. Для получения дополнительной информации см. WEBSITE_RUN_FROM_PACKAGE. Ознакомьтесь с примером шаблона в Function app на Linux в плане Consumption.

  • packageUri должно быть расположением, к которому могут получить доступ Функции. Рассмотрите возможность использования хранилища BLOB-объектов Azure с общей сигнатурой доступа (SAS). После истечения срока действия SAS функции больше не смогут получить доступ к общему ресурсу для целей развертывания. При повторном создании SAS не забудьте обновить WEBSITE_RUN_FROM_PACKAGE параметр с новым значением URI.

  • При настройке WEBSITE_RUN_FROM_PACKAGE URI необходимо вручную синхронизировать триггеры.

  • Всегда устанавливайте все необходимые параметры приложения в appSettings коллекции при добавлении или обновлении параметров. Обновление удаляет существующие параметры, которые не заданы явным образом. Дополнительные сведения см. в разделе "Конфигурация приложения".

  • Функции не поддерживают веб-развертывание (msdeploy) для развертываний пакетов. Вместо этого необходимо использовать zip-развертывание в процессах развертывания и автоматизации. Дополнительные сведения см. в статье Zip deployment for Azure Functions.

Удаленные сборки

В процессе развертывания предполагается, что используемый вами файл .zip или zip-развертывание содержит готовое к выполнению приложение. Это предполагает, что по умолчанию настройки не выполняются.

Для некоторых сценариев требуется удаленное перестроение приложения. Один из примеров заключается в том, что необходимо включить пакеты для Linux в Python или Node.js приложения, разработанные на компьютере с Windows. В этом случае функции можно настроить для удаленной сборки кода после развертывания ZIP.

Способ запроса удаленной сборки зависит от операционной системы, в которой выполняется развертывание:

При развертывании приложения в Windows процесс развертывания выполняет команды, относящиеся к языку, например dotnet restore для приложений C# или npm install для приложений Node.js.

Чтобы обеспечить те же процессы сборки, которые вы получаете с непрерывной интеграцией, добавьте SCM_DO_BUILD_DURING_DEPLOYMENT=true в параметры вашего приложения в коде развертывания и полностью удалите настройку WEBSITE_RUN_FROM_PACKAGE.

Контейнеры Linux

Если вы развертываете контейнеризированное приложение-функцию в ценовых планах Azure Functions "Премиум" или "Выделенный", необходимо:

  • linuxFxVersion Задайте параметр сайта с идентификатором образа контейнера.
  • Задайте все необходимые DOCKER_REGISTRY_SERVER_* параметры при получении контейнера из частного реестра.
  • Установите параметр приложения WEBSITES_ENABLE_APP_SERVICE_STORAGE на false.

Если отсутствуют некоторые параметры, подготовка приложений может завершиться ошибкой HTTP/500:

Function app provisioning failed.

Дополнительные сведения см. в разделе "Конфигурация приложения".

resource functionApp 'Microsoft.Web/sites@2024-04-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: '~20'
        }
        {
          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) среды контейнерных приложений.
  • Добавьте ссылку на ресурс в коллекцию dependsOn при создании ресурса Microsoft.App/managedEnvironments одновременно с сайтом.

Определение контейнерного приложения-функции, развернутого из частного реестра контейнеров в существующей среде приложений контейнеров, может выглядеть следующим образом:

resource functionApp 'Microsoft.Web/sites@2024-04-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
  ]
}

Конфигурация приложений

В плане потребления Flex вы настраиваете приложение-функцию в Azure с двумя типами свойств:

Configuration свойство Microsoft.Web/sites
Конфигурация приложений functionAppConfig
Параметры приложения Коллекция siteConfig.appSettings

Вы поддерживаете эти конфигурации приложений в functionAppConfig.

Behavior Настройка в functionAppConfig
Экземпляры постоянной готовности scaleAndConcurrency.alwaysReady
Источник развертывания deployment
Размер экземпляра scaleAndConcurrency.instanceMemoryMB
Конкурентность триггера HTTP scaleAndConcurrency.triggers.http.perInstanceConcurrency
Языковая среда выполнения runtime.name
Языковая версия runtime.version
Максимальное число экземпляров scaleAndConcurrency.maximumInstanceCount
Стратегия обновления сайта siteUpdateStrategy.type

План потребления Flex также поддерживает следующие параметры приложения:

Функции предоставляют следующие параметры настройки приложения-функции в Azure:

Configuration свойство Microsoft.Web/sites
Параметры сайта siteConfig
Параметры приложения Коллекция siteConfig.appSettings

На объекте siteConfig необходимы следующие параметры сайта:

Эти настройки сайта необходимы только при использовании управляемых идентификаторов для получения образа из экземпляра реестра контейнеров Azure.

Эти параметры приложения являются обязательными (или рекомендуемыми) для определенной операционной системы и варианта размещения:

Эти параметры приложения необходимы для развертываний контейнеров:

Эти параметры требуются только при развертывании из частного реестра контейнеров:

Помните об этом при работе с параметрами сайта и приложения с помощью 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 API обновления заменяют весь /config/appsettings ресурс. Если удалить существующие параметры, приложение-функция не будет запускаться. Для программного обновления отдельных параметров приложения можно использовать Azure CLI, Azure PowerShell или портал Azure для внесения этих изменений. Дополнительные сведения см. в разделе Работа с параметрами приложения.

  • По возможности используйте подключения на основе управляемых удостоверений к другим службам Azure, включая AzureWebJobsStorage подключение. Дополнительные сведения см. в разделе Настройка подключения на основе удостоверений.

Развертывания слотов

Функции позволяют развертывать различные версии кода в уникальных конечных точках в приложении-функции. Этот параметр упрощает разработку, проверку и развертывание обновлений функций без влияния на функции, выполняемые в рабочей среде. Слоты развертывания — это функция Azure App Service. Количество доступных слотов зависит от размещающего плана. Дополнительные сведения см. в разделе слоты развертывания Azure Functions.

Ресурс слота определяется так же, как ресурс приложения-функции (Microsoft.Web/sites), но вместо этого используется Microsoft.Web/sites/slots идентификатор ресурса. Пример развертывания (как в Bicep, так и в шаблонах ARM), создающих слот производственной и промежуточной среды в плане Premium, см. в разделе приложение Azure Functions со слотом развертывания.

Дополнительные сведения о том, как переключать слоты с помощью шаблонов, см. в статье Автоматизация с помощью шаблонов диспетчера ресурсов.

При работе с развертываниями слотов следует учитывать следующие аспекты.

  • Не задавайте параметр WEBSITE_CONTENTSHARE явно в определении слота развертывания. Процесс создания приложения в слоте развертывания создает эту настройку для вас.

  • При перемещении слотов некоторые параметры приложения считаются "постоянными", поскольку они остаются с текущим слотом и не перемещаются вместе с кодом, который меняется местами. Вы можете определить такой параметр слота , включив "slotSetting":true в определение конкретного параметра приложения в шаблоне. Дополнительные сведения см. в разделе "Управление параметрами".

Защищенные развертывания

Вы можете создать функциональное приложение в развертывании, где вы защищаете один или несколько ресурсов, интегрируясь с виртуальными сетями. Ресурс Microsoft.Web/sites/networkConfig определяет интеграцию виртуальной сети для приложения-функции. Эта интеграция зависит от указанных приложений-функций и ресурсов виртуальной сети. Приложение-функция может также зависеть от других ресурсов частной сети, таких как частные конечные точки и маршруты. Дополнительные сведения см. в сетевых параметрах Azure Functions.

Эти проекты предоставляют основанные на Bicep примеры развертывания функциональных приложений в виртуальной сети, включая ограничения на сетевой доступ.

При создании развертывания, использующего безопасную учетную запись хранения, необходимо явно задать WEBSITE_CONTENTSHARE параметр и создать ресурс общей папки с именем этого параметра. Убедитесь, что вы создаете Microsoft.Storage/storageAccounts/fileServices/shares ресурс, используя значение WEBSITE_CONTENTSHARE, как показано в этом примере (шаблон ARM|файл Bicep). Кроме того, необходимо задать для свойства vnetContentShareEnabled сайта значение true.

Note

Если эти параметры не являются частью развертывания, использующего безопасную учетную запись хранения, во время проверки развертывания возникает эта ошибка: Could not access storage account using provided connection string.

Эти проекты предоставляют примеры как шаблонов Bicep, так и ARM о том, как развертывать ваши приложения-функции в виртуальной сети, в том числе с ограничениями сетевого доступа.

Ограниченный сценарий Description
Создайте функциональное приложение с интеграцией виртуальной сети Вы создаете приложение-функцию в виртуальной сети с полным доступом к ресурсам в этой сети. Входящий и исходящий доступ к приложению-функции не ограничен. Дополнительные сведения см. в разделе Интеграция виртуальной сети.
Создайте приложение-функцию, которое обращается к защищенной учетной записи хранилища Созданное приложение-функция использует безопасную учетную запись хранения, к которой функции обращаются с помощью частных конечных точек. Для получения дополнительной информации см. Ограничьте доступ к своей учетной записи хранения в пределах виртуальной сети.
Создайте функциональное приложение и учетную запись хранилища, которые использовали бы частные конечные точки для обоих Доступ к созданному приложению-функции можно получить только с помощью частных конечных точек, а для доступа к ресурсам хранилища используется частная конечная точка. Дополнительные сведения см. в разделе Частные конечные точки.

Параметры ограниченной сети

Возможно, вам также потребуется использовать эти параметры, если приложение-функция имеет ограничения сети:

Setting Value Description
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: при создании приложения-функции и связанных ресурсов на портале на последнем экране Review + create есть ссылка Скачать шаблон для автоматизации.

    Скачать ссылку на шаблон из процесса создания функций Azure на портале 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 с инструктирует 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 и шаблона:

Кнопка "Развернуть в Azure"

Note

Этот метод не поддерживает развертывание файлов Bicep пока.

Замените <url-encoded-path-to-azuredeploy-json> на URL-кодированную версию действительного пути вашего файла azuredeploy.json в GitHub.

Ниже приведен пример использования разметки:

[![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 Functions.

  • Last updated on