Compartilhar via

Automatizar a implantação de recursos para seu aplicativo de funções do Azure Functions

  • Artigo

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

  • Integrando suas implantações de recursos com seu código-fonte em Azure Pipelines e implantações baseadas em GitHub Actions.
  • Restaurar um aplicativo de funções e recursos relacionados de um backup.
  • Implantar uma topologia de aplicativo diversas vezes.

Este artigo mostra como automatizar a criação de recursos e implantação para o 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 do modelo necessário depende das opções de hospedagem desejadas para seu aplicativo de funções. Este artigo dá suporte às seguintes opções de hospedagem:

Opção de hospedagem Tipo de implantação Para saber mais, confira:
Plano de consumo do Azure Functions Somente código Plano de Consumo
Plano de Consumo flexível do Azure Functions Somente código Plano de Consumo Flexível
Plano Premium do Azure Elastic Functions Código | Contêiner Plano Premium
Plano dedicado do Azure Functions (Serviço de Aplicativo) Código | Contêiner Plano dedicado
Aplicativos de Contêiner do Azure Somente contêiner Hospedagem de Aplicativos de Contêiner do Azure Functions
Azure Arc Código | Contêiner Serviço de Aplicativo, Functions e Aplicativos Lógicos no Azure Arc (versão prévia)

Ao usar esse artigo, tenha essas considerações em mente:

  • 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 Requisito Referência da sintaxe e propriedades
Uma conta de armazenamento Obrigatório Microsoft.Storage/storageAccounts
UmComponente do Application Insights Recomendado microsoft.insights/componentes*
UmPlano de hospedagem Obrigatório Microsoft.Web/serverfarms
Um aplicativo de funções Obrigatório Microsoft.Web/sites

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

Recurso Requisito Referência da sintaxe e propriedades
Uma conta de armazenamento Obrigatório Microsoft.Storage/storageAccounts
UmComponente do Application Insights Recomendado microsoft.insights/componentes*
Um aplicativo de funções Obrigatório Microsoft.Web/sites

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

Recurso Requisito Referência da sintaxe e propriedades
Uma conta de armazenamento Obrigatório Microsoft.Storage/storageAccounts
UmComponente do Application Insights Recomendado microsoft.insights/componentes*
Um ambiente gerenciado Obrigatório Microsoft.App/managedEnvironments
Um aplicativo de funções Obrigatório Microsoft.Web/sites

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

Recurso Requisito Referência da sintaxe e propriedades
Uma conta de armazenamento Obrigatório Microsoft.Storage/storageAccounts
UmComponente do Application Insights Recomendadas Microsoft.Insights/componentes1
Um ambiente Kubernetes do Serviço de Aplicativo Obrigatório Microsoft.ExtendedLocation/customLocations
Um aplicativo de funções Obrigatório Microsoft.Web/sites

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

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

Pré-requisitos

  • Os exemplos foram 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 Azure Log Analytics existente. 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 Log Analytics, veja Criar um espaço de trabalho Log Analytics. Você pode encontrar o ID de recurso do espaço de trabalho totalmente qualificado em uma página do espaço de trabalho no portal do Azure em Configurações>Propriedades>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 de funções hospedado em Aplicativos de Contêiner.

Criar Conta de Armazenamento

Todos os aplicativo de funções requerem uma conta de armazenamento do Azure. Você precisa de uma conta de finalidade geral que dá suporte a blobs, tabelas, consultas e arquivos. Para saber mais, confira 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.

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

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 amostra.

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

Contêiner de implantação

As implantações em um aplicativo em execução no plano de Consumo Flex exigem um contêiner no Armazenamento de Blobs do Azure como 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, veja 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ção, veja Fontes de implantação.

Esse 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 obter o snippet no contexto, veja esse exemplo de implantação.

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

Habilitar logs de armazenamento

