Partilhar via

Automatize a implantação de recursos para seu aplicativo de função no Azure Functions

  • Artigo

Você pode usar um arquivo Bicep ou um modelo do Azure Resource Manager (ARM) para automatizar o processo de implantação de seu aplicativo de função. Durante a implantação, você pode usar recursos existentes do Azure ou criar novos. A automação ajuda você com estes cenários:

  • Integrando suas implantações de recursos com seu código-fonte em implantações baseadas em Pipelines do Azure e GitHub Actions.
  • Restaurando um aplicativo de função e recursos relacionados a partir de um backup.
  • Implantando uma topologia de aplicativo várias vezes.

Este artigo mostra como automatizar a criação de recursos e a implantação do Azure Functions. Dependendo dos gatilhos e associações usados por suas funções, talvez seja necessário implantar outros recursos, o que está fora do escopo deste artigo.

O código de modelo necessário depende das opções de hospedagem desejadas para seu aplicativo de função. Este artigo suporta as seguintes opções de hospedagem:

Opção de hospedagem Tipo de implementação Para saber mais, consulte...
Plano de consumo do Azure Functions Apenas código Plano de consumo
Plano de consumo do Azure Functions Flex Apenas código Plano de consumo Flex
Plano Azure Functions Elastic Premium Código | Contentor Plano Premium
Plano Dedicado do Azure Functions (Serviço de Aplicativo) Código | Contentor Plano dedicado
Aplicativos de contêiner do Azure Apenas contentores Aplicativos de contêiner que hospedam o Azure Functions
Azure Arc Código | Contentor Serviço de Aplicativo, Funções e Aplicativos Lógicos no Azure Arc (Visualização)

Ao usar este artigo, tenha estas considerações em mente:

  • Não há uma maneira canônica de estruturar um modelo ARM.

  • Uma implantação do Bicep pode ser modularizada em vários arquivos Bicep.

  • Este artigo pressupõe que você tenha uma compreensão básica da criação de arquivos Bicep ou da criação de modelos do Azure Resource Manager.

  • Os exemplos são mostrados como seções individuais para recursos específicos. Para obter um amplo conjunto de exemplos completos de arquivo Bicep e modelo ARM, consulte estes exemplos de implantação de aplicativo de função.
  • Os exemplos são mostrados como seções individuais para recursos específicos. Para obter um amplo conjunto de exemplos completos de arquivo Bicep e modelo ARM, consulte estes exemplos de implantação do aplicativo Flex Consumption.
  • Os exemplos são mostrados como seções individuais para recursos específicos.

Recursos necessários

Você deve criar ou configurar estes recursos para uma implantação hospedada pelo Azure Functions:

Recurso Necessidade Sintaxe e referência de propriedades
Uma conta de armazenamento Necessário Microsoft.Storage/storageContas
Um componente do Application Insights Recomendado Microsoft.Insights/componentes*
Um plano de hospedagem Necessário Microsoft.Web/serverfarms
Um aplicativo de função Necessário Microsoft.Web/sites

Você deve criar ou configurar estes recursos para uma implantação hospedada pelo Azure Functions:

Recurso Necessidade Sintaxe e referência de propriedades
Uma conta de armazenamento Necessário Microsoft.Storage/storageContas
Um componente do Application Insights Recomendado Microsoft.Insights/componentes*
Um aplicativo de função Necessário Microsoft.Web/sites

Uma implantação hospedada em Aplicativos de Contêiner do Azure geralmente consiste nestes recursos:

Recurso Necessidade Sintaxe e referência de propriedades
Uma conta de armazenamento Necessário Microsoft.Storage/storageContas
Um componente do Application Insights Recomendado Microsoft.Insights/componentes*
Um ambiente gerenciado Necessário Microsoft.App/managedEnvironments
Um aplicativo de função Necessário Microsoft.Web/sites

Uma implantação hospedada pelo Azure Arc normalmente consiste nestes recursos:

Recurso Necessidade Sintaxe e referência de propriedades
Uma conta de armazenamento Necessário Microsoft.Storage/storageContas
Um componente do Application Insights Recomendado Microsoft.Insights/componentes1
Um ambiente Kubernetes do Serviço de Aplicativo Necessário Microsoft.ExtendedLocation/customLocations
Um aplicativo de função Necessário Microsoft.Web/sites

*Se você ainda não tiver um espaço de trabalho do Log Analytics que possa ser usado pela instância do Application Insights, também precisará criar esse recurso.

