Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Ao criar uma instância de aplicativo de funções em Azure, você deve fornecer acesso a uma conta de Armazenamento do Azure padrão. O diagrama e a tabela a seguir detalham como Azure Functions usa serviços na conta de armazenamento padrão:
Selecione seu plano de hospedagem no topo deste artigo para ver as orientações de armazenamento que se aplicam ao seu aplicativo de funcionamento.
| Serviço de armazenamento | Uso de funções |
|---|---|
| Armazenamento de Blobs do Azure | Mantenha o estado de associações e as chaves de função 1. Fonte de implantação para aplicativos que são executados em um plano de consumo Flex. Usado por padrão para hubs de tarefas em Durable Functions. Pode ser usado para armazenar o código do aplicativo de funções para o build remoto de Consumo em Linux ou como parte de implantações de URL do pacote externo. |
| Arquivos do Azure2 | Compartilhamento de arquivos usado para armazenar e executar o código do aplicativo de funções em um Plano de consumo e Plano Premium. Manter pacotes de extensão. Armazenar logs de implantação. Dá suporte a dependências gerenciadas no PowerShell. |
| Armazenamento de Filas do Azure | Usado por padrão para hubs de tarefas em Durable Functions. Usado para tratamento de falhas e repetições em gatilhos específicos de Azure Functions. Usado para rastreamento de objetos pelo gatilho de armazenamento de blobs. |
| Armazenamento de tabelas do Azure | Usado por padrão para hubs de tarefas em Durable Functions. Usado para acompanhar eventos de diagnóstico. |
- O armazenamento de blobs é o armazenamento padrão para chaves de função, mas você pode configurar um armazenamento alternativo.
- Arquivos do Azure é configurado por padrão, mas você pode criar um aplicativo sem Arquivos do Azure em determinadas condições.
Considerações importantes
Considere os seguintes fatos sobre as contas de armazenamento usadas pelos seus aplicativos de trabalho:
Quando você hospeda seu aplicativo de função no plano Consumption (Windows) ou no plano Premium, você armazena seu código de função e arquivos de configuração no Arquivos do Azure, na conta de armazenamento vinculada. Se você excluir essa conta de armazenamento, você apaga permanentemente o conteúdo. Para obter mais informações, consulte A conta de armazenamento foi excluída.
A conta de armazenamento mantém dados importantes, como código de função, chaves de acesso e outros dados importantes relacionados a serviços. Você deve gerenciar cuidadosamente o acesso às contas de armazenamento usadas pelos aplicativos de funções das seguintes maneiras:
Audite e limite o acesso de aplicativos e usuários à conta de armazenamento com base em um modelo de privilégios mínimos. As permissões para a conta de armazenamento podem vir de ações de dados na função atribuída ou por meio da permissão para executar a operação listKeys.
Monitore a atividade do painel de controle (como recuperar chaves) e as operações do plano de dados (como gravar em um blob) na conta de armazenamento. Considere manter logs de armazenamento em um local diferente do Armazenamento do Azure. Para saber mais, confira Logs de armazenamento.
Se você usar Durable Functions, o armazenamento do hub de tarefas é especialmente sensível em termos de segurança, porque o acesso de gravação a ele pode ser usado para alterar o comportamento do aplicativo, inclusive para permitir a execução arbitrária de código. Para obter mais informações, consulte Proteger o armazenamento do hub de tarefas.
Requisitos da conta de armazenamento
As contas de armazenamento criadas durante o processo de criação do aplicativo de funções no portal Azure funcionam com o novo aplicativo de funções. Quando você opta por usar uma conta de armazenamento existente, a lista fornecida não inclui determinadas contas de armazenamento sem suporte. As restrições a seguir se aplicam às contas de armazenamento usadas pelo aplicativo de funções. Garanta que uma conta de armazenamento existente atenda aos seguintes requisitos:
- Não é possível usar uma conta de armazenamento protegida pela rede quando seu aplicativo de funções estiver hospedado no Plano de consumo.
O tipo de conta deve dar suporte ao armazenamento de Blob, Fila e Tabela. Algumas contas de armazenamento não oferecem suporte a filas e tabelas. Essas contas incluem contas de armazenamento somente blob e Armazenamento Premium do Azure. Para saber mais sobre os tipos de contas de armazenamento, confira Visão geral da conta de Armazenamento.
Ao criar seu aplicativo de funções no portal Azure, você só pode escolher uma conta de armazenamento existente na mesma região que o aplicativo de funções criado. Esse requisito é uma otimização de desempenho e não uma limitação estrita. Para saber mais, veja Local da conta de armazenamento.
Quando você cria seu aplicativo de funções em um plano com suporte à zona de disponibilidade habilitado, há suporte somente para contas de armazenamento redundante de zona.
Ao usar a automação de implantação para criar sua aplicação de função com uma conta de armazenamento com proteção de rede, é preciso incluir configurações de rede específicas no modelo ARM ou no arquivo Bicep. Se você não incluir essas configurações e recursos, sua implantação automatizada poderá falhar na validação. Para obter diretrizes de modelos ARM e Bicep, consulte Implantações seguras. Para obter uma visão geral sobre como configurar contas de armazenamento com rede, consulte Como usar uma conta de armazenamento protegida com Azure Functions.
Orientações sobre a Conta de armazenamento
Cada aplicativo de funções exige uma conta de armazenamento para ser operado. Quando você exclui essa conta, seu aplicativo de funções para de ser executado. Para solucionar problemas relacionados ao armazenamento, consulte Como solucionar problemas relacionados ao armazenamento. As considerações a seguir se aplicam à conta de armazenamento usada por aplicativos de funções.
Local da conta de armazenamento
Para obter o melhor desempenho, o aplicativo de funções deve usar uma conta de armazenamento na mesma região, o que reduz a latência. O portal Azure impõe essa prática recomendada. Se você precisar usar uma conta de armazenamento em uma região diferente do seu aplicativo de funções, deverá criar seu aplicativo de funções fora do portal Azure.
A conta de armazenamento precisa estar acessível para o aplicativo de funções. Se você precisar usar uma conta de armazenamento protegida, considere restringir a conta de armazenamento a uma rede virtual.
Configuração da conta de armazenamento
Por padrão, os aplicativos de funções configuram a conexão AzureWebJobsStorage como um cadeia de conexão armazenado na configuração do aplicativo AzureWebJobsStorage. Você também pode configurar o AzureWebJobsStorage para usar uma conexão baseada em identidade sem um segredo.
Aplicativos de funções em execução em um plano de consumo (somente Windows) ou um plano Elastic Premium (Windows ou Linux) podem usar Arquivos do Azure para armazenar as imagens necessárias para habilitar o dimensionamento dinâmico. Para esses planos, defina a cadeia de conexão da conta de armazenamento na configuração WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e o nome do compartilhamento de arquivos na configuração WEBSITE_CONTENTSHARE. Esse valor geralmente é a mesma conta usada para AzureWebJobsStorage. Você também pode criar um aplicativo de funções que não usa Arquivos do Azure, mas o dimensionamento pode ser limitado.
Observação
Você deve atualizar a cadeia de conexão da conta de armazenamento ao regenerar as chaves de armazenamento. Para obter mais informações, consulte Criar uma conta de armazenamento Azure.
Contas de armazenamento compartilhadas
Vários aplicativos de funções podem compartilhar a mesma conta de armazenamento sem problemas. Por exemplo, em Visual Studio, você pode desenvolver vários aplicativos usando o emulador de armazenamento Azurite. Nesse caso, o emulador age como uma única conta de armazenamento. A mesma conta de armazenamento que seu aplicativo de funções usa também pode armazenar os dados do aplicativo. No entanto, essa abordagem nem sempre é uma boa ideia em um ambiente de produção.
Talvez seja necessário usar contas de armazenamento separadas para evitar colisões de ID do host.
Considerações sobre políticas de gerenciamento de ciclo de vida
Não aplique políticas de gerenciamento de ciclo de vida à sua conta de Armazenamento de Blobs usada pelo aplicativo de funções. O Functions usa o Armazenamento de Blobs para manter informações importantes, como chaves de acesso à função. As políticas podem remover blobs, como chaves, necessários para o host do Azure Functions. Se você deve usar políticas, exclua os contêineres usados pelo Functions, que possuem o prefixo azure-webjobs ou scm.
Logs de armazenamento
Como o código de função e as chaves podem ser persistentes na conta de armazenamento, o registro em log de atividades na conta de armazenamento é uma boa maneira de monitorar o acesso não autorizado. Os logs de recursos do Azure Monitor podem ser usados para acompanhar eventos no plano de dados de armazenamento. Consulte Monitoring Armazenamento do Azure para obter detalhes sobre como configurar e examinar esses logs.
O log de atividades Azure Monitor mostra eventos do plano de controle, incluindo a operação listKeys. No entanto, você também deve configurar logs de recursos para a conta de armazenamento para acompanhar o uso subsequente de chaves ou outras operações de plano de dados baseadas em identidade. Você deve ter pelo menos a categoria de log StorageWrite habilitada para identificar modificações nos dados fora das operações normais do Functions.
Para limitar o impacto potencial de quaisquer permissões de armazenamento com escopo amplo, considere usar um destino não relacionado a armazenamento para esses logs, como o Log Analytics. Para obter mais informações, consulte Monitoring Armazenamento de Blobs do Azure.
Otimizar o desempenho de armazenamento
Use uma conta de armazenamento separada para cada aplicativo de funções para maximizar o desempenho. Essa abordagem é particularmente importante quando você tem funções disparadas por Durable Functions ou Hubs de Eventos, que geram um alto volume de transações de armazenamento. Quando a lógica do aplicativo interage com Armazenamento do Azure, diretamente (usando o SDK de Armazenamento) ou por meio de uma das associações de armazenamento, você deve usar uma conta de armazenamento dedicada. Por exemplo, se você tiver uma função disparada pelo hub de eventos gravando alguns dados no armazenamento de blobs, use duas contas de armazenamento: uma para o aplicativo de funções e outra para os blobs que a função armazena.
Roteamento consistente por meio de redes virtuais
Vários aplicativos de funções hospedados no mesmo plano também podem usar a mesma conta de armazenamento para o compartilhamento de conteúdo Arquivos do Azure, definido por WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Quando você protege essa conta de armazenamento usando uma rede virtual, todos esses aplicativos (incluindo slots) devem usar o mesmo valor para vnetContentShareEnabled (anteriormente WEBSITE_CONTENTOVERVNET) e a mesma configuração de integração de rede virtual para garantir que o tráfego seja roteado consistentemente por meio da rede virtual pretendida. Uma incompatibilidade nessa configuração entre aplicativos que usam o mesmo Arquivos do Azure conta de armazenamento pode resultar em roteamento de tráfego por meio de redes públicas. Nessa configuração, as regras de rede da conta de armazenamento bloqueiam o acesso.
A vnetContentShareEnabled orientação não se aplica a Flex Consumption, Dedicated, Container Apps ou Consumption Hosting.
Trabalhando com blobs
Um cenário-chave para o Functions é o processamento de arquivos em um contêiner de blob, como para processamento de imagem ou análise de sentimento. Para saber mais, confira Processar uploads de arquivos.
Gatilho em um contêiner de blob
Há várias maneiras de executar seu código de função com base em alterações em blobs em um contêiner de armazenamento, conforme indicado por este diagrama:
Use a tabela a seguir para determinar qual gatilho de função melhor atende às suas necessidades de processamento de blobs adicionados ou atualizados em um contêiner:
| Estratégia | Gatilho de blob (sondagem) | Gatilho de blob (controlado por eventos) | Gatilho de fila | Gatilho da Grade de Eventos |
|---|---|---|---|---|
| Latência | Alta (até dez minutos) | Baixo | Médio | Baixo |
| Limitações da conta de armazenamento | Não oferece suporte a contas somente para blobs¹ e a contas com namespace hierárquico (HNS) habilitado, como contas do Azure Data Lake Storage Gen2 | Não suporta contas v1 de uso geral | None | Não suporta contas v1 de uso geral |
| Tipo de gatilho | Armazenamento de Blobs | Armazenamento de Blobs | Armazenamento de filas | Grade de Eventos |
| Versão da extensão | Qualquer | Armazenamento v5.x+ | Qualquer | Qualquer |
| Processa blobs existentes | Sim | Não | Não | Não |
| Filtros | Padrão de nome do blob | Filtros de evento | n/d | Filtros de evento |
| Requer assinatura de evento | Não | Sim | Não | Sim |
| Dá suporte ao plano Consumo Flex | Não | Sim | Sim | Sim |
| Dá suporte a alta escala² | Não | Sim | Sim | Sim |
| Funciona com restrições de acesso de entrada | Sim | Não | Sim | Sim3 |
| Descrição | Comportamento de gatilho padrão, que depende da sondagem do contêiner em busca de atualizações. Para obter mais informações, confira os exemplos na Referência de gatilho de armazenamento de blobs. | Consome eventos de armazenamento de blobs de uma assinatura de evento. Requer um valor de parâmetro Source igual a EventGrid. Para obter mais informações, consulte Tutorial: acionar Azure Functions em contêineres de blob usando uma assinatura de evento. |
A cadeia de caracteres de nome de blob é adicionada manualmente a uma fila de armazenamento quando um blob é adicionado ao contêiner. Um gatilho do Armazenamento de Filas passa esse valor diretamente para uma ligação de entrada do Armazenamento de Blob na mesma função. | Oferece a flexibilidade de acionar eventos além daqueles provenientes de um contêiner de armazenamento. Use quando necessário para que eventos que não sejam de armazenamento também disparem a função. Para obter mais informações, consulte Como trabalhar com gatilhos e associações do Event Grid no Azure Functions. |
- A limitação de conta somente para blobs se aplica apenas ao gatilho de Blob Storage baseado em polling. As associações de entrada e saída do Armazenamento de Blobs dão suporte a contas somente de blob.
- A alta escala pode ser definida vagamente como contêineres que possuem mais de 100.000 blobs ou contas de armazenamento que têm mais de 100 atualizações de blobs por segundo.
- Você pode contornar as restrições de acesso de entrada fazendo com que a assinatura do evento forneça eventos por meio de um canal criptografado no espaço IP público usando uma identidade de usuário conhecida. Para obter mais informações, consulte Entregar eventos com segurança usando identidades gerenciadas.
Criptografia do armazenamento de dados
Armazenamento do Azure criptografa todos os dados em uma conta de armazenamento em repouso. Para obter mais informações, consulte criptografia do Armazenamento do Azure para dados em repouso.
Por padrão, os dados são criptografados com chaves gerenciadas por Microsoft. Para ter mais controle sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para serem usadas na criptografia de dados de blob e de arquivo. Essas chaves devem estar presentes no Azure Key Vault para que o Functions possa acessar a conta de armazenamento. Para saber mais, consulte Criptografar os dados do aplicativo em repouso usando chaves gerenciadas pelo cliente.
Residência de dados na região
Quando todos os dados do cliente devem permanecer dentro de uma única região, use uma conta de armazenamento associada ao aplicativo de função que tenha redundância dentro da região. Também use uma conta de armazenamento redundante dentro da região com Azure Durable Functions.
A plataforma armazena outros dados de clientes gerenciados pela plataforma apenas dentro da região quando você hospeda em um Ambiente do Serviço de Aplicativo (ASE) com balanceamento de carga interna. Para saber mais, veja Redundância de zona do ASE.
Considerações sobre a ID do host
As considerações desta seção sobre o ID do host não se aplicam ao Flex Consumption. Neste plano de hospedagem, o valor do ID do host é criado de forma a evitar esses possíveis problemas.
O Functions usa um valor de ID de host para identificar de forma única um aplicativo de funções específico em artefatos armazenados. Por padrão, o runtime gera automaticamente esse ID a partir do nome do app de função, truncado para os primeiros 32 caracteres. O runtime usa esse ID ao armazenar informações de correlação e rastreamento por aplicativo na conta de armazenamento vinculada. Quando aplicativos de função têm nomes com mais de 32 caracteres e os primeiros 32 caracteres são idênticos, esse truncamento pode resultar em IDs de host duplicados. Quando dois aplicativos de função com IDs de host idênticos usam a mesma conta de armazenamento, ocorre uma colisão de ID de host porque os dados armazenados não podem ser vinculados de forma única ao app de função correto.
Observação
O mesmo tipo de colisão de ID de host pode ocorrer entre um aplicativo de funções em um slot de produção e esse mesmo aplicativo em um slot de preparo, quando ambos os slots usam a mesma conta de armazenamento.
Na versão 4.x do runtime Functions, um erro é registrado e o host para, resultando em uma falha completa. Para obter mais informações, consulte Truncamento de HostID pode causar colisões.
Evitando colisões de ID do host
Use as seguintes estratégias para evitar colisões de ID de host:
- Use contas de armazenamento separadas para que cada host colidindo escreva em uma conta diferente.
- Renomeie um dos seus aplicativos de função para que tenha menos de 32 caracteres no nome, o que altera o ID do host calculado para o aplicativo e remove a colisão.
- Defina uma ID de host explícita para um ou mais dos aplicativos em colisão. Para saber mais, confira Sobrescrever a ID do host.
Importante
Alterar a conta de armazenamento associada a um aplicativo de funções existente ou alterar a ID do host do aplicativo pode afetar o comportamento das funções existentes. Por exemplo, um gatilho do Armazenamento de Blobs acompanha se ele processa blobs individuais gravando registros em um caminho específico do ID do host no armazenamento. Quando a ID do host é alterada ou você aponta para uma nova conta de armazenamento, os blobs processados anteriormente podem ser reprocessados.
Substituir a ID do host
Você pode definir um ID de host explícito para seu app de funções nas configurações do aplicativo usando essa AzureFunctionsWebHost__hostid configuração. Para obter mais informações, consulte AzureFunctionsWebHost__hostid.
Quando ocorre uma colisão entre slots, você deve definir um ID de host específico para cada slot, incluindo o slot de produção. Você também deve marcar essas configurações como configurações de implantação para que elas não sejam trocadas. Para saber como criar configurações de aplicativo, consulte Trabalhar com as configurações do aplicativo.
Criar um aplicativo sem Arquivos do Azure
O serviço Arquivos do Azure fornece um sistema de arquivos compartilhado que dá suporte a cenários de alta escala. Quando o aplicativo de funções é executado em um plano Elastic Premium ou em Windows em um plano de consumo, um compartilhamento de Arquivos do Azure é criado por padrão em sua conta de armazenamento. As funções podem usar esse compartilhamento para recursos como streaming de logs e como localização compartilhada de conteúdo de aplicativo. O local de implantação depende da tecnologia de implantação e da configuração do aplicativo. Por exemplo, um aplicativo que usa uma URL de pacote externo executa seu pacote a partir da URL configurada em vez do compartilhamento Arquivos do Azure.
Usar o Arquivos do Azure requer uma cadeia de conexão, que você armazena nas configurações do seu app como WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Arquivos do Azure atualmente não dá suporte a conexões baseadas em identidade. Se o seu cenário exigir que você não armazene nenhum segredo nas configurações do app, você deve remover a dependência do seu app do Arquivos do Azure. Você pode evitar essa dependência criando seu aplicativo sem a dependência de Arquivos do Azure padrão.
Observação
Você também deve considerar executar seu aplicativo de funções no plano Flex Consumption, que oferece maior controle sobre o pacote de implantação, incluindo a capacidade de usar conexões de identidade gerenciada. Para obter mais informações, consulte Definir configurações de implantação.
Para rodar seu aplicativo sem o compartilhamento Arquivos do Azure, você deve atender aos seguintes requisitos:
Você deve implantar seu pacote em um contêiner do Armazenamento de Blobs do Azure que não permita acesso anônimo e definir a URL Armazenamento de Blobs do pacote como configuração
WEBSITE_RUN_FROM_PACKAGEdo app.Para evitar armazenar uma credencial de implantação na URL do pacote, conceda à identidade gerenciada do aplicativo de funções acesso ao pacote. Quando você usa uma identidade atribuída pelo usuário, também defina
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID. Se você não puder usar identidade gerenciada, use uma URL de assinatura de acesso compartilhada (SAS) e renove antes que o SAS expire.Para remover a cadeia de conexão da conta de armazenamento padrão do host das configurações do seu aplicativo, configure
AzureWebJobsStoragepara usar uma identidade gerenciada.Você deve atualizar manualmente o pacote de implantação e manter a URL do pacote de implantação. Para informações sobre como reiniciar o app e sincronizar gatilhos ao atualizar o pacote, veja Executar a partir de uma URL de pacote externo.
Você também deve observar as seguintes considerações:
- Seu aplicativo não pode contar com um sistema de arquivos compartilhado e gravável.
- Não há suporte para edição de portal.
- Experiências de streaming de log em clientes, como o portal do Azure de padrão para logs do sistema de arquivos. Em vez disso, você deve confiar em logs do Application Insights.
Se os requisitos anteriores atenderem ao seu cenário, você poderá continuar a criar um aplicativo de funções sem Arquivos do Azure. Crie um aplicativo sem as configurações de aplicativo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE de uma das seguintes maneiras:
- Modelos Bicep/ARM: remova as duas configurações do app do template ARM ou do arquivo Bicep e então implante o app usando o template modificado.
- No portal do Azure: limpe Adicione uma conexão do Arquivos do Azure na guia Armazenamento ao criar o aplicativo no portal do Azure.
Arquivos do Azure é usado para habilitar a expansão dinâmica para funções. O dimensionamento pode ser limitado quando você executa seu aplicativo sem Arquivos do Azure no plano Elastic Premium e nos planos de consumo em execução no Windows.
O Flex Consumption não depende de um compartilhamento de conteúdo do Arquivos do Azure. Ele usa armazenamento de Blob configurável para implantação e oferece suporte a conexões com identidade gerenciada. Para obter mais informações, consulte Definir configurações de implantação.
Aplicativos dedicados de planos não possuem a dependência padrão de compartilhamento de conteúdo do Arquivos do Azure descrita nesta seção.
Funções no Aplicativos de Contêiner do Azure não possuem a dependência padrão de compartilhamento de conteúdo do Arquivos do Azure descrita nesta seção.
Montar compartilhamento de arquivos
Essa funcionalidade está disponível apenas quando rodando no Linux.
Você pode montar compartilhamentos do Arquivos do Azure nos seus aplicativos de funções Linux, que podem ser usados para acessar arquivos existentes, modelos de aprendizado de máquina ou grandes binários em suas funções. Para obter diretrizes conceituais sobre como escolher entre montagens de armazenamento, associações e bancos de dados externos, consulte Conseque uma estratégia de acesso a arquivos para Azure Functions.
O Flex Consumption dá suporte apenas a montagens do Arquivos do Azure com Server Message Block (SMB).
Use o comando a seguir para montar um compartilhamento existente no seu aplicativo de funções Linux.
az webapp config storage-account add
Neste comando, share-name é o nome do compartilhamento de Arquivos do Azure existente.
custom-id pode ser qualquer cadeia de caracteres que defina exclusivamente o compartilhamento quando montado no aplicativo de funções. Além disso, mount-path é o caminho do qual o compartilhamento é acessado no aplicativo de funções.
mount-path deve estar no formato /dir-name e não pode começar com /home.
Para obter um exemplo completo, consulte Criar um aplicativo de funções Python e montar um compartilhamento Arquivos do Azure.
Para Funções em Aplicativos de Contêiner do Azure, configure um volume do Arquivos do Azure no aplicativo de contêiner. Para obter mais informações, confira Usar montagens de armazenamento nos Aplicativos de Contêiner do Azure.
Não há suporte para montagens de armazenamento no plano de consumo.
Importante
Os Aplicativos de Função ainda executando o end-of-life v3 runtime no Linux em um plano Consumo deixarão de funcionar depois de 30 de setembro de 2026. Para evitar a interrupção do serviço, migre seu aplicativo para o runtime v4.
A opção de hospedar aplicativos de funções no Linux em um plano de consumo será desativada em 30 de setembro de 2028. O plano de consumo do Linux não está recebendo novos recursos ou versões de idioma. Os aplicativos em execução em Windows em um plano de consumo não são afetados no momento. Migre seus aplicativos para o plano de Consumo Flex antes da data de aposentadoria.