Como a conta de armazenamento é usada para dados importantes do aplicativo de funções, você deve monitorar conta quanto à 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 Microsoft Azure. Nesta seção de exemplo, um workspace do Log Analytics chamado myLogAnalytics é usado como o destino desses 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 workspace pode ser usado para o recurso do Application Insights definido posteriormente. Para obter mais informações, incluindo como trabalhar com esses logs, consulte Monitorar o Armazenamento do Microsoft Azure.

Criar Application Insights

Você deve usar o Application Insights para monitorar as execuções do aplicativo de funções. O Application Insights agora requer um espaço de trabalho do Azure Log Analytics, que pode ser compartilhado. Esses exemplos pressupõem que você está usando um espaço de trabalho existente e tem a ID de recurso totalmente qualificada para o espaço de trabalho. Para obter mais informações, veja 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 precisa ser fornecida ao aplicativo de funções usando a configuração de aplicativo APPLICATIONINSIGHTS_CONNECTION_STRING. Para mais informações, consulte Configuração de aplicativo.

Os exemplos neste artigo obtêm o valor da cadeia de conexão para a instância criada. Em vez disso, as versões mais antigas podem usar 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 de Consumo Flexível do Azure Functions, plano Premium ou plano Dedicado (Serviço de Aplicativo) devem ter o plano de hospedagem definido explicitamente.

Consumo Flex é um plano de hospedagem baseado em Linux que se baseia no modelo de cobrança sem servidor Consumo pague pelo que usar. O plano oferece suporte para rede privada, seleção de tamanho de memória de instância e suporte aprimorado de identidade gerenciada.

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

Essa seção de exemplo cria um plano de Consumo flexível:

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, veja o arquivo function.bicep completo no repositório de amostra do plano Consumo Flex.

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

O Plano Premium oferece a mesma colocação em escala do Plano de Consumo, mas inclui os recursos dedicados e as funcionalidades adicionais. Para saber mais,consultePlano Premium do Azure Functions.

Um plano Premium é um tipo especial de recurso serverfarm. Especifique-o usando EP1, EP2 ou EP3 para o valor da propriedade Name na propriedade sku. A maneira como você define o plano de hospedagem do Functions depende se o aplicativo de funções é executado no Windows ou no Linux. Esta seção de exemplo cria um plano 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
  }
}

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

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

No plano Dedicado (Serviço de Aplicativo), seus aplicativos de funções são executados em VMs dedicadas, em SKUs Básico, Standard e Premium nos planos do Serviço de Aplicativo, assim como os aplicativos Web. Para obter mais informações, confira Plano dedicado.

Para ver um exemplo de arquivo Bicep/modelo do Azure Resource Manager, confira Aplicativo de funções no Plano do Serviço de Aplicativo do Azure.

No Functions, o plano dedicado é apenas um Plano do Serviço de Aplicativo regular, definido por um recurso serverfarm. Você precisa fornecer pelo menos um valor name. Para obter uma lista de nomes de plano com suporte, consulte a configuração --sku em az appservice plan create para a lista atual de valores com suporte para um plano Dedicado.

A maneira como você define o plano de hospedagem depende se o aplicativo de funções é 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. Ao ignorar essa definição de recurso, um plano será criado automaticamente ou selecionado por região quando você criar o recurso de aplicativo de funções propriamente dito.

Você pode definir explicitamente um plano de consumo como um tipo especial de recurso serverfarm, que você especifica usando o valor Dynamic para as propriedades computeMode 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 o aplicativo de funções é 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 do Kubernetes

O Azure Functions pode ser implantado para o Kubernetes habilitado para Azure Arc como um projeto de código ou um aplicativo de funções em contêineres.

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 o Azure Arc. Os exemplos neste artigo presumem que você tenha a ID do recurso do local personalizado (customLocationId) e o ambiente do Kubernetes do Serviço de Aplicativo (kubeEnvironmentId) em que você está fazendo a implantação, que estão definidos neste exemplo:

param kubeEnvironmentId string
param customLocationId string