Quando você implanta vários recursos em um único arquivo Bicep ou modelo ARM, a ordem na qual os recursos são criados é importante. Este requisito é resultado de dependências entre recursos. Para essas dependências, certifique-se de usar o dependsOn elemento para definir a dependência no recurso dependente. Para obter mais informações, consulte Definir a ordem de implantação de recursos em modelos ARM ou Dependências de recursos no Bicep.

Pré-requisitos

  • Os exemplos são projetados para serem executados no contexto de um grupo de recursos existente.
  • Tanto o Application Insights quanto os logs de armazenamento exigem que você tenha um espaço de trabalho existente do Azure Log Analytics. Os espaços de trabalho podem ser compartilhados entre serviços e, como regra geral, você deve criar um espaço de trabalho em cada região geográfica para melhorar o desempenho. Para obter um exemplo de como criar um espaço de trabalho do Log Analytics, consulte Criar um espaço de trabalho do Log Analytics. Você pode encontrar a ID de recurso de espaço de trabalho totalmente qualificada em uma página de espaço de trabalho no portal do Azure em Propriedades de Configurações>>ID do Recurso.
  • Este artigo pressupõe que você já tenha criado um ambiente gerenciado nos Aplicativos de Contêiner do Azure. Você precisa do nome e da ID do ambiente gerenciado para criar um aplicativo funcional hospedado em Aplicativos de Contêiner.
  • Este artigo pressupõe que você já tenha criado um local personalizado habilitado para o Serviço de Aplicativo em um cluster Kubernetes habilitado para Azure Arc. Você precisa da ID de local personalizada e da ID de ambiente do Kubernetes para criar um aplicativo de função hospedado em um local personalizado do Azure Arc.

Criar conta de armazenamento

Todos os aplicativos de função exigem uma conta de armazenamento do Azure. Você precisa de uma conta de uso geral que ofereça suporte a blobs, tabelas, filas e arquivos. Para obter mais informações, consulte Requisitos da conta de armazenamento do Azure Functions.

Importante

A conta de armazenamento é usada para armazenar dados importantes do aplicativo, às vezes incluindo o próprio código do aplicativo. Você deve limitar o acesso de outros aplicativos e usuários à conta de armazenamento.

Esta seção de exemplo cria uma conta de armazenamento padrão de uso geral v2:

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

Para obter mais contexto, consulte o arquivo main.bicep completo no repositório de modelos.

Para obter mais contexto, consulte o arquivo storage-account.bicep completo no repositório de exemplo.

Você precisa definir a cadeia de conexão dessa conta de armazenamento como a configuração do aplicativo, que o AzureWebJobsStorage Functions exige. Os modelos neste artigo constroem esse valor de cadeia de conexão com base na conta de armazenamento criada, que é uma prática recomendada. Para obter mais informações, consulte Configuração do aplicativo.

Contêiner de implantação

As implantações em um aplicativo em execução no plano Flex Consumption exigem um contêiner no Armazenamento de Blobs do Azure como a fonte de implantação. Você pode usar a conta de armazenamento padrão ou especificar uma conta de armazenamento separada. Para obter mais informações, consulte Definir configurações de implantação.

Essa conta de implantação já deve estar configurada quando você cria seu aplicativo, incluindo o contêiner específico usado para implantações. Para saber mais sobre como configurar implantações, consulte Fontes de implantação.

Este exemplo mostra como criar um contêiner na conta de armazenamento:

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'
    }
  }]
}

Para o trecho no contexto, consulte este exemplo de implantação.

Outras configurações de implantação são definidas com o próprio aplicativo.

Habilitar logs de armazenamento

Como a conta de armazenamento é usada para dados importantes do aplicativo de função, você deve monitorar a conta para a modificação desse conteúdo. Para monitorar sua conta de armazenamento, você precisa configurar os logs de recursos do Azure Monitor para o Armazenamento do Azure. Nesta seção de exemplo, um espaço de trabalho do Log Analytics chamado myLogAnalytics é usado como destino para esses logs.

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
      }
    ]
  }
}

Esse mesmo espaço de trabalho pode ser usado para o recurso do Application Insights definido posteriormente. Para obter mais informações, incluindo como trabalhar com esses logs, consulte Monitorando o Armazenamento do Azure.

Criar insights de aplicativos

Você deve usar o Application Insights para monitorar as execuções do aplicativo de função. O Application Insights agora requer um espaço de trabalho do Azure Log Analytics, que pode ser compartilhado. Estes exemplos pressupõem que você esteja usando um espaço de trabalho existente e tenha a ID de recurso totalmente qualificada para o espaço de trabalho. Para obter mais informações, consulte Espaço de trabalho do Azure Log Analytics.

Nesta seção de exemplo, o recurso do Application Insights é definido com o tipo Microsoft.Insights/components e o tipo 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>'
  }
}

