Considerações de armazenamento do Azure Functions
O Azure Functions requer uma conta de armazenamento do Azure quando você cria uma instância de aplicativo de funções. Os seguintes serviços de armazenamento podem ser usados pelo aplicativo de funções:
| 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 pelos hubs de tarefas no 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. |
| Armazenamento de Filas do Azure | Usado por padrão pelos hubs de tarefas no Durable Functions. Usado para tratamento de falha e repetição em gatilhos específicos do Azure Functions. Usado para rastreamento de objetos pelo gatilho de armazenamento de blobs. |
| Armazenamento de Tabelas do Azure | Usado por padrão pelos hubs de tarefas no Durable Functions. |
- O armazenamento de blobs é o armazenamento padrão para chaves de função, mas você pode configurar um armazenamento alternativo.
- Arquivos do Azure são configurados por padrão, mas você pode criar um aplicativo sem Arquivos do Azure, sob determinadas condições.
Considerações importantes
Você deve considerar seriamente os seguintes fatos sobre as contas de armazenamento usadas por seus aplicativos de funções:
Quando o aplicativo de funções é hospedado no plano de Consumo ou no plano Premium, o código de função e os arquivos de configuração são armazenados em Arquivos do Azure na conta de armazenamento vinculada. Ao excluir essa conta de armazenamento, o conteúdo será excluído e não poderá ser recuperado. Para obter mais informações, confira A conta de armazenamento foi excluída
Dados importantes, como código de função, chaves de acesso e outros dados importantes relacionados ao serviço, podem ser mantidos na conta de armazenamento. 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 Microsoft Azure. Para saber mais, confira Logs de armazenamento.
Requisitos da conta de armazenamento
As contas de armazenamento criadas como parte do fluxo de criação do aplicativo de funções no portal do Azure têm a garantia de funcionar 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 seguintes restrições se aplicam às contas de armazenamento usadas pelo aplicativo de funções, portanto, você deve garantir que uma conta de armazenamento existente atenda a estes requisitos:
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.
Não é possível usar uma conta de armazenamento protegida pela rede quando seu aplicativo de funções estiver hospedado no Plano de consumo.
Ao criar seu aplicativo de funções no portal, você só tem permissão para escolher uma conta de armazenamento existente na mesma região que o aplicativo de funções que você está criando. Essa é uma otimização de desempenho e não uma limitação estrita. Para saber mais, veja Local da conta de armazenamento.
Ao criar seu aplicativo de funções em um plano com suporte de zona de disponibilidade habilitado, apenas as contas de armazenamento redundância de zona são suportadas.
Ao utilizar a automatização de implantação para criar a sua aplicação de funções com uma conta de armazenamento protegida pela rede, deve incluir configurações de rede específicas no seu modelo ARM ou ficheiro Bicep. Quando você não inclui essas configurações e recursos, sua implantação automatizada pode falhar na validação. Para obter orientações mais específicas sobre ARM e Bicep, veja Implantações seguras. Para obter uma visão geral sobre a configuração de contas de armazenamento com rede, veja Como usar uma conta de armazenamento segura com Azure Functions.
Orientações sobre a Conta de armazenamento
Cada aplicativo de funções exige uma conta de armazenamento para ser operado. Quando essa conta for excluída, o aplicativo de funções não será executado. Para solucionar problemas relacionados ao armazenamento, consulte Como solucionar problemas relacionados ao armazenamento. As outras considerações a seguir se aplicam à Conta de armazenamento usada pelos 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 do Azure impõe essa prática recomendada. Se, por algum motivo, você precisar usar uma conta de armazenamento em uma região diferente do aplicativo de funções, deverá criar o aplicativo de funções fora do portal.
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 uma cadeia de conexão armazenada na configuração de aplicativo AzureWebJobsStorage, mas você também pode configurar 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 em um plano Elastic Premium (Windows ou Linux) podem usar os Arquivos do Azure para armazenar as imagens necessárias para habilitar o dimensionamento dinâmico. Para esses planos, defina a cadeia de conexão para a conta de armazenamento na configuração WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e o nome do compartilhamento de arquivos na configuração WEBSITE_CONTENTSHARE. Geralmente, essa é a mesma conta usada para AzureWebJobsStorage. Você também pode criar um aplicativo de funções que não usa os Arquivos do Azure, mas a colocação em escala pode ser limitada.
Observação
Uma cadeia de conexão da conta de armazenamento deverão ser atualizadas se você regenerar as chaves de armazenamento. Leia mais sobre o gerenciamento de chaves de armazenamento aqui.
Contas de armazenamento compartilhadas
É possível que vários aplicativos de funções compartilhem a mesma conta de armazenamento sem nenhum problema. Por exemplo, no Visual Studio, você pode desenvolver vários aplicativos usando o emulador de armazenamento do Azure. Nesse caso, o emulador age como uma única conta de armazenamento. A mesma conta de armazenamento usada pelo aplicativo de funções também pode ser usada para 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
Você não deve aplicar políticas de gerenciamento do 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 de função, e as políticas podem remover blobs (como chaves) necessários para o host do 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 Monitoramento do Armazenamento do Microsoft Azure para obter detalhes sobre como configurar e examinar esses logs.
O log de atividades do Azure Monitor mostra eventos do painel 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 que não seja de armazenamento para esses logs, como a Análise de Logs. Para obter mais informações, confira Como monitorar o 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. Isso será especialmente importante ao disparar as funções do Durable Functions ou do Hub de Eventos, que geram um alto volume de transações de armazenamento. Quando a lógica de aplicativo interagir com o Armazenamento do Azure, de modo direto (usando o SDK de Armazenamento) ou por meio de uma das associações de armazenamento, você deverá usar uma conta de armazenamento dedicada. Por exemplo, caso uma função disparada pelo Hub de Eventos esteja gravando dados no armazenamento de blobs, use duas contas de armazenamento – uma para o aplicativo de funções e outra para os blobs que estão sendo armazenados pela função.
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 dos Arquivos do Azure (definido por WEBSITE_CONTENTAZUREFILECONNECTIONSTRING). Quando essa conta de armazenamento também é protegida por uma rede virtual, todas essas aplicações também devem utilizar o mesmo valor para vnetContentShareEnabled (anteriormente WEBSITE_CONTENTOVERVNET) para garantir que o tráfego é encaminhado de forma consistente através da rede virtual pretendida. Uma incompatibilidade nessa definição entre aplicações que utilizam a mesma conta de armazenamento de Arquivos do Azure pode resultar no encaminhamento do tráfego através de redes públicas, o que faz com que o acesso seja bloqueado pelas regras de rede da conta de armazenamento.
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 o código de função com base em alterações em blobs em um contêiner de armazenamento. Use a seguinte tabela para determinar qual gatilho de função é melhor para suas necessidades:
| Estratégia | Contêiner (sondagem) | Contêiner (eventos) | Gatilho de Fila | Grade de Eventos |
|---|---|---|---|---|
| Latency | Alta (até dez minutos) | Baixo | Médio | Baixo |
| Limitações da conta de armazenamento | Contas somente blob sem suporte¹ | uso geral v1 sem suporte | nenhum | uso geral v1 sem suporte |
| 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 | No | No |
| Filtros | Padrão de nome do blob | Filtros de evento | n/d | Filtros de evento |
| Requer assinatura de evento | No | 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 |
| 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, confira Tutorial: disparar o 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. Esse valor é passado diretamente por um gatilho de armazenamento de filas para uma ligação de entrada de armazenamento de blobs na mesma função. | Fornece a flexibilidade de disparar em 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, confira Como trabalhar com gatilhos e associações da Grade de Eventos no Azure Functions. |
- 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.
Criptografia do armazenamento de dados
O 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 pela Microsoft. Para obter controle adicional sobre as chaves de criptografia, você pode fornecer chaves gerenciadas pelo cliente para usar para criptografia de dados de blob e arquivo. Essas chaves devem estar presentes no Azure Key Vault para que o Functions possa acessar a conta de armazenamento. Para saber mais, confira Criptografia em repouso usando chaves gerenciadas pelo cliente.
Residência de dados na região
Quando todos os dados do cliente devem permanecer em uma única região, a conta de armazenamento associada ao aplicativo de funções deve ser uma com redundância na região. Uma conta de armazenamento redundante na região também deve ser usada com o Azure Durable Functions.
Outros dados do cliente gerenciados pela plataforma são armazenados apenas dentro da região ao hospedar em um ASE (Ambiente do Serviço de Aplicativo) com balanceamento de carga internamente. Para saber mais, veja Redundância de zona do ASE.
Considerações sobre a ID do host
O Functions usa um valor de ID do host como uma maneira de identificar exclusivamente um aplicativo de funções específico em artefatos armazenados. Por padrão, essa ID é gerada automaticamente a partir do nome do aplicativo de funções, truncada para os primeiros 32 caracteres. Essa ID é usada ao armazenar informações de correlação por aplicativo e acompanhamento na conta de armazenamento vinculada. Quando você tem aplicativos de funções com nomes com mais de 32 caracteres e quando os primeiros 32 caracteres são idênticos, esse truncamento pode resultar em valores duplicados de ID do host. Quando dois aplicativos de funções com IDs de host idênticas usam a mesma conta de armazenamento, você obtém uma colisão de ID de host porque os dados armazenados não podem ser vinculados exclusivamente ao aplicativo de funções correto.
Observação
Esse tipo de colisão de ID de host pode ocorrer entre um aplicativo de funções em um slot de produção e o mesmo aplicativo de funções em um slot de preparo, quando ambos os slots usam a mesma conta de armazenamento.
A partir da versão 3.x do runtime do Functions, a colisão da ID do host é detectada e um aviso é registrado. Na versão 4.x, um erro é registrado e o host é interrompido, resultando em uma falha dura. Mais detalhes sobre a colisão da ID do host podem ser encontrados neste problema.
Evitando colisões de ID do host
Você pode usar as seguintes estratégias para evitar colisões de ID do host:
- Use uma conta de armazenamento separada para cada aplicativo de funções ou slot envolvido na colisão.
- Renomeie um dos aplicativos de funções para um valor menor que 32 caracteres de comprimento, o que altera a ID do host computado 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, consulte a substituição da 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 de armazenamento de Blobs rastreia se são processados blobs individuais gravando recibos em um caminho de ID de host específico 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 explicitamente uma ID de host específica para o aplicativo de funções nas configurações do aplicativo usando a configuração AzureFunctionsWebHost__hostid. Para obter mais informações, consulte AzureFunctionsWebHost__hostid.
Quando a colisão ocorre entre slots, você deve definir uma ID de host específica 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.
Clusters habilitados para Azure Arc
Quando seu aplicativo de funções é implantado em um cluster do Kubernetes habilitado para Azure Arc, uma conta de armazenamento pode não ser exigida pelo aplicativo de funções. Nesse caso, uma conta de armazenamento só é exigida pelo Functions quando seu aplicativo de funções usa um gatilho que requer armazenamento. A tabela a seguir indica quais gatilhos podem exigir uma conta de armazenamento e quais não.
| Não é necessária | pode exigir armazenamento |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Barramento de Serviço |
• SQL do Azure • Armazenamento de blobs • Grade de Eventos • Hubs de Evento • Hub IoT • Armazenamento de Filas • SendGrid • SignalR • Armazenamento de tabelas • Timer • Twilio |
Para criar um aplicativo de funções em um cluster do Kubernetes habilitado para Azure Arc sem armazenamento, você deve usar o comando az functionapp create da CLI do Azure. A versão da CLI do Azure deve incluir a versão 0.1.7 ou uma versão posterior da extensão appservice-kube. Use o comando az --version para verificar se a extensão está instalada e se é a versão correta.
Criar recursos do aplicativo de funções usando métodos diferentes da CLI do Azure requer uma conta de armazenamento existente. Se você planeja usar os gatilhos que exigem uma conta de armazenamento, deve criar a conta antes de criar o aplicativo de funções.
Criar um aplicativo sem Arquivos do Azure
O serviço Arquivos do Azure fornece um sistema de ficheiros partilhado que suporta cenários de alta escala. Quando a sua aplicação de funções é executada no Windows num plano Elastic Premium ou Consumo, uma partilha de Arquivos do Azure é criada por padrão na sua conta de armazenamento. Esse compartilhamento é usado pelo Functions para habilitar determinados recursos, como streaming de log. Ele também é usado como um local de implantação de pacote compartilhado, o que garante a consistência do código de função implantado em todas as instâncias.
Por padrão, os aplicativos de funções hospedados nos planos Premium e de Consumo usam implantação zip, com pacotes de implantação armazenados neste compartilhamento de arquivos do Azure. Essa seção é relevante apenas para esses planos de hospedagem.
O uso de Arquivos do Azure requer o uso de uma cadeia de conexão, que é armazenada nas configurações do seu aplicativo como WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Atualmente, os Arquivos do Azure não suportam ligações baseadas em identidade. Se o seu cenário exigir que você não armazene nenhum segredo nas configurações do aplicativo, você deverá remover a dependência do seu aplicativo dos Arquivos do Azure. Você pode fazer isso criando seu aplicativo sem a dependência padrão dos Arquivos do Azure.
Observação
Você também deve considerar a execução em seu aplicativo de funções no plano Flex Consumo, que está atualmente em versão prévia. O plano Flex Consumo fornece maior controle sobre o pacote de implantação, incluindo a capacidade de usar conexões de identidade gerenciadas. Para obter mais informações, veja Definir configurações de implantação no artigo Consumo Flexível.
Para executar seu aplicativo sem o compartilhamento de arquivos do Azure, você deve atender aos seguintes requisitos:
- Você deve implantar seu pacote em um contêiner de armazenamento remoto de Blobs do Azure e, em seguida, definir a URL que fornece acesso a esse pacote como a
WEBSITE_RUN_FROM_PACKAGEconfiguração do aplicativo. Essa opção permite armazenar o conteúdo do seu aplicativo no armazenamento de Blobs em vez de Arquivos do Azure, que oferece suporte a identidades gerenciadas.
Você é responsável por atualizar manualmente o pacote de implantação e manter a URL do pacote de implantação, que provavelmente contém uma assinatura de acesso compartilhado (SAS).
- Seu aplicativo não pode depender de um sistema compartilhado de arquivos graváveis.
- O aplicativo não pode usar a versão 1.x do runtime do Functions.
- 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 acima forem adequados ao seu cenário, você poderá criar um aplicativo de funções sem Arquivos do Azure. Você pode fazer isso criando um aplicativo sem as configurações de aplicativo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE. Para começar, gere um modelo ARM para uma implantação padrão, remova as duas configurações e, em seguida, implante o modelo modificado.
Como os Arquivos do Azure são usados para permitir a expansão dinâmico para Funções, o dimensionamento pode ser limitado ao executar seu aplicativo sem os Arquivos do Azure no plano Elastic Premium e nos planos de Consumo em execução no Windows.
Montar compartilhamento de arquivos
Essa funcionalidade só estará disponível quando estiver em execução no Linux.
Você pode montar compartilhamentos de arquivos existentes do Azure para os aplicativos de funções do Linux. Ao montar um compartilhamento em seu aplicativo de funções do Linux, você pode usar os modelos de machine learning existentes ou outros dados em suas funções. Use o comando a seguir para montar um compartilhamento existente para o aplicativo de funções do Linux.
az webapp config storage-account add
Nesse comando, share-name é o nome do compartilhamento de arquivos do Azure existente e 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 os scripts em Criar um aplicativo de função Python e montar um compartilhamento de Arquivos do Azure.
No momento, apenas um storage-type de AzureFiles é compatível. Só é possível montar cinco compartilhamentos para um determinado aplicativo de funções. Montar um compartilhamento de arquivos pode aumentar o tempo de inicialização a frio em pelo menos 200 a 300 ms, ou ainda mais quando a conta de armazenamento estiver em uma região diferente.
O compartilhamento montado está disponível para o código de função no mount-path especificado. Por exemplo, quando mount-path é /path/to/mount, você pode acessar o diretório de destino por APIs do sistema de arquivos, como no exemplo de Python a seguir:
import os
...
files_in_share = os.listdir("/path/to/mount")
Próximas etapas
Saiba mais sobre as opções de hospedagem do Azure Functions.