Ambos os sites e planos devem referenciar o local personalizado por meio de um campo extendedLocation. Conforme 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 do Kubernetes (K1) para SKU, o campo kind deve ser linux,kubernetes e a propriedade reserved deve ser true, já que é uma implantação do Linux. Você também precisa definir o extendedLocation e kubeEnvironmentProfile.id para a ID de local personalizada e a ID do ambiente do Kubernetes, respectivamente, que podem ser semelhantes a 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
  }
}

Crie o aplicativo de funções

O recurso do aplicativo de funções é 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ções depende se você está hospedando no Windows ou no Linux:

Para obter uma lista das configurações de aplicativo necessárias ao executar no Windows, confira Configuração do aplicativo. Para ver um exemplo de arquivo Bicep/modelo do Azure Resource Manager, confira o modelo Aplicativo de funções hospedado no plano de Consumo no Windows.

Para obter uma lista das configurações de aplicativo necessárias ao executar no Windows, confira Configuração do aplicativo.

O Consumo Flex substitui muitas das configurações padrão do aplicativo e propriedades de configuração do site usadas nas implantações de modelos Bicep e ARM. Para mais informações, consulte Configuração de 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, veja o arquivo function.bicep completo no repositório de amostra do plano Consumo Flex.

Observação

Se você optar por definir explicitamente o plano de Consumo, precisará definir a propriedade serverFarmId no aplicativo, de modo que ele aponte para a ID do recurso do plano. Verifique se o aplicativo de funções tem uma configuração dependsOn que também referencia o plano. Se você não definiu explicitamente um plano, um será criado para você.

Defina a propriedade serverFarmId no aplicativo, de modo que ele aponte para a ID do recurso do plano. Verifique se o aplicativo de funções tem uma configuração dependsOn que também referencia o 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 linuxFxVersion do site para solicitar que um contêiner específico do Linux 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 mais informações, consulte Configuração de aplicativo.

Importante

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

A equipe do Functions está comprometida em publicar atualizações mensais para essas imagens base. As atualizações regularem incluem as atualizações de versão secundária mais recentes e as correções de segurança para linguagens e runtime do Functions. Você deve atualizar regularmente o seu contêiner a partir da imagem base mais recente e reimplantar a versão atualizada do seu contêiner.

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

O plano de Consumo Flex mantém o código do seu projeto em um pacote de arquivos compactado no formato zip, armazenado em um contêiner 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 obter mais informações, consulte Implantação.

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

Contêiner de implantação

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

Esse exemplo utiliza uma identidade gerida atribuída pelo sistema para aceder ao contêiner de armazenamento de bolhas especificado, que é criado noutro local da implantação:

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

Ao utilizar identidades geridas, também deve permitir que a aplicação de funções aceda à conta de armazenamento utilizando 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 um exemplo de referência completo, veja esse arquivo Bicep.

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

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 authentication.type como 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 de Consumo Flex 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 do pacote em si deve ser released-package.zip.

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

Este exemplo adiciona uma origem de implantação 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 
  }
}

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

Para implantar seu aplicativo com êxito usando o Azure Resource Manager, é 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 siteConfig. É importante definir essas configurações em um nível superior porque transmitem informações para o mecanismo de implantação e de runtime do Functions. Informações de nível superior são necessárias antes do recurso filho sourcecontrols/web ser aplicado. Embora seja possível definir essas configurações no recurso config/appSettings de nível infantil, em alguns casos seu aplicativo de funções deve ser implantado antes config/appSettings é aplicado.

Pacote de implantação de zip

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

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

Para um plano de consumo no Linux, em vez disso, defina o URI do pacote de implantação diretamente na configuração de WEBSITE_RUN_FROM_PACKAGE, 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 as seguintes coisas ao incluir recursos de implantação zip em seu modelo:

  • O packageUri precisa ser um local que possa ser acessado pelo Functions. Considere usar o Armazenamento de Blobs do Azure com uma SAS (Assinatura de Acesso Compartilhado). Depois que a SAS expirar, o Functions não poderá mais acessar o compartilhamento para implantações. Ao regenerar sua SAS, lembre-se de atualizar a configuração de WEBSITE_RUN_FROM_PACKAGE com o novo valor de URI.

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

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

  • O Functions não dá suporte à Implantação da Web (msdeploy) para implantações de pacote. Em vez disso, você precisa usar a implantação de zip em seus pipelines de implantação e automação. Para obter mais informações, confira Implantação de zip para o Azure Functions.

Builds remotos

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

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

A maneira como você solicita um build remoto depende do sistema operacional no qual você está implantando:

Quando um aplicativo é implantado no Windows, comandos específicos de linguagem (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 suas configurações do aplicativo em seu código de implantação e remova o WEBSITE_RUN_FROM_PACKAGE por completo.

Contêineres do Linux

Se você estiver implantando um aplicativo de funções em contêineres em um plano Premium ou Dedicado do Azure Functions, precisará:

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

Function app provisioning failed.

Para mais informações, consulte Configuração de 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 precisa:

  • Definir o campo kind como um valor de functionapp,linux,container,azurecontainerapps.
  • Defina a propriedade de site managedEnvironmentId como o URI totalmente qualificado do ambiente de Aplicativos de Contêiner.
  • Adicione um link de recurso na coleção de dependsOn do site ao criar um recurso de Microsoft.App/managedEnvironments ao mesmo tempo que o site.

A definição de um aplicativo de funções em contêineres 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 campo kind do recurso do aplicativo de funções depende do tipo de implantação:

Tipo de implantação Valor do campo kind
Implantação somente código functionapp,linux,kubernetes
Implantação de contêiner functionapp,linux,kubernetes,container

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

A definição de um aplicativo de funções em contêineres, 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 do aplicativo

Num plano de Consumo Flexível, configura a sua aplicação de funções em Azure com dois tipos de propriedades:

Configuração Propriedade Microsoft.Web/sites
Configuração do aplicativo functionAppConfig
Configurações do aplicativo siteConfig.appSettings collection

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

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

O plano Consumo Flex também oferece suporte a essas configurações de aplicativo:

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

Configuração Propriedade Microsoft.Web/sites
Configurações do site siteConfig
Configurações do aplicativo siteConfig.appSettings collection

Essas configurações de site são obrigatórias na propriedade siteConfig:

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 uma opção de hospedagem:

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

Estas configurações só são necessárias ao implantar 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 do ARM:

  • A configuração opcional alwaysReady contém uma matriz de um ou mais objetos {name,instanceCount}, cada um representando grupo de escala por função. Esses grupos de escala são usados para tomar decisões de ajuste de escala de forma "always-ready", ou seja, estão prontos para agir sempre que necessário. Este exemplo define contagens de escala de forma "always-ready"para o grupo http e também para uma função específica chamada helloworld, que usa um tipo de gatilho não agrupado:
      alwaysReady: [
    {
      name: 'http'
      instanceCount: 2
    }
    {
      name: 'function:helloworld'
      instanceCount: 1
    }
  ]
  • Há considerações importantes sobre a definição de WEBSITE_CONTENTSHARE em uma implantação automatizada. Para obter diretrizes detalhadas, veja a referência WEBSITE_CONTENTSHARE.

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

  • 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ê precisa fazer isso porque as chamadas à API REST de atualização subjacente substituem todo o recurso /config/appsettings. Se você remover as configurações existentes, seu aplicativo de funções não será executado. Para atualizar programaticamente as configurações individuais do aplicativo, 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, confira Trabalhar com configurações de aplicativo.

implantações de slot

O Functions permite implantar versões diferentes do código em pontos de extremidade exclusivos em seu aplicativo de funções. 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 as funções em Slots de implantação do Azure Functions.

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

Para saber como trocar slots usando modelos, veja Automatizar com modelos do Resource Manager.

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

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

  • Quando você troca slots, algumas configurações de aplicativo são consideradas "grudentas", pois permanecem com o slot e não com o código sendo trocado. Você pode definir uma configuração de slot incluindo "slotSetting":true na definição de configuração de aplicativo específica em seu modelo. Para saber mais, confira Gerenciar configurações.

Implantações protegidas

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

Esses projetos fornecem exemplos baseados em Bicep de como implementar as suas aplicações de função numa rede virtual, incluindo com restrições de acesso à rede:

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

Observação

Quando essas configurações não fazem parte de uma implantação que usa uma conta de armazenamento protegida, você vê esse 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 do ARM de como implantar seus aplicativos de funções em uma rede virtual, inclusive com restrições de acesso à rede:

Cenário restrito Descrição
Criar um aplicativo de funções com integração de rede virtual Seu aplicativo de funções é criado em uma rede virtual com acesso total aos recursos nessa rede. O acesso de entrada e saída ao aplicativo de funções não é restrito. Para saber mais, veja Integração de rede virtual.
Criar um aplicativo de funções que acessa uma conta de armazenamento protegida Seu aplicativo de funções criado usa uma conta de armazenamento protegida, que o Functions acessa usando pontos de extremidade privados. Para obter mais informações, confira Restringir a conta de armazenamento a uma rede virtual.
Criar um aplicativo de funções e uma conta de armazenamento que usam pontos de extremidade privados Seu aplicativo de funções 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, confira Pontos de extremidade privados.

Configurações de rede restrita

Talvez você também precise usar essas configurações quando seu aplicativo de funções tiver restrições de rede:

Configuração Valor Descrição
WEBSITE_CONTENTOVERVNET 1 Uma configuração de aplicativo que permite que o aplicativo de funções seja dimensionado quando a conta de armazenamento é restrita a uma rede virtual. Para obter mais informações, confira Restringir a conta de armazenamento a uma rede virtual.
vnetrouteallenabled 1 Configuração de site que força todo o tráfego do aplicativo de funções a usar a rede virtual. Para obter mais informações, confira Integração de rede virtual regional. Essa configuração de site substitui a configuração do aplicativo WEBSITE_VNET_ROUTE_ALL.

Considerações sobre 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 dar acesso ao endereço IP protegido ou à rede virtual na conta de armazenamento gerenciando a regra de acesso à rede padrão.

Chaves de acesso de 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. Esse exemplo cria uma chave de acesso no nível do host chamada my_custom_key quando o aplicativo de funções é 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'))
  ]
}

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