Para obter mais contexto, consulte o arquivo main.bicep completo no repositório de modelos.

A conexão deve ser fornecida ao aplicativo de função usando a configuração do APPLICATIONINSIGHTS_CONNECTION_STRING aplicativo. Para obter mais informações, consulte Configuração do aplicativo.

Os exemplos neste artigo obtêm o valor da cadeia de conexão para a instância criada. Em vez disso, versões mais antigas podem ser usadas APPINSIGHTS_INSTRUMENTATIONKEY para definir a chave de instrumentação, o que não é mais recomendado.

Criar o plano de hospedagem

Os aplicativos hospedados em um plano Azure Functions Flex Consumption, plano Premium ou plano Dedicado (Serviço de Aplicativo) devem ter o plano de hospedagem explicitamente definido.

O Flex Consumption é um plano de hospedagem baseado em Linux que se baseia no modelo de pagamento de consumo pelo que você usa sem servidor. O plano oferece suporte para redes privadas, seleção de tamanho de memória de instância e suporte aprimorado a identidades gerenciadas.

Um plano Flex Consumption é um tipo especial de serverfarm recurso. Você pode especificá-lo usando FC1 para o valor da Name propriedade na sku propriedade com um tier valor de FlexConsumption.

Esta seção de exemplo cria o plano Flex Consumption:

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

Para obter mais contexto, consulte o arquivo function.bicep completo no repositório de exemplo do plano Flex Consumption.

Como o plano Flex Consumption atualmente só suporta Linux, você também deve definir a reserved propriedade como true.

O plano Premium oferece o mesmo escalonamento que o plano de Consumo, mas inclui recursos dedicados e recursos extras. Para saber mais, consulte Plano Premium do Azure Functions.

Um plano Premium é um tipo especial de serverfarm recurso. Você pode especificá-lo usando EP1, EP2ou EP3 para o valor da Name propriedade na sku propriedade. A maneira como você define o plano de hospedagem do Functions depende se seu aplicativo de função é executado no Windows ou no Linux. Esta seção de exemplo cria um EP1 plano:

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

Para obter mais contexto, consulte o arquivo main.bicep completo no repositório de modelos.

Para obter mais informações sobre o sku objeto, consulte SkuDefinition ou revise os modelos de exemplo.

No plano Dedicado (Serviço de Aplicativo), seu aplicativo de função é executado em VMs dedicadas em SKUs Básicas, Padrão e Premium nos planos do Serviço de Aplicativo, semelhantes aos aplicativos Web. Para obter mais informações, consulte Plano dedicado.

Para obter um exemplo de arquivo Bicep/modelo do Azure Resource Manager, consulte Aplicativo de função no plano do Serviço de Aplicativo do Azure.

Em Funções, o plano Dedicado é apenas um plano regular do Serviço de Aplicativo, que é definido por um serverfarm recurso. Você deve fornecer pelo menos o name valor. Para obter uma lista de nomes de planos suportados, consulte a --sku configuração na az appservice plan create lista atual de valores suportados para um plano dedicado.

A maneira como você define o plano de hospedagem depende se seu aplicativo de função é executado no Windows ou no Linux:

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

Para obter mais contexto, consulte o arquivo main.bicep completo no repositório de modelos.

Criar o plano de hospedagem

Você não precisa definir explicitamente um recurso de plano de hospedagem de consumo. Quando você ignora essa definição de recurso, um plano é automaticamente criado ou selecionado por região quando você cria o próprio recurso de aplicativo de função.

Você pode definir explicitamente um plano de consumo como um tipo especial de serverfarm recurso, que você especifica usando o valor Dynamic para as computeMode propriedades e sku . Esta seção de exemplo mostra como definir explicitamente um plano de consumo. A maneira como você define um plano de hospedagem depende se seu aplicativo de função é executado no Windows ou no 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'
  }
}

Para obter mais contexto, consulte o arquivo main.bicep completo no repositório de modelos.

Ambiente Kubernetes

O Azure Functions pode ser implantado no Kubernetes habilitado para Azure Arc como um projeto de código ou um aplicativo de função conteinerizado.

Para criar o aplicativo e planejar recursos, você já deve ter criado um ambiente Kubernetes do Serviço de Aplicativo para um cluster Kubernetes habilitado para Azure Arc. Os exemplos neste artigo pressupõem que você tenha a ID do recurso do local personalizado (customLocationId) e do ambiente Kubernetes do Serviço de Aplicativo (kubeEnvironmentId) no qual está implantando, que são definidos neste exemplo:

param kubeEnvironmentId string
param customLocationId string

Ambos os sites e planos devem fazer referência ao local personalizado por meio de um extendedLocation campo. Como mostrado neste exemplo truncado, extendedLocation fica fora de properties, como um par para kind e location:

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

O recurso de plano deve usar o valor Kubernetes (K1) para SKU, o kind campo deve ser linux,kubernetes, e a reserved propriedade deve ser true, já que é uma implantação do Linux. Você também deve definir o extendedLocation e kubeEnvironmentProfile.id para o ID de local personalizado e o ID de ambiente do Kubernetes, respectivamente, que podem se parecer com esta seção de exemplo:

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
  }
}

Criar a aplicação de funções

O recurso de aplicativo de função é definido por um recurso do tipo Microsoft.Web/sites e kind que inclui functionapp, no mínimo.

A maneira como você define um recurso de aplicativo de função depende se você está hospedando no Linux ou no Windows:

Para obter uma lista das configurações de aplicativos necessárias durante a execução no Windows, consulte Configuração de aplicativos. Para obter um exemplo de arquivo Bicep/modelo do Azure Resource Manager, consulte o aplicativo de função hospedado no Windows em um modelo de plano de consumo .

Para obter uma lista das configurações de aplicativos necessárias durante a execução no Windows, consulte Configuração de aplicativos.

O Flex Consumption substitui muitas das configurações padrão do aplicativo e das propriedades de configuração do site usadas nas implantações de modelos Bicep e ARM. Para obter mais informações, consulte Configuração do aplicativo.

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
      }
    }
  }
}

Para obter mais contexto, consulte o arquivo function.bicep completo no repositório de exemplo do plano Flex Consumption.

Nota

Se você optar por definir opcionalmente seu plano de Consumo, deverá definir a serverFarmId propriedade no aplicativo para que ela aponte para a ID do recurso do plano. Verifique se o aplicativo de função tem uma dependsOn configuração que também faz referência ao plano. Se você não definiu explicitamente um plano, um será criado para você.

Defina a serverFarmId propriedade no aplicativo para que ela aponte para a ID do recurso do plano. Verifique se o aplicativo de função tem uma dependsOn configuração que também faz referência ao plano.

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'
        }
      ]
    }
  }
}

Para obter um exemplo completo de ponta a ponta, consulte este arquivo 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'
        }
      ]
    }
  }
}

Para obter um exemplo completo de ponta a ponta, consulte este arquivo main.bicep.

Fontes de implantação

Você pode usar a configuração do linuxFxVersion site para solicitar que um contêiner Linux específico seja implantado em seu aplicativo quando ele for criado. Mais configurações são necessárias para acessar imagens em um repositório privado. Para obter mais informações, consulte Configuração do aplicativo.

Importante

Ao criar seus próprios contêineres, é necessário manter a imagem base do contêiner atualizada para a imagem base suportada mais recente. As imagens de base com suporte para o Azure Functions são específicas do idioma e são encontradas nos repositórios de imagem base do Azure Functions.

A equipa do Functions está empenhada em publicar atualizações mensais para estas imagens base. As atualizações regulares incluem as últimas atualizações de versões secundárias e correções de segurança para o tempo de execução e os idiomas do Functions. Você deve atualizar regularmente seu contêiner a partir da imagem base mais recente e reimplantar a versão atualizada do contêiner.

Seu arquivo Bicep ou modelo ARM pode, opcionalmente, também definir uma implantação para seu código de função, que pode incluir estes métodos:

O plano Flex Consumption mantém o código do projeto no arquivo de pacote compactado zip em um contêiner de armazenamento de blob conhecido como contêiner de implantação. Você pode configurar a conta de armazenamento e o contêiner usados para implantação. Para mais informações, consulte Implementação.

Você deve usar uma implantação para publicar seu pacote de código no contêiner de implantação. Durante uma implantação de ARM ou Bicep, você pode fazer isso definindo uma fonte de pacote que usa a /onedeploy extensão. Se, em vez disso, você optar por carregar diretamente o pacote para o contêiner, o pacote não será implantado automaticamente.

Contêiner de implantação

A conta de armazenamento específica e o contêiner usados para implantações, o método de autenticação e as functionAppConfig.deployment.storage credenciais são definidos no elemento do properties para o site. O contêiner e todas as configurações do aplicativo devem existir quando o aplicativo é criado. Para obter um exemplo de como criar o contêiner de armazenamento, consulte Contêiner de implantação.

Este exemplo usa uma identidade gerenciada atribuída ao sistema para acessar o contêiner de armazenamento de blob especificado, que é criado em outro lugar na implantação:

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

Ao usar identidades gerenciadas, você também deve habilitar o aplicativo de função para acessar a conta de armazenamento usando a identidade, conforme mostrado neste exemplo:

