Автоматизация развертывания ресурсов приложения-функции для службы "Функции Azure"
Для автоматизации процесса развертывания приложения-функции можно использовать файл Bicep или шаблон Azure Resource Manager (ARM). Во время развертывания можно использовать существующие ресурсы Azure или создать новые. Автоматизация поможет вам в следующих сценариях:
- Интеграция развертываний ресурсов с исходным кодом в развертываниях Azure Pipelines и GitHub Actions.
- Восстановление приложения-функции и связанных ресурсов из резервной копии.
- Развертывание топологии приложения несколько раз.
В этой статье показано, как автоматизировать создание ресурсов и развертывание для Функции Azure. В зависимости от триггеров и привязок, используемых функциями, может потребоваться развернуть другие ресурсы, которые находятся вне области этой статьи.
Требуемый код шаблона зависит от требуемых параметров размещения приложения-функции. В этой статье поддерживаются следующие варианты размещения:
Вариант размещения | Тип развертывания | Дополнительные сведения см. в статье ... |
---|---|---|
План потребления службы "Функции Azure" | Только код | План потребления |
план потребления Функции Azure Flex | Только код | План потребления Flex |
план Функции Azure Elastic Premium | Код | Контейнер | План категории "Премиум" |
план выделенных Функции Azure (Служба приложений) | Код | Контейнер | План ценовой категории "Выделенный" |
Приложения контейнеров Azure | Только контейнер | Размещение приложений контейнеров Функции Azure |
Azure Arc | Код | Контейнер | Служба приложений, Функции и Logic Apps в Azure Arc (предварительная версия) |
При использовании этой статьи следует учитывать следующие аспекты:
Нет канонического способа структурировать шаблон ARM.
Развертывание Bicep можно модульизировать в несколько файлов Bicep.
В этой статье предполагается, что у вас есть базовое представление о создании файлов Bicep или создании шаблонов Azure Resource Manager.
- Примеры показаны в виде отдельных разделов для определенных ресурсов. Полный набор примеров шаблонов Bicep и ARM см . в следующих примерах развертывания приложения-функции.
- Примеры показаны в виде отдельных разделов для определенных ресурсов. Полный набор примеров шаблонов Bicep и ARM см . в следующих примерах развертывания приложения Flex Consumption.
- Примеры показаны в виде отдельных разделов для определенных ресурсов.
Необходимые ресурсы
Необходимо создать или настроить эти ресурсы для развертывания, размещенного в Функции Azure:
Ресурс | Требование | Справочник по синтаксису и свойствам |
---|---|---|
Учетная запись хранения | Обязательное поле | Microsoft.Storage/storageAccounts |
Компонент Application Insights | Рекомендуемая конфигурация | Microsoft.Insights/components* |
План размещения | Обязательное поле | Microsoft.Web/serverfarms |
Приложение-функция | Обязательное поле | Microsoft.Web/sites |
Необходимо создать или настроить эти ресурсы для развертывания, размещенного в Функции Azure:
Ресурс | Требование | Справочник по синтаксису и свойствам |
---|---|---|
Учетная запись хранения | Обязательное поле | Microsoft.Storage/storageAccounts |
Компонент Application Insights | Рекомендуемая конфигурация | Microsoft.Insights/components* |
Приложение-функция | Обязательное поле | Microsoft.Web/sites |
Развертывание, размещенное в контейнерных приложениях Azure, обычно состоит из следующих ресурсов:
Ресурс | Требование | Справочник по синтаксису и свойствам |
---|---|---|
Учетная запись хранения | Обязательное поле | Microsoft.Storage/storageAccounts |
Компонент Application Insights | Рекомендуемая конфигурация | Microsoft.Insights/components* |
Управляемая среда | Обязательное поле | Microsoft.App/managedEnvironments |
Приложение-функция | Обязательное поле | Microsoft.Web/sites |
Развертывание, размещенное в Azure Arc, обычно состоит из следующих ресурсов:
Ресурс | Требование | Справочник по синтаксису и свойствам |
---|---|---|
Учетная запись хранения | Обязательное поле | Microsoft.Storage/storageAccounts |
Компонент Application Insights | Рекомендуемая конфигурация | Microsoft.Insights/components1 |
Среда 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". Полный идентификатор ресурса рабочей области можно найти на странице рабочей области на странице портал Azure в разделе "Идентификатор ресурса свойств>параметров".>
- В этой статье предполагается, что вы уже создали управляемую среду в приложениях контейнеров Azure. Для создания приложения-функции, размещенного в контейнерных приложениях, необходимо имя и идентификатор управляемой среды.
- В этой статье предполагается, что вы уже создали пользовательское расположение с поддержкой Служба приложений в кластере Kubernetes с поддержкой Azure Arc. Для создания приложения-функции, размещенного в пользовательском расположении Azure Arc, необходимо как идентификатор пользовательского расположения, так и идентификатор среды Kubernetes.
Создание учетной записи хранения
Для всех приложений-функций требуется учетная запись хранения Azure. Необходима учетная запись общего назначения, поддерживающая большие двоичные объекты, таблицы, очереди и файлы. Дополнительные сведения см. в разделе Требования к учетной записи хранения.
Внимание
Учетная запись хранения используется для хранения важных данных приложения, иногда включая сам код приложения. Необходимо ограничить доступ от других приложений и пользователей к учетной записи хранения.
В этом примере создается учетная запись хранения уровня "Стандартный" версии 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
}
}
Дополнительные сведения см. в полном файле main.bicep в репозитории шаблонов.
Дополнительные сведения см. в полном файле storage-account.bicep в примере репозитория.
Необходимо задать строка подключения этой учетной записи хранения в качестве AzureWebJobsStorage
параметра приложения, для которого требуются функции. Шаблоны, приведенные в этой статье, создают это значение строка подключения на основе созданной учетной записи хранения, которая рекомендуется. Дополнительные сведения см. в разделе "Конфигурация приложения".
Контейнер развертывания
Для развертываний в приложении, работающем в плане потребления Flex, требуется контейнер в Хранилище BLOB-объектов Azure в качестве источника развертывания. Вы можете использовать учетную запись хранения по умолчанию или указать отдельную учетную запись хранения. Дополнительные сведения см. в разделе "Настройка параметров развертывания".
Эта учетная запись развертывания уже должна быть настроена при создании приложения, включая конкретный контейнер, используемый для развертываний. Дополнительные сведения о настройке развертываний см. в статье "Источники развертывания".
В этом примере показано, как создать контейнер в учетной записи хранения:
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. В этом примере в myLogAnalytics
качестве назначения для этих журналов используется рабочая область Log Analytics.
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 плана потребления Flex, плана Premium или выделенного плана (Служба приложений), должны иметь явно определенный план размещения.
Flex Consumption — это план размещения на основе Linux, который основан на использовании модели выставления счетов без сервера. Функции плана поддерживают частные сети, выбор размера памяти экземпляра и улучшенную поддержку управляемого удостоверения.
План потребления Flex — это особый serverfarm
тип ресурса. Его можно указать с помощью FC1
Name
значения свойства в свойстве sku
со значением tier
FlexConsumption
.
В этом примере создается план потребления Flex:
resource flexFuncPlan 'Microsoft.Web/serverfarms@2023-12-01' = {
name: planName
location: location
tags: tags
kind: 'functionapp'
sku: {
tier: 'FlexConsumption'
name: 'FC1'
}
properties: {
reserved: true
}
}
Дополнительные сведения см. в полном файле function.bicep в примере репозитория плана потребления Flex.
Так как план потребления Flex в настоящее время поддерживает только Linux, необходимо также задать reserved
для true
свойства значение .
План "Премиум" предлагает такие же возможности масштабирования, как и план потребления, предоставляя выделенные ресурсы и дополнительные возможности. См. статью План "Премиум" Функций Azure.
План "Премиум" — это специальный тип ресурса serverfarm
. Его можно указать с помощью EP1
, EP2
либо EP3
для Name
значения свойства в свойстве sku
. Способ определения плана размещения функций зависит от того, работает ли приложение-функция в Windows или Linux. В этом примере показано, как EP1
создать план:
resource hostingPlan 'Microsoft.Web/serverfarms@2022-03-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 см. на странице Provision a function app running on an App Service Plan (Приложение-функция в плане Службы приложений Azure).
В Функциях выделенный план — это просто обычный план Службы приложений, который определяется ресурсом serverfarm
. Необходимо указать по крайней name
мере значение. Список поддерживаемых имен планов см --sku
. в az appservice plan create
параметре текущего списка поддерживаемых значений для выделенного плана.
Способ определения плана размещения зависит от того, работает ли ваше приложение-функция в Windows или Linux:
resource hostingPlanName 'Microsoft.Web/serverfarms@2022-03-01' = {
name: hostingPlanName
location: location
sku: {
tier: 'Standard'
name: 'S1'
size: 'S1'
family: 'S'
capacity: 1
}
}
Дополнительные сведения см. в полном файле main.bicep в репозитории шаблонов.
Создание плана размещения
Вам не нужно явно определять ресурс плана размещения потребления. При пропуске этого определения ресурса план автоматически создается или выбирается на основе каждого региона при создании самого ресурса приложения-функции.
Вы можете явно определить план потребления в качестве специального serverfarm
типа ресурса, который вы указываете, используя значение Dynamic
для computeMode
свойств и sku
свойств. В этом примере показано, как явно определить план потребления. Способ определения плана размещения зависит от того, работает ли ваше приложение-функция в Windows или Linux.
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'
}
}
Дополнительные сведения см. в полном файле main.bicep в репозитории шаблонов.
Среда Kubernetes
Функции Azure можно развернуть в Kubernetes с поддержкой Azure Arc либо как проект кода, либо контейнерное приложение-функцию.
Чтобы создать приложение и ресурс плана, у вас должна быть созданная среда Kubernetes для Службы приложений с кластером Kubernetes с поддержкой Azure Arc. В примерах в этой статье предполагается, что у вас есть идентификатор ресурса настраиваемого расположения (customLocationId
) и Служба приложений среде 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
поле должно быть, и reserved
свойство должно бытьlinux,kubernetes
true
, так как это развертывание 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/sites
и kind
включает functionapp
как минимум.
Способ определения ресурса приложения-функции зависит от того, размещается ли вы в Linux или в Windows:
Список параметров приложения, необходимых при запуске в Windows, см. в разделе "Конфигурация приложения". Пример шаблона Bicep-файла или Azure Resource Manager см . в приложении-функции, размещенном в Windows в шаблоне плана потребления.
Список параметров приложения, необходимых при запуске в Windows, см. в разделе "Конфигурация приложения".
Flex Consumption заменяет многие стандартные параметры приложения и свойства конфигурации сайта, используемые в развертываниях шаблонов Bicep и ARM. Дополнительные сведения см. в разделе "Конфигурация приложения".
resource flexFuncApp 'Microsoft.Web/sites@2023-12-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.
Примечание.
Если вы решили дополнительно определить план потребления, необходимо задать serverFarmId
свойство в приложении таким образом, чтобы он указывает на идентификатор ресурса плана. Убедитесь, что приложение-функция имеет dependsOn
параметр, который также ссылается на план. Если вы явно не определили план, он создается для вас.
serverFarmId
Задайте свойство в приложении таким образом, чтобы он указывает на идентификатор ресурса плана. Убедитесь, что приложение-функция имеет dependsOn
параметр, который также ссылается на план.
resource functionAppName_resource 'Microsoft.Web/sites@2022-03-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: '~14'
}
]
}
}
}
Полный пример см. в этом файле main.bicep.
resource functionApp 'Microsoft.Web/sites@2022-03-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: '~14'
}
]
}
}
}
Полный пример см. в этом файле main.bicep.
Источники развертывания
Вы можете использовать linuxFxVersion
параметр сайта, чтобы запросить развертывание определенного контейнера Linux в приложении при его создании. Для доступа к изображениям в частном репозитории требуются дополнительные параметры. Дополнительные сведения см. в разделе "Конфигурация приложения".
Внимание
При создании собственных контейнеров необходимо сохранить базовый образ контейнера обновленным до последнего поддерживаемого базового образа. Поддерживаемые базовые образы для Функции Azure относятся к языку и находятся в репозитории базовых образов Функции Azure.
Команда функций привержена публикации ежемесячных обновлений для этих базовых образов. Регулярные обновления включают последние незначительные обновления версий и исправления безопасности для среды выполнения функций и языков. Необходимо регулярно обновлять контейнер из последнего базового образа и повторно развертывать обновленную версию контейнера.
Файл Bicep или шаблон ARM также может определить развертывание для кода функции, которое может включать следующие методы:
План потребления Flex поддерживает код проекта в zip-сжатый файл пакета в контейнере хранилища 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 использует одно развертывание для развертывания проекта кода. Сам пакет кода совпадает с тем же, что и для развертывания 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 для Функции Azure. При использовании автоматизации развертывания ресурсов можно ссылаться на пакет развертывания .zip в шаблоне Bicep или ARM.
Чтобы использовать zip-развертывание в шаблоне, задайте WEBSITE_RUN_FROM_PACKAGE
параметр в приложении 1
и включите /zipDeploy
определение ресурса.
Для плана потребления в Linux вместо этого задайте универсальный код ресурса (URI) пакета развертывания непосредственно в параметре WEBSITE_RUN_FROM_PACKAGE
, как показано в этом примере шаблона.
В этом примере в существующее приложение добавляется источник 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@2021-02-01' = {
name: '${functionAppName}/ZipDeploy'
location: location
properties: {
packageUri: packageUri
}
}
При включении ресурсов zip-развертывания в шаблон следует учитывать следующие моменты:
- Планы потребления в Linux не поддерживаются
WEBSITE_RUN_FROM_PACKAGE = 1
. Вместо этого необходимо задать универсальный код ресурса (URI) пакета развертывания непосредственно в параметреWEBSITE_RUN_FROM_PACKAGE
. Дополнительные сведения см. в WEBSITE_RUN_FROM_PACKAGE. Пример шаблона см. в разделе "Приложение-функция", размещенное в Linux в плане потребления.
Это
packageUri
должно быть расположение, к которому можно получить доступ с помощью Функций. Рекомендуется использовать хранилище BLOB-объектов Azure с подписанным URL-адресом (SAS). После истечения срока действия SAS функции больше не смогут получить доступ к общей папке для развертываний. При повторном создании SAS не забудьте обновитьWEBSITE_RUN_FROM_PACKAGE
параметр с новым значением URI.При настройке
WEBSITE_RUN_FROM_PACKAGE
URI необходимо вручную синхронизировать триггеры.Всегда устанавливайте все необходимые параметры приложения в
appSettings
коллекции при добавлении или обновлении параметров. Существующие параметры, не заданные явным образом, удаляются обновлением. Дополнительные сведения см. в разделе "Конфигурация приложения".Функции не поддерживают веб-развертывание (msdeploy) для развертываний пакетов. Вместо этого необходимо использовать zip-развертывание в конвейерах развертывания и автоматизации. Дополнительные сведения см. в статье о развертывании Zip для Функции Azure.
Удаленные сборки
В процессе развертывания предполагается, что используемый вами файл .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 ценовой категории "Премиум" или "Выделенный", необходимо:
linuxFxVersion
Задайте параметр сайта с идентификатором образа контейнера.- Задайте все необходимые
DOCKER_REGISTRY_SERVER_*
параметры при получении контейнера из частного реестра. - Задайте
WEBSITES_ENABLE_APP_SERVICE_STORAGE
для параметра приложения значениеfalse
.
Если отсутствуют некоторые параметры, подготовка приложений может завершиться ошибкой 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 шаблон должен:
kind
Задайте для поля значениеfunctionapp,linux,container,azurecontainerapps
.- Задайте свойству
managedEnvironmentId
сайта полный универсальный код ресурса (URI) среды "Приложения контейнеров". - Добавьте ссылку на ресурсы в коллекцию сайта
dependsOn
при созданииMicrosoft.App/managedEnvironments
ресурса одновременно с сайтом.
Определение контейнерного приложения-функции, развернутого из частного реестра контейнеров в существующей среде приложений контейнеров, может выглядеть следующим образом:
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 вы настраиваете приложение-функцию в 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 также поддерживает следующие параметры приложения:
- Параметры на основе строки подключения:
- Параметры на основе управляемых удостоверений:
Функции предоставляют следующие параметры настройки приложения-функции в Azure:
Настройка | Свойство 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. Количество доступных слотов зависит от плана размещения. Дополнительные сведения см. в разделе Функции Azure функции слотов развертывания.
Ресурс слота определяется так же, как ресурс приложения-функции (Microsoft.Web/sites
), но вместо этого используется Microsoft.Web/sites/slots
идентификатор ресурса. Пример развертывания (в шаблонах Bicep и ARM), создающих рабочий и промежуточный слот в плане Premium, см . в приложении-функции Azure с слотом развертывания.
Сведения о том, как переключать слоты с помощью шаблонов, см. в статье "Автоматизация с помощью шаблонов Resource Manager".
При работе с развертываниями слотов следует учитывать следующие рекомендации.
Не устанавливайте
WEBSITE_CONTENTSHARE
явно параметр в определении слота развертывания. Этот параметр создается автоматически при создании приложения в слоте развертывания.При переключении слотов некоторые параметры приложения считаются "липкими", в том, что они остаются с слотом, а не с кодом, который переключается. Вы можете определить такой параметр слота, включив
"slotSetting":true
в определение конкретного параметра приложения в шаблоне. Дополнительные сведения см. в разделе "Управление параметрами".
Защищенные развертывания
Вы можете создать приложение-функцию в развертывании, где один или несколько ресурсов были защищены, интегрируя с виртуальными сетями. Интеграция виртуальной сети для приложения-функции определяется ресурсом Microsoft.Web/sites/networkConfig
. Эта интеграция зависит от указанных приложений-функций и ресурсов виртуальной сети. Приложение-функция может также зависеть от других ресурсов частной сети, таких как частные конечные точки и маршруты. Дополнительные сведения см. в статье Возможности работы с сетью в Функциях Azure.
Эти проекты предоставляют примеры развертывания приложений-функций в виртуальной сети на основе Bicep, включая ограничения доступа к сети:
- Высокомасштабная функция HTTP,активируемая http, подключается к концентратору событий, защищенному виртуальной сетью: активируемая http-функция (изолированный рабочий режим .NET) принимает вызовы из любого источника, а затем отправляет текст этих HTTP-вызовов в защищенный концентратор событий, работающий в виртуальной сети с помощью интеграции виртуальной сети.
- Функция активируется служебная шина очередью, защищенной в виртуальной сети: функция Python активируется служебная шина очередью, защищенной в виртуальной сети. Очередь обращается к виртуальной сети с помощью частной конечной точки. Виртуальная машина в виртуальной сети используется для отправки сообщений.
При создании развертывания, использующего безопасную учетную запись хранения, необходимо явно задать WEBSITE_CONTENTSHARE
параметр и создать ресурс общей папки с именем этого параметра. Убедитесь, что вы создаете Microsoft.Storage/storageAccounts/fileServices/shares
ресурс с помощью значения WEBSITE_CONTENTSHARE
, как показано в этом примере (файл Bicep шаблона|ARM). Кроме того, необходимо задать для свойства vnetContentShareEnabled
сайта значение true.
Примечание.
Если эти параметры не являются частью развертывания, использующего защищенную учетную запись хранения, вы увидите эту ошибку во время проверки развертывания: Could not access storage account using provided connection string
Эти проекты предоставляют примеры шаблонов Bicep и ARM о том, как развертывать приложения-функции в виртуальной сети, в том числе с ограничениями доступа к сети:
Ограниченный сценарий | 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
, функции автоматически создают новый ключ при создании ресурса, который рекомендуется. Дополнительные сведения о ключах доступа, включая рекомендации по обеспечению безопасности для работы с ключами доступа, см. в статье "Работа с ключами доступа" в Функции Azure.
Создание шаблона
Эксперты с шаблонами Bicep или ARM могут вручную закодирует развертывания с помощью простого текстового редактора. Для остальных нас существует несколько способов упростить процесс разработки:
Visual Studio Code: доступны расширения, которые помогут вам работать как с файлами Bicep, так и с шаблонами ARM. Вы можете использовать эти средства, чтобы убедиться, что ваш код правильный, и они предоставляют некоторую базовую проверку.
портал 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":""}}]}}
Для проверки шаблона перед развертыванием можно использовать следующие методы:
Следующая задача deploymentMode: 'Validation'
развертывания группы ресурсов 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"
Примечание.
Этот метод сейчас не поддерживает развертывание файлов Bicep.
Замените <url-encoded-path-to-azuredeploy-json>
версией необработанного пути к файлу azuredeploy.json
на сайте GitHub, указав его в формате URL-адреса.
Ниже приведен пример использования разметки:
[![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: