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. 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. |
1 O armazenamento de Blob é o armazenamento padrão para teclas 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 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 já protegida usando um firewall ou uma rede virtual privada ao criar seu aplicativo de função no portal do Azure. No entanto, o portal atualmente não filtra essas contas de armazenamento seguras. Para saber como usar uma conta de armazenamento segura com seu aplicativo de função, consulte Como usar uma conta de armazenamento segura com o Azure Functions.
Não é possível usar contas de armazenamento seguras com aplicativos de função hospedados 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.
Você pode criar aplicativos de função em um plano Elastic Premium ou Dedicado (Serviço de Aplicativo) usando a automação de implantação. No entanto, 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 mais informações, consulte Implantações seguras.
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.
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:
| Consideração | Armazenamento de blobs (sondagem) | Armazenamento de Blob (baseado em eventos) | Armazenamento de filas | 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 |
| 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 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. |
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.
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 Azure Files é configurado por padrão para planos de consumo Elastic Premium e não Linux para servir como um sistema de arquivos compartilhado em cenários de alta escala. O sistema de arquivos é usado pela plataforma para alguns recursos, como streaming de logs, mas garante principalmente a consistência da carga útil da função implantada. Quando um aplicativo é implantado usando uma URL de pacote externo, o conteúdo do aplicativo é servido a partir de um sistema de arquivos somente leitura separado. Isso significa que você pode criar seu aplicativo de função sem os Arquivos do Azure. Se você criar seu aplicativo de função com Arquivos do Azure, um sistema de arquivos gravável ainda será fornecido. No entanto, esse sistema de arquivos pode não estar disponível para todas as instâncias de aplicativos funcionais.
Quando os Arquivos do Azure não são usados, você deve atender aos seguintes requisitos:
- Você deve implantar a partir de uma URL de pacote externo.
- 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 itens acima forem contabilizados corretamente, você poderá criar o aplicativo sem os Arquivos do Azure. Crie o aplicativo de função sem especificar as configurações e WEBSITE_CONTENTSHARE do WEBSITE_CONTENTAZUREFILECONNECTIONSTRING aplicativo. Você pode evitar essas configurações gerando um modelo ARM para uma implantação padrão, removendo as duas configurações e, em seguida, implantando o modelo.
Como o Functions usa os Arquivos do Azure durante partes do processo de expansão dinâmica, o dimensionamento pode ser limitado ao ser executado sem os planos Arquivos do Azure no Consumo e no Elastic Premium.
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.