Considerações sobre o armazenamento das Funções do Azure

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

1. O armazenamento de Blob é o armazenamento padrão para chaves de função, mas você pode configurar um armazenamento alternativo.
2. Os Arquivos do Azure são configurados por padrão, mas você pode criar um aplicativo sem os Arquivos do Azure sob determinadas condições.

Considerações importantes

Você deve considerar fortemente os seguintes fatos em relação às contas de armazenamento usadas por seus aplicativos de função:

• Quando seu aplicativo de função é hospedado no plano de consumo ou plano Premium, seu código de função e arquivos de configuração são armazenados em Arquivos do Azure na conta de armazenamento vinculada. Quando elimina esta conta de armazenamento, o conteúdo é eliminado e não pode 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 com serviços, permanecem na conta de armazenamento. Você deve gerenciar cuidadosamente o acesso às contas de armazenamento usadas pelos aplicativos de função 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 de permissão para executar a operação listKeys.

  • Monitore a atividade do plano de controle (como recuperar chaves) e as operações do plano de dados (como gravar em um blob) em sua conta de armazenamento. Considere manter os logs de armazenamento em um local diferente do Armazenamento do Azure. Para obter mais informações, consulte Logs de armazenamento.

Requisitos da conta de armazenamento

As contas de armazenamento que crias durante o processo de criação da app de funções no portal Azure funcionam com a nova aplicação 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 seu aplicativo funcional. Verifique se uma conta de armazenamento existente atende a estes requisitos:

• O tipo de conta deve suportar armazenamento de Blob, Fila e Tabela. Algumas contas de armazenamento não suportam filas e tabelas. Estas contas incluem contas de armazenamento apenas de blobs e Armazenamento Premium do Azure. Para saber mais sobre os tipos de conta de armazenamento, consulte Visão geral da conta de armazenamento.

• Você não pode usar uma conta de armazenamento protegida pela rede quando seu aplicativo de função está hospedado no plano de consumo.

• Quando crias a tua aplicação de funções no portal Azure, só podes escolher uma conta de armazenamento existente na mesma região da aplicação de funções que criaste. Este requisito é uma otimização de desempenho e não uma limitação estrita. Para saber mais, consulte Localização da conta de armazenamento.

• Quando o utilizador cria a sua aplicação de função num plano com suporte à zona de disponibilidade ativado, apenas contas de armazenamento com redundância de zona são suportadas.

Ao usar a automação de implantação para criar seu aplicativo de função com uma conta de armazenamento protegida por rede, você deve incluir configurações de rede específicas em seu modelo ARM ou arquivo Bicep. Se não incluir estas definições e recursos, a sua implementação automática pode falhar na validação. Para obter orientação sobre o modelo ARM e o 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 segura com o Azure Functions.

Diretrizes para contas de armazenamento

Cada aplicativo de função requer uma conta de armazenamento para operar. Quando apagas essa conta, a tua app de funções deixa de funcionar. Para solucionar problemas relacionados ao armazenamento, consulte Como solucionar problemas relacionados ao armazenamento. As seguintes considerações aplicam-se à conta de armazenamento utilizada pelas aplicações de funções.

Localização da conta de armazenamento

Para obter o melhor desempenho, seu aplicativo de função 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 precisar de usar uma conta de armazenamento numa região diferente da sua aplicação de funções, deve criar a sua aplicação de funções fora do portal Azure.

A conta de armazenamento deve estar acessível ao aplicativo de função. Se você precisar usar uma conta de armazenamento segura, considere restringir sua conta de armazenamento a uma rede virtual.

Configuração de conexão da conta de armazenamento

Por defeito, as aplicações funcionais configuram a AzureWebJobsStorage ligação como uma cadeia de ligação armazenada na configuração da aplicação AzureWebJobsStorage. Também pode configurar o AzureWebJobsStorage para usar uma ligação baseada em identidade sem segredo.

Os aplicativos de função executados 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ção que não use Arquivos do Azure, mas o dimensionamento pode ser limitado.

Contas de armazenamento compartilhadas