// 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'
  }
}

Para obter um exemplo de referência completo, consulte este arquivo Bicep.

Este exemplo requer que você saiba o valor GUID para a função que está sendo atribuída. Você pode obter esse valor de ID para qualquer nome de função amigável usando o comando az role definition list , como neste exemplo:

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

Ao usar uma cadeia de conexão em vez de identidades gerenciadas, você precisa definir como authentication.type StorageAccountConnectionString e definir authentication.storageAccountConnectionStringName como o nome da configuração do aplicativo que contém a cadeia de conexão da conta de armazenamento de implantação.

Pacote de implantação

O plano Flex Consumption usa uma implantação para implantar seu projeto de código. O pacote de código em si é o mesmo que você usaria para implantação zip em outros planos de hospedagem do Functions. No entanto, o nome do arquivo de pacote em si deve ser released-package.zip.

Para incluir um pacote de implantação em seu modelo, use a definição de /onedeploy recurso para a URL remota que contém o pacote de implantação. O host Functions deve ser capaz de acessar essa fonte de pacote remoto e o contêiner de implantação.

Este exemplo adiciona uma fonte de implantação única a um aplicativo existente:

@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 
  }
}

Seu arquivo Bicep ou modelo ARM pode, opcionalmente, também definir uma implantação para seu código de função usando um pacote de implantação zip.

Para implantar com êxito seu aplicativo usando o Gerenciador de Recursos do Azure, é importante entender como os recursos são implantados no Azure. Na maioria dos exemplos, as configurações de nível superior são aplicadas usando siteConfigo . É importante definir essas configurações em um nível superior, porque elas transmitem informações para o tempo de execução e o mecanismo de implantação do Functions. Informações de nível superior são necessárias antes que o recurso filho sourcecontrols/web seja aplicado. Embora seja possível definir essas configurações no recurso de nível config/appSettings filho, em alguns casos, seu aplicativo de função deve ser implantado antes config/appSettings de ser aplicado.

Pacote de implantação Zip

A implantação Zip é uma maneira recomendada de implantar o código do aplicativo de função. Por padrão, as funções que usam a implantação zip são executadas no próprio pacote de implantação. Para obter mais informações, incluindo os requisitos para um pacote de implantação, consulte Implantação Zip para o Azure Functions. Ao usar a automação de implantação de recursos, você pode fazer referência ao pacote de implantação .zip em seu modelo Bicep ou ARM.

Para usar a implantação zip em seu modelo, defina a WEBSITE_RUN_FROM_PACKAGE configuração no aplicativo como 1 e inclua a definição de /zipDeploy recurso.

Para um plano de consumo no Linux, defina o URI do pacote de implantação diretamente na WEBSITE_RUN_FROM_PACKAGE configuração, conforme mostrado neste modelo de exemplo.

Este exemplo adiciona uma fonte de implantação zip a um aplicativo existente:

@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
  }
}

Tenha em mente o seguinte ao incluir recursos de implantação zip em seu modelo:

  • O packageUri deve ser um local que possa ser acessado pelo Functions. Considere usar o armazenamento de blob do Azure com uma assinatura de acesso compartilhado (SAS). Depois que o SAS expira, o Functions não pode mais acessar o compartilhamento para implantações. Ao regenerar sua SAS, lembre-se de atualizar a WEBSITE_RUN_FROM_PACKAGE configuração com o novo valor de URI.

  • Ao definir WEBSITE_RUN_FROM_PACKAGE como um URI, você deve sincronizar manualmente os disparadores.

  • Certifique-se de sempre definir todas as configurações de aplicativo necessárias na appSettings coleção ao adicionar ou atualizar as configurações. As configurações existentes não definidas explicitamente são removidas pela atualização. Para obter mais informações, consulte Configuração do aplicativo.

  • O Functions não oferece suporte a implantação da Web (msdeploy) para implantações de pacotes. Em vez disso, você deve usar a implantação zip em seus pipelines de implantação e automação. Para obter mais informações, consulte Implantação Zip para Azure Functions.

Compilações remotas

O processo de implantação pressupõe que o arquivo .zip que você usa ou uma implantação zip contém um aplicativo pronto para executar. Isso significa que, por padrão, nenhuma personalização é executada.

Há cenários que exigem que você recrie seu aplicativo remotamente. Um exemplo é quando você precisa incluir pacotes específicos do Linux em Python ou Node.js aplicativos que você desenvolveu em um computador Windows. Nesse caso, você pode configurar o Functions para executar uma compilação remota em seu código após a implantação zip.

A maneira como você solicita uma compilação remota depende do sistema operacional no qual você está implantando:

