Considerações sobre o armazenamento das Funções do Azure
As Funções do Azure requerem uma conta de Armazenamento do Azure quando cria uma instância de aplicação de funções. Os seguintes serviços de armazenamento podem ser usados pelo seu aplicativo de função:
| Serviço de armazenamento | Utilização de funções |
|---|---|
| Armazenamento de Blobs do Azure | Manter o estado das ligações e as teclasde função 1. Origem de implantação para aplicativos executados em um plano Flex Consumption. Usado por padrão para hubs de tarefas em funções duráveis. Pode ser usado para armazenar código de aplicativo de função para compilação remota de consumo do Linux ou como parte de implantações de URL de pacote externo. |
| Arquivos doAzure 2 | Compartilhamento de arquivos usado para armazenar e executar o código do aplicativo de função em um Plano de Consumo e Plano Premium. |
| Armazenamento de filas do Azure | Usado por padrão para hubs de tarefas em funções duráveis. Usado para manipulação de falhas e novas tentativas em gatilhos específicos do Azure Functions. Usado para rastreamento de objetos pelo gatilho de armazenamento de Blob. |
| Armazenamento de tabelas do Azure | Usado por padrão para hubs de tarefas em funções duráveis. |
- O armazenamento de Blob é o armazenamento padrão para chaves de função, mas você pode configurar um armazenamento alternativo.
- 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 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çã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 criadas como parte do fluxo de criação do aplicativo de função no portal do Azure têm a garantia de funcionar com o novo aplicativo de função. 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 de função, portanto, você deve certificar-se de que uma conta de armazenamento existente atenda a esses 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.
Ao criar seu aplicativo de função no portal, você só pode escolher uma conta de armazenamento existente na mesma região do aplicativo de função que está criando. Esta é uma otimização de desempenho e não uma limitação estrita. Para saber mais, consulte Localização da conta de armazenamento.
Ao criar seu aplicativo de função em um plano com o suporte à zona de disponibilidade habilitado, 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. 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, 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 essa conta é excluída, seu aplicativo de função não é 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 por aplicativos de função.
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, por algum motivo, você precisar usar uma conta de armazenamento em uma região diferente do seu aplicativo de função, deverá criar seu aplicativo de função fora do portal.
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 padrão, os aplicativos de função configuram a AzureWebJobsStorage conexão como uma cadeia de conexão armazenada na configuração do aplicativo AzureWebJobsStorage, mas você também pode configurar AzureWebJobsStorage para usar uma conexão baseada em identidade sem um 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 . Esta é 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.
Nota
Uma cadeia de conexão de conta de armazenamento deve ser atualizada quando você regenera chaves de armazenamento. Leia mais sobre o gerenciamento de chaves de armazenamento aqui.
Contas de armazenamento compartilhadas
É possível que vários aplicativos funcionais compartilhem a mesma conta de armazenamento sem problemas. Por exemplo, no Visual Studio você pode desenvolver vários aplicativos usando o emulador de armazenamento Azurite. Neste caso, o emulador age como uma única conta de armazenamento. A mesma conta de armazenamento usada pelo aplicativo de função 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 de host.
Considerações sobre a política de gerenciamento do ciclo de vida
Você não deve aplicar políticas de gerenciamento de ciclo de vida à sua conta de armazenamento de Blob usada pelo seu aplicativo de função. O Functions usa o armazenamento de Blob para manter informações importantes, como teclas de acesso de função, e as políticas podem remover blobs (como chaves) necessários para o host do 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. Isso é particularmente importante quando você tem funções duráveis ou funções acionadas pelo Hub de eventos, 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 estão sendo armazenados pela função.
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 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) para garantir que o tráfego seja roteado consistentemente através da rede virtual pretendida. Uma incompatibilidade nessa configuração entre aplicativos que usam a mesma conta de armazenamento do Azure Files pode resultar em tráfego sendo roteado por 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, 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. Use a tabela a seguir para determinar qual gatilho de função melhor atende às suas necessidades:
| Estratégia | Contentor (sondagem) | Container (eventos) | Queue trigger | Event Grid |
|---|---|---|---|---|
| Latência | Alta (até 10 min) | Baixo | Médio | Baixo |
| Limitações da conta de armazenamento | Contas somente de blob não suportadas¹ | uso geral v1 não suportado | nenhum | uso geral v1 não suportado |
| Tipo de acionador | Armazenamento de blobs | Armazenamento de blobs | Armazenamento de filas | Event Grid |
| Versão da extensão | Qualquer | Armazenamento v5.x+ | Qualquer | Qualquer |
| Processa blobs existentes | Sim | No | No | Não |
| Filtros | Padrão de nome de blob | Filtros de eventos | n/d | Filtros de eventos |
| Requer subscrição de eventos | Não | Sim | No | Sim |
| Suporta o plano Flex Consumption | Não | Sim | Sim | Sim |
| Suporta alta escala² | Não | Sim | Sim | Sim |
| Description | Comportamento de gatilho padrão, que depende da sondagem do contêiner para atualizações. Para obter mais informações, consulte os exemplos na referência de gatilho de armazenamento de Blob. | Consome eventos de armazenamento de blob de uma assinatura de evento. Requer um Source valor de parâmetro de EventGrid. Para obter mais informações, consulte Tutorial: Acionar 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 fila para uma ligação de entrada de armazenamento de Blob na mesma função. | Fornece a flexibilidade de acionar eventos além daqueles provenientes de um contêiner de armazenamento. Use quando necessário também para que eventos que não sejam de armazenamento acionem sua função. Para obter mais informações, consulte Como trabalhar com gatilhos e associações de Grade de Eventos no Azure Functions. |
- As ligações de entrada e saída de armazenamento de Blob suportam contas somente de blob.
- 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.
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 controle adicional sobre 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 for Functions para poder acessar a conta de armazenamento. Para saber mais, consulte 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çã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.
Nota
Esse mesmo tipo de colisão de ID de host pode ocorrer entre um aplicativo de função em um slot de produção e o mesmo aplicativo de função em um slot de preparação, quando ambos os slots usam a mesma conta de armazenamento.
A partir da versão 3.x do tempo de execução do Functions, a colisão de ID do host é detetada e um aviso é registrado. Na versão 4.x, um erro é registrado e o host é interrompido, resultando em uma falha grave. Mais detalhes sobre a colisão de ID do host podem ser encontrados nesta edição.
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 Substituição de ID de host.
Importante
Alterar a conta de armazenamento associada a um aplicativo de função existente ou alterar o ID de host do aplicativo pode afetar o comportamento das funções existentes. Por exemplo, um gatilho de armazenamento de Blob rastreia se ele processou blobs individuais gravando recibos em um caminho de ID de host específico no armazenamento. Quando o ID do host muda ou você aponta para uma nova conta de armazenamento, os blobs processados anteriormente podem ser reprocessados.
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, uma conta de armazenamento pode não ser necessária para seu aplicativo de função. Nesse caso, uma conta de armazenamento só é exigida pelo Functions 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 no Windows em um plano Elastic Premium ou Consumo, um compartilhamento de Arquivos do Azure é criado por padrão em sua conta de armazenamento. Esse compartilhamento é usado pelo Functions 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 fazer isso criando seu aplicativo sem a dependência padrão dos Arquivos do Azure.
Nota
Você também deve considerar a execução em seu aplicativo de função no plano Flex Consumption, que está atualmente em visualização. O plano Flex Consumption fornece maior controle sobre o pacote de implantação, incluindo a capacidade de usar conexões de identidade gerenciadas. Para obter mais informações, consulte Definir configurações de implantação no artigo Consumo do Flex.
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_PACKAGEaplicativo. Essa opção 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ê é 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 de arquivos gravável compartilhado.
- O aplicativo não pode usar a versão 1.x do tempo de execução do Functions.
- 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 acima se adequarem ao seu cenário, você poderá continuar a criar um aplicativo funcional sem os Arquivos do Azure. Você pode fazer isso criando um aplicativo sem as configurações e WEBSITE_CONTENTSHARE do WEBSITE_CONTENTAZUREFILECONNECTIONSTRING aplicativo. Para começar, gere um modelo ARM para uma implantação padrão, remova as duas configurações e implante o modelo modificado.
Como os Arquivos do Azure são usados para habilitar a expansão dinâmica para o Functions, 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 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.
az webapp config storage-account add
Neste comando, share-name é o nome do compartilhamento existente de Arquivos do Azure e custom-id pode ser qualquer cadeia de caracteres que define exclusivamente o compartilhamento quando montado no aplicativo de função. Além disso, mount-path é o caminho a partir do qual o compartilhamento é acessado em seu aplicativo de função. mount-path deve estar no formato /dir-namee 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.
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")
Próximos passos
Saiba mais sobre as opções de hospedagem do Azure Functions.