Várias aplicações funcionais podem partilhar a mesma conta de armazenamento sem qualquer problema. Por exemplo, no Visual Studio, pode desenvolver várias aplicações usando o emulador de armazenamento Azurite. Neste caso, o emulador age como uma única conta de armazenamento. A mesma conta de armazenamento que a sua aplicação de funções usa também pode armazenar os dados da sua aplicação. 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 de host.

Considerações sobre a política de gerenciamento do ciclo de vida

Não aplique políticas de gestão do ciclo de vida à sua conta Blob Storage usada pela sua aplicação de funções. O Functions usa o armazenamento de Blob para manter informações importantes, como teclas de acesso de função. As políticas podem remover blobs, como chaves, necessários para o host Functions. Se você precisar usar políticas, exclua os contêineres usados pelo Functions, que são prefixados com 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 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 rastrear eventos no plano de dados de armazenamento. Consulte Monitorando o Armazenamento do Azure para obter detalhes sobre como configurar e examinar esses logs.

O log de atividades do 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 controlar 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 poder 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 o uso de um destino que não seja de armazenamento para esses logs, como o Log Analytics. Para obter mais informações, consulte Monitorando o Armazenamento de Blobs do Azure.

Otimizar o desempenho de armazenamento

Para maximizar o desempenho, use uma conta de armazenamento separada para cada aplicativo de função. Essa abordagem é particularmente importante quando você tem funções duráveis ou Hubs de eventos acionados, que geram um alto volume de transações de armazenamento. Quando a lógica do aplicativo interage com o 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 acionada pelo hub de eventos gravando alguns dados no armazenamento de blobs, use duas contas de armazenamento: uma para o aplicativo de função e outra para os blobs que a função armazena.

Roteamento consistente através de redes virtuais

Vários aplicativos de função hospedados no mesmo plano também podem usar a mesma conta de armazenamento para o compartilhamento de conteúdo dos Arquivos do Azure, definido pelo WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Quando protege esta conta de armazenamento usando uma rede virtual, todas estas aplicações devem usar 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 nesta configuração entre aplicações que usam a mesma conta de armazenamento Azure Files pode resultar no encaminhamento de tráfego através 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, consulte Processar carregamentos 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 disparador de função melhor atende às suas necessidades para processar blobs que foram adicionados ou atualizados num contentor.

1. As ligações de entrada e saída de armazenamento de Blob suportam contas somente de blob.
2. Alta escala pode ser vagamente definida como contêineres que têm mais de 100.000 blobs ou contas de armazenamento que têm mais de 100 atualizações de blob por segundo.
3. Você pode contornar as restrições de acesso de entrada fazendo com que a assinatura do evento entregue eventos em 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 de dados de armazenamento

O Armazenamento do Azure criptografa todos os dados em uma conta de armazenamento em repouso. Para obter mais informações, consulte Encriptação do Armazenamento do Microsoft Azure para dados inativos.

Por padrão, os dados são criptografados com chaves gerenciadas pela Microsoft. Para obter mais controlo sobre chaves de criptografia, pode-se fornecer chaves geridas pelo cliente a utilizar na criptografia de dados blob e de ficheiros. Essas chaves devem estar presentes no Azure Key Vault for Functions para poder 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ção 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 de clientes gerenciados pela plataforma só são armazenados na região ao hospedar em um ambiente de serviço de aplicativo (ASE) com balanceamento de carga interno. Para saber mais, consulte Redundância de zona ASE.

Considerações sobre o ID do host

O Functions usa um valor de ID de host como uma maneira de identificar exclusivamente um aplicativo de função específico em artefatos armazenados. Por padrão, essa ID é gerada automaticamente a partir do nome do aplicativo de função, truncado para os primeiros 32 caracteres. Esse ID é usado ao armazenar informações de correlação e rastreamento por aplicativo na conta de armazenamento vinculada. Quando você tem aplicativos de função com nomes maiores que 32 caracteres e quando os primeiros 32 caracteres são idênticos, esse truncamento pode resultar em valores de ID de host duplicados. Quando dois aplicativos de função com IDs de host idênticos 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ção correto.

