Considerações de armazenamento do Azure Functions

Ao criar uma instância de aplicativo de funções no Azure, você deve fornecer acesso a uma conta de Armazenamento do Azure padrão. Este diagrama e a tabela subsequente detalham como o Azure Functions usa serviços na conta de armazenamento padrão:

1. O armazenamento de blobs é o armazenamento padrão para chaves de função, mas você pode configurar um armazenamento alternativo.
2. 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, consulte 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 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. Verifique se uma conta de armazenamento existente atende 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 do Azure, você só tem permissão para 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 seu aplicativo de funções com uma conta de armazenamento protegida pela rede, você deve incluir configurações de rede específicas no modelo do ARM ou no arquivo Bicep. Quando você não inclui essas configurações e recursos, sua implantação automatizada pode falhar na validação. Para orientação sobre modelos ARM e Bicep, consulte Implantações protegidas. 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 é excluída, seu aplicativo de funções não é mais 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 seu aplicativo de funções, você deverá criar seu aplicativo de funções fora do portal do 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 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. Esse valor geralmente é 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.

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 Azurite. 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 à 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 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. 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 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, 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 dos Arquivos do Azure, definido por WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Quando essa conta de armazenamento também é protegida por uma rede virtual, todos esses aplicativos também devem usar o mesmo valor para vnetContentShareEnabled (anteriormente WEBSITE_CONTENTOVERVNET) garantir que o tráfego seja roteado consistentemente por meio da rede virtual pretendida. Uma incompatibilidade nessa configuração entre aplicativos que usam a mesma conta de armazenamento de Arquivos do Azure pode resultar em tráfego sendo roteado por meio de redes públicas. Nessa configuração, as regras de rede da conta de armazenamento bloqueiam o acesso.

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:

1. As associações de entrada e saída do Armazenamento de Blobs dão suporte a contas somente de blob.
2. 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.
3. 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

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

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. Para obter mais informações, consulte Truncamento de HostID pode causar colisões.

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, confira Sobrescrever a ID do host.

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 kubernetes habilitado para Azure Arc, seu aplicativo de funções pode não exigir uma conta de armazenamento. Nesse caso, as funções só exigem uma conta de armazenamento 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.

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 seu aplicativo de funções é executado em um plano Elastic Premium ou no Windows em um plano de consumo, um compartilhamento de Arquivos do Azure é criado por padrão em sua conta de armazenamento. As funções utilizam esse compartilhamento para ativar determinados recursos, como a transmissão 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 evitar dependências criando seu aplicativo sem a dependência padrão dos Arquivos do Azure.

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_PACKAGE configuração do aplicativo. Essa abordagem permite que você armazene o conteúdo do aplicativo no Armazenamento de Blobs em vez de arquivos do Azure, que dá suporte a identidades gerenciadas.

Você deve atualizar manualmente o pacote de implantação e manter a URL do pacote de implantação, que provavelmente contém uma SAS (assinatura de acesso compartilhado).

Você também deve observar as seguintes considerações:

• O aplicativo não pode usar a versão 1.x do runtime do Functions.
• Seu aplicativo não pode depender de um sistema compartilhado de arquivos graváveis.
• 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 de aplicativo do modelo do ARM ou do arquivo Bicep e implante o aplicativo usando o modelo modificado.
• O portal do Azure: desmarque Adicionar uma conexão de Arquivos do Azure na guia Armazenamento ao criar o aplicativo no portal do Azure.

Os Arquivos do Azure são usados para habilitar a expansão dinâmica para o Functions. O dimensionamento pode ser limitado quando você executa seu aplicativo sem o Azure Files no plano Elastic Premium e nos planos de consumo que operam 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.

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")

Artigo relacionado

Saiba mais sobre as opções de hospedagem do Azure Functions.