Quando um aplicativo é implantado no Windows, comandos específicos do idioma (como dotnet restore para aplicativos C# ou npm install para aplicativos Node.js) são executados.

Para habilitar os mesmos processos de compilação que você obtém com a integração contínua, adicione SCM_DO_BUILD_DURING_DEPLOYMENT=true às configurações do aplicativo em seu código de implantação e remova completamente WEBSITE_RUN_FROM_PACKAGE .

Contentores do Linux

Se você estiver implantando um aplicativo de função em contêiner em um plano do Azure Functions Premium ou dedicado, deverá:

Se algumas configurações estiverem faltando, o provisionamento do aplicativo pode falhar com este erro HTTP/500:

Function app provisioning failed.

Para obter mais informações, consulte Configuração do aplicativo.

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
  ]
}

Ao implantar funções em contêineres nos Aplicativos de Contêiner do Azure, seu modelo deve:

  • Defina o kind campo como um valor de functionapp,linux,container,azurecontainerapps.
  • Defina a managedEnvironmentId propriedade site como o URI totalmente qualificado do ambiente Container Apps.
  • Adicione um link de recurso no conjunto de dependsOn sites ao criar um Microsoft.App/managedEnvironments recurso ao mesmo tempo que o site.

A definição de um aplicativo de função em contêiner implantado de um registro de contêiner privado para um ambiente de Aplicativos de Contêiner existente pode ser semelhante a este exemplo:

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
  ]
}

Ao implantar funções no Azure Arc, o valor definido para o kind campo do recurso de aplicativo de função depende do tipo de implantação:

Tipo de implementação kind valor do campo
Implantação somente de código functionapp,linux,kubernetes
Implementação em contentor functionapp,linux,kubernetes,container

Você também deve definir o customLocationId como fez para o recurso do plano de hospedagem.

A definição de um aplicativo de função em contêiner, usando uma imagem de início rápido do .NET 6, pode ser semelhante a este exemplo:

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
  ]
}

Configuração da aplicação

Em um plano Flex Consumption, você configura seu aplicativo de função no Azure com dois tipos de propriedades:

Configuração Microsoft.Web/sites propriedade
Configuração da aplicação functionAppConfig
Definições da aplicação siteConfig.appSettings Coleção

Essas configurações de aplicativo são mantidas em functionAppConfig:

Comportamento Ambientação em functionAppConfig
Instâncias sempre prontas scaleAndConcurrency.alwaysReady
Origem da implantação deployment
Tamanho da memória da instância scaleAndConcurrency.instanceMemoryMB
Simultaneidade de gatilho HTTP scaleAndConcurrency.triggers.http.perInstanceConcurrency
Tempo de execução da linguagem runtime.name
Versão linguística runtime.version
Contagem máxima de instâncias scaleAndConcurrency.maximumInstanceCount

O plano Flex Consumption também suporta estas configurações do aplicativo:

O Functions fornece as seguintes opções para configurar seu aplicativo de função no Azure:

Configuração Microsoft.Web/sites propriedade
Definições do site siteConfig
Definições da aplicação siteConfig.appSettings Coleção

Estas configurações do siteConfig site são necessárias na propriedade:

Essas configurações de site são necessárias somente ao usar identidades gerenciadas para obter a imagem de uma instância do Registro de Contêiner do Azure:

Estas configurações de aplicativo são necessárias (ou recomendadas) para um sistema operacional específico e opção de hospedagem:

Estas configurações de aplicativo são necessárias para implantações de contêiner:

Essas configurações só são necessárias ao implantar a partir de um registro de contêiner privado:

Tenha estas considerações em mente ao trabalhar com configurações de site e aplicativo usando arquivos Bicep ou modelos ARM:

  • A configuração opcional alwaysReady contém uma matriz de um ou mais {name,instanceCount} objetos, com um para cada grupo de escala por função. Estes são os grupos de escala que estão sendo usados para tomar decisões de escala sempre prontas. Este exemplo define contagens sempre prontas para o grupo e uma única função chamada helloworld, que é de um tipo de gatilho http não agrupado:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Há considerações importantes sobre quando você deve definir WEBSITE_CONTENTSHARE em uma implantação automatizada. Para obter orientações detalhadas, consulte a WEBSITE_CONTENTSHARE referência.

  • Você sempre deve definir as configurações do aplicativo como uma siteConfig/appSettings coleção do Microsoft.Web/sites recurso que está sendo criado, como é feito nos exemplos neste artigo. Essa definição garante que as configurações que seu aplicativo de função precisa executar estejam disponíveis na inicialização inicial.

  • Ao adicionar ou atualizar as configurações do aplicativo usando modelos, certifique-se de incluir todas as configurações existentes com a atualização. Você deve fazer isso porque as chamadas de API REST de atualização subjacentes substituem todo /config/appsettings o recurso. Se você remover as configurações existentes, seu aplicativo de função não será executado. Para atualizar programaticamente as configurações de aplicativos individuais, você pode usar a CLI do Azure, o Azure PowerShell ou o portal do Azure para fazer essas alterações. Para obter mais informações, consulte Trabalhar com configurações do aplicativo.