Quando você não define a propriedade value, 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, veja Trabalhar com chaves de acesso no Azure Functions.

Criar seu modelo

Especialistas em modelos Bicep ou do ARM podem codificar manualmente as próprias implantações usando um editor de texto simples. Para o resto de nós, há várias maneiras de facilitar o processo de desenvolvimento:

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

  • Portal do Azure: quando você criar seu aplicativo de funções e recursos relacionados no portal, a tela final Examinar + criar terá um link Baixar um modelo para automação.

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

    Este link mostra o modelo do ARM gerado com base nas opções escolhidas no portal. Esse modelo pode parecer um pouco complexo quando você cria um aplicativo de funções com muitos recursos novos. No entanto, pode fornecer uma boa referência sobre a aparência do seu modelo ARM.

Validar o modelo

Quando você cria manualmente o arquivo de modelo de implantação, é importante validar seu modelo antes da implantação. Todos os métodos de implantação validam a sintaxe do modelo e geram uma mensagem de erro validation failed, 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 tarefa implantação do grupo de recursos do Azure v2 a seguir, 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 encontrar pré-lançamento e erros de implantação.

Implantar o modelo

Você pode usar uma das seguintes maneiras para implantar o arquivo Bicep e o modelo:

Botão Implantar no Azure

Observação

Este método não dá suporte à implantação de arquivos Bicep no momento.

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

Este é 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>)

Este é 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>

Implantar usando 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ções com os recursos necessários. Para executar o loca, você deve ter oMicrosoft Azure PowerShellinstalado. Para entrar no Azure, primeiro você deve executar 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

Para testar essa implantação, você pode usar ummodelo de curtidaque cria um aplicativo de funções no Windows em um Plano de Consumo.

Próximas etapas

Saiba mais sobre como desenvolver e configurar o Azure Functions.