Na versão 4.x do runtime Functions, é registado um erro e o host é parado, resultando numa falha total. Para obter mais informações, consulte O 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 de host:

• Use uma conta de armazenamento separada para cada função, aplicativo ou slot envolvido na colisão.
• Renomeie um dos seus aplicativos de função para um valor inferior a 32 caracteres de comprimento, o que altera o ID de host computado para o aplicativo e remove a colisão.
• Defina um ID de host explícito para um ou mais dos aplicativos em colisão. Para saber mais, consulte Substituir o ID do host.

Substituir o ID do host

Você pode definir explicitamente um ID de host específico para seu aplicativo de função nas configurações do aplicativo usando a AzureFunctionsWebHost__hostid configuração. Para obter mais informações, consulte AzureFunctionsWebHost__hostid.

Quando a colisão ocorre 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 configurações de aplicativo.

Clusters habilitados para Azure Arc

Quando seu aplicativo de função é implantado em um cluster Kubernetes habilitado para Azure Arc, seu aplicativo de função pode não exigir uma conta de armazenamento. Nesse caso, as funções só exigem uma conta de armazenamento quando seu aplicativo de função 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ção em um cluster 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 az --version comando para verificar se a extensão está instalada e se é a versão correta.

Criar seus recursos de aplicativo de função usando métodos diferentes da CLI do Azure requer uma conta de armazenamento existente. Se você planeja usar quaisquer gatilhos que exijam uma conta de armazenamento, crie a conta antes de criar o aplicativo de função.

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 seu aplicativo de função é 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 usam esse compartilhamento para habilitar determinados recursos, como o streaming de logs. Ele também é usado como um local de implantação de pacote compartilhado, o que garante a consistência do código da função implantada em todas as instâncias.

Por padrão, os aplicativos de função hospedados nos planos Premium e de Consumo usam a implantação zip, com pacotes de implantação armazenados neste compartilhamento de arquivos do Azure. Esta seção é relevante apenas para esses planos de hospedagem.

Usar 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 oferecem suporte a conexõ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 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 de Blob do Azure remoto e, em seguida, definir a URL que fornece acesso a esse pacote como a configuração do WEBSITE_RUN_FROM_PACKAGE aplicativo. Essa abordagem permite armazenar o conteúdo do aplicativo no armazenamento de Blob em vez dos Arquivos do Azure, que dão 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 assinatura de acesso compartilhado (SAS).

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

• O aplicativo não pode usar a versão 1.x do tempo de execução do Functions.
• Seu aplicativo não pode depender de um sistema de arquivos gravável compartilhado.
• A edição do portal não é suportada.
• Registre experiências de streaming em clientes, como o portal do Azure padrão para logs do sistema de arquivos. Em vez disso, você deve confiar nos logs do Application Insights.

Se os requisitos anteriores se adequarem ao seu cenário, você poderá continuar a criar um aplicativo funcional sem os Arquivos do Azure. Crie uma aplicação sem as definições WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e WEBSITE_CONTENTSHARE da aplicação de uma destas maneiras:

• Modelos Bicep/ARM: remova as duas configurações do aplicativo do modelo 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 o aplicativo é executado sem o uso de Azure Files nos planos Elastic Premium e de Consumo em execução no Windows.

Montar compartilhamentos de arquivos

Esta funcionalidade só está disponível quando executada no Linux.

Você pode montar compartilhamentos existentes do Azure Files em seus aplicativos de função Linux. Ao montar um compartilhamento em seu aplicativo de função Linux, você pode usar modelos de aprendizado de máquina existentes ou outros dados em suas funções.

Você pode usar o seguinte comando para montar um compartilhamento existente em seu aplicativo de função Linux.

Atualmente, apenas um storage-type dos é suportado AzureFiles . Você só pode montar cinco compartilhamentos em um determinado aplicativo de função. A montagem de um compartilhamento de arquivos pode aumentar o tempo de inicialização a frio em pelo menos 200-300 ms, ou até mais quando a conta de armazenamento está em uma região diferente.

O compartilhamento montado está disponível para seu 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 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.