Implantações de slots

O Functions permite implantar diferentes versões do seu código em pontos de extremidade exclusivos em seu aplicativo de função. Essa opção facilita o desenvolvimento, a validação e a implantação de atualizações de funções sem afetar as funções em execução na produção. Os slots de implantação são um recurso do Serviço de Aplicativo do Azure. O número de slots disponíveis depende do seu plano de hospedagem. Para obter mais informações, consulte Funções de slots de implantação do Azure Functions.

Um recurso de slot é definido da mesma forma que um recurso de aplicativo de função (Microsoft.Web/sites), mas, em vez disso, você usa o identificador de Microsoft.Web/sites/slots recurso. Para obter um exemplo de implantação (nos modelos Bicep e ARM) que cria um slot de produção e de preparo em um plano Premium, consulte Aplicativo de função do Azure com um slot de implantação.

Para saber mais sobre como trocar slots usando modelos, consulte Automatizar com modelos do Resource Manager.

Tenha em mente as seguintes considerações ao trabalhar com implantações de slots:

  • Não defina explicitamente a WEBSITE_CONTENTSHARE configuração na definição de slot de implantação. Essa configuração é gerada para você quando o aplicativo é criado no slot de implantação.

  • Quando você troca slots, algumas configurações do aplicativo são consideradas "pegajosas", na medida em que ficam com o slot e não com o código que está sendo trocado. Você pode definir essa configuração de slot incluindo "slotSetting":true na definição específica do aplicativo em seu modelo. Para obter mais informações, consulte Gerenciar configurações.

Implantações seguras

Você pode criar seu aplicativo de função em uma implantação onde um ou mais dos recursos foram protegidos pela integração com redes virtuais. A integração de rede virtual para seu aplicativo de função é definida por um Microsoft.Web/sites/networkConfig recurso. Essa integração depende do aplicativo de função referenciado e dos recursos da rede virtual. Seu aplicativo de função também pode depender de outros recursos de rede privada, como pontos de extremidade e rotas particulares. Para obter mais informações, consulte Opções de rede do Azure Functions.

Esses projetos fornecem exemplos baseados no Bíceps de como implantar seus aplicativos de função em uma rede virtual, inclusive com restrições de acesso à rede:

Ao criar uma implantação que usa uma conta de armazenamento segura, você deve definir explicitamente a WEBSITE_CONTENTSHARE configuração e criar o recurso de compartilhamento de arquivos nomeado nessa configuração. Certifique-se de criar um Microsoft.Storage/storageAccounts/fileServices/shares recurso usando o valor de WEBSITE_CONTENTSHARE, conforme mostrado neste exemplo (arquivo Bicep de modelo|ARM). Você também precisará definir a propriedade vnetContentShareEnabled do site como true.

Nota

Quando essas configurações não fazem parte de uma implantação que usa uma conta de armazenamento segura, você vê este erro durante a validação da implantação: Could not access storage account using provided connection string.

Esses projetos fornecem exemplos de modelo Bicep e ARM de como implantar seus aplicativos de função em uma rede virtual, inclusive com restrições de acesso à rede:

Cenário restrito Description
Criar um aplicativo de função com integração de rede virtual Seu aplicativo de função é criado em uma rede virtual com acesso total aos recursos nessa rede. O acesso de entrada e saída ao seu aplicativo de função não é restrito. Para obter mais informações, consulte Integração de rede virtual.
Criar um aplicativo de função que acesse uma conta de armazenamento segura Seu aplicativo de função criado usa uma conta de armazenamento segura, que o Functions acessa usando pontos de extremidade privados. Para obter mais informações, veja Restringir a conta de armazenamento a uma rede virtual.
Crie um aplicativo de função e uma conta de armazenamento que usem pontos de extremidade privados Seu aplicativo de função criado só pode ser acessado usando pontos de extremidade privados e usa pontos de extremidade privados para acessar recursos de armazenamento. Para obter mais informações, consulte Pontos de extremidade privados.

Configurações de rede restritas

Você também pode precisar usar essas configurações quando seu aplicativo de função tiver restrições de rede:

Definição valor Description
WEBSITE_CONTENTOVERVNET 1 Configuração do aplicativo que permite que seu aplicativo de função seja dimensionado quando a conta de armazenamento está restrita a uma rede virtual. Para obter mais informações, veja Restringir a conta de armazenamento a uma rede virtual.
vnetrouteallenabled 1 Configuração do site que força todo o tráfego do aplicativo de função a usar a rede virtual. Para obter mais informações, consulte Integração de rede virtual regional. Esta configuração do site substitui a configuração WEBSITE_VNET_ROUTE_ALLdo aplicativo .

Considerações para restrições de rede

Quando você está restringindo o acesso à conta de armazenamento por meio dos pontos de extremidade privados, não é possível acessar a conta de armazenamento por meio do portal ou de qualquer dispositivo fora da rede virtual. Você pode conceder acesso ao seu endereço IP seguro ou rede virtual na conta de armazenamento gerenciando a regra de acesso à rede padrão.

Teclas de acesso à função

As chaves de acesso de função no nível do host são definidas como recursos do Azure. Isso significa que você pode criar e gerenciar chaves de host em seus modelos ARM e arquivos Bicep. Uma chave de host é definida como um recurso do tipo Microsoft.Web/sites/host/functionKeys. Este exemplo cria uma chave de acesso no nível do host nomeada my_custom_key quando o aplicativo de função é criado:

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'))
  ]
}

Neste exemplo, o name parâmetro é o nome do novo aplicativo de função. Você deve incluir uma dependsOn configuração para garantir que a chave seja criada com o novo aplicativo de função. Finalmente, o properties objeto da chave de host também pode incluir uma value propriedade que pode ser usada para definir uma chave específica.

Quando você não define a value propriedade, o Functions gera automaticamente uma nova chave para você quando o recurso é criado, o que é recomendado. Para saber mais sobre chaves de acesso, incluindo práticas recomendadas de segurança para trabalhar com chaves de acesso, consulte Trabalhar com chaves de acesso no Azure Functions.

Crie o seu modelo

Especialistas com modelos Bicep ou ARM podem codificar manualmente suas implantações usando um editor de texto simples. Para o resto de nós, existem várias maneiras de tornar o processo de desenvolvimento mais fácil:

  • Visual Studio Code: Há extensões disponíveis para ajudá-lo a trabalhar com arquivos Bicep e modelos ARM. Você pode usar essas ferramentas para ajudar a garantir que seu código esteja correto e elas fornecem alguma validação básica.

  • Portal do Azure: quando você cria seu aplicativo de função e recursos relacionados no portal, a tela final Revisão + criação tem um link Baixar um modelo para automação .

    Baixe o link de modelo do processo de criação do Azure Functions no portal do Azure.

    Este link mostra o modelo ARM gerado com base nas opções que você escolheu no portal. Este modelo pode parecer um pouco complexo quando você está criando um aplicativo de função com muitos recursos novos. No entanto, ele pode fornecer uma boa referência para a aparência do seu modelo ARM.

Validar o seu modelo

Quando você cria manualmente o arquivo de modelo de implantação, é importante validar o modelo antes da implantação. Todos os métodos de implantação validam a sintaxe do modelo e geram uma mensagem de validation failed erro, conforme mostrado no seguinte exemplo formatado em 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":""}}]}}

Os seguintes métodos podem ser usados para validar seu modelo antes da implantação:

A seguinte tarefa de implantação do grupo de recursos do Azure v2 com deploymentMode: 'Validation' instrui o Azure Pipelines a validar o modelo.

- 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'

Você também pode criar um grupo de recursos de teste para localizar erros de comprovação e implantação .

Implementar o seu modelo

Você pode usar qualquer uma das seguintes maneiras de implantar seu arquivo e modelo Bicep:

Botão Implementar no Azure

Nota

Esse método não suporta a implantação de arquivos Bicep atualmente.

Substitua <url-encoded-path-to-azuredeploy-json> por uma versão codificada por URL do caminho bruto do seu azuredeploy.json arquivo no GitHub.

Aqui está um exemplo que usa markdown:

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

Aqui está um exemplo que usa 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>

Implementar com o PowerShell

Os comandos do PowerShell a seguir criam um grupo de recursos e implantam um arquivo Bicep ou modelo ARM que cria um aplicativo de função com seus recursos necessários. Para executar localmente, você deve ter o Azure PowerShell instalado. Para entrar no Azure, você deve primeiro executar Connect-AzAccounto .

# 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

Para testar essa implantação, você pode usar um modelo como este que cria um aplicativo de função no Windows em um plano de consumo.

Próximos passos

Saiba mais sobre como desenvolver e configurar o Azure Functions.