Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Quando cria uma instância de function app no Azure, deve fornecer acesso a uma conta padrão do Armazenamento do Azure. O diagrama e a tabela seguintes detalham como o Funções do Azure utiliza os serviços na conta de armazenamento predefinida.
Selecione o seu plano de alojamento no topo deste artigo para ver as orientações de armazenamento que se aplicam à sua aplicação funcional.
| Serviço de armazenamento | Utilização de funções |
|---|---|
| Azure Blob Storage | Manter o estado das ligações e as teclas de função1. Origem de implantação para aplicações executadas num Flex Consumption plan. Usado por padrão para hubs de tarefas no Durable Functions. Pode ser usado para armazenar código de aplicativo de função para compilação remota na plataforma de Consumo do Linux ou como parte de implantação por URL de pacotes externos. |
| Ficheiros do Azure2 | Partilha de ficheiros usada para armazenar e executar o código da aplicação de funções em um Plano de Consumo e Plano Premium. Mantenha pacotes de extensão. Armazene logs de implantação. Suporta dependências gerenciadas no PowerShell. |
| Azure Fila de Armazenamento | Usado por padrão para hubs de tarefas no Durable Functions. Usado para o gerenciamento de falhas e tentativas em gatilhos específicos do Funções do Azure |
| Azure Armazenamento de tabelas | Usado por padrão para hubs de tarefas no Durable Functions. Usado para rastrear eventos de diagnóstico. |
- O armazenamento de Blob é o armazenamento padrão para chaves de função, mas você pode configurar um armazenamento alternativo.
- Ficheiros do Azure está configurado por defeito, mas pode criar uma aplicação sem Ficheiros do Azure sob certas condições.
Considerações importantes
Considere os seguintes factos relativamente às contas de armazenamento usadas pelas suas aplicações funcionais:
Quando aloja a sua aplicação de funções no plano Consumption (Windows) ou no plano Premium, armazena o seu código de função e ficheiros de configuração no Ficheiros do Azure na conta de armazenamento ligada. Se apagares essa conta de armazenamento, apagas permanentemente o conteúdo. Para obter mais informações, consulte A conta de armazenamento foi excluída.
A conta de armazenamento mantém dados importantes, como código de função, chaves de acesso e outros dados importantes relacionados com o serviço. 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 registos de armazenamento num local diferente do Armazenamento do Azure. Para obter mais informações, consulte registos de armazenamento.
Se usar Durable Functions, o armazenamento do hub de tarefas é especialmente sensível à segurança porque o acesso de escrita pode ser usado para alterar o comportamento da aplicação, incluindo desencadear a execução arbitrária de código. Para mais informações, consulte Proteger o armazenamento do seu centro de tarefas.
Requisitos da conta de armazenamento
As contas de armazenamento que crias durante o processo de criação da app de funções no portal do 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. Garantir que uma conta de armazenamento existente cumpre estes requisitos:
- Você não pode usar uma conta de armazenamento protegida pela rede quando seu aplicativo de função está hospedado no plano de consumo.
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 para blobs e "Azure Armazenamento Premium". Para saber mais sobre os tipos de conta de armazenamento, consulte Visão geral da conta de armazenamento.
Quando cria a sua aplicação de funções no portal do Azure, só pode escolher uma conta de armazenamento existente na mesma região da aplicação de funções que criou. 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.
Quando utiliza a automação de implementação para criar a sua aplicação de funções com uma conta de armazenamento segura em rede, deve incluir configurações específicas de rede no seu modelo ARM ou ficheiro Bicep. Se não incluir estas definições e recursos, a sua implementação automática pode falhar na validação. Para templates ARM e orientações sobre o Bicep, consulte Implantações seguras. Para uma visão geral sobre a configuração de contas de armazenamento com rede, consulte Como usar uma conta de armazenamento segura com Funções do Azure.
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 Azure aplica esta melhor prática. Se precisares de usar uma conta de armazenamento numa região diferente da tua app de funções, tens de criar a tua app de funções fora do portal do 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 padrão, as aplicações de funções configuram a ligação AzureWebJobsStorage 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.
Aplicações funcionais a correr num plano Consumption (apenas Windows) ou num plano Elastic Premium (Windows ou Linux) podem usar o Ficheiros do Azure para armazenar as imagens necessárias para permitir a escalabilidade dinâmica. Para estes planos, defina a cadeia de conexão da conta de armazenamento na configuração WEBSITE_CONTENTAZUREFILECONNECTIONSTRING e o nome da partilha de ficheiros na configuração WEBSITE_CONTENTSHARE. Esse valor geralmente é a mesma conta usada para AzureWebJobsStorage. Também podes criar uma aplicação de funções que não use Ficheiros do Azure, mas a escala pode ser limitada.
Nota
Tem de atualizar a cadeia de conexão de uma conta de armazenamento quando regenera as chaves de armazenamento. Para mais informações, consulte Criar uma conta de armazenamento Azure.
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 Armazenamento de Blobs 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 registos de recursos do Azure Monitor podem ser usados para acompanhar eventos contra o plano de dados de armazenamento. Consulte Monitoring Armazenamento do Azure para detalhes sobre como configurar e examinar estes logs.
O registo de atividade do Azure Monitor mostra eventos do plano de controlo, 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 permissões de armazenamento de âmbito amplo, considere usar um destino não armazenado para estes registos, como o Log Analytics. Para mais informações, consulte Monitorizaçã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. Esta abordagem é particularmente importante quando se têm funções desencadeadas por Durable Functions ou Event Hubs, que geram ambos um elevado volume de transações de armazenamento. Quando a lógica da tua aplicação interage com o Armazenamento do Azure, seja diretamente (usando o Storage SDK) ou através de uma das ligações de armazenamento, deves 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
Aplicações com múltiplas funções alojadas no mesmo plano também podem usar a mesma conta de armazenamento para a Ficheiros do Azure partilha de conteúdo, definida por WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Quando protege esta conta de armazenamento usando uma rede virtual, todas estas aplicações (incluindo slots) devem usar o mesmo valor para vnetContentShareEnabled (anteriormente WEBSITE_CONTENTOVERVNET) e a mesma configuração de integração de rede virtual para garantir que o tráfego é encaminhado de forma consistente através da rede virtual pretendida. Um desajuste nesta configuração entre aplicações que usam a mesma conta de armazenamento Ficheiros do Azure 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.
A vnetContentShareEnabled orientação não se aplica ao Flex Consumption, Dedicated, Container Apps ou Consumption Hosting.
Trabalhando com blobs
Um cenário-chave para Functions é o processamento de ficheiros num contêiner de blobs, como para processamento de imagens 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.
| Estratégia | Gatilho de blob (sondagem) | Gatilho de Blob (acionado por eventos) | Disparador de fila | Gatilho de grade de eventos |
|---|---|---|---|---|
| Latência | Alta (até 10 min) | Baixo | Médio | Baixo |
| Limitações da conta de armazenamento | Não suporta contas só de blobs¹ nem contas com o espaço de nomes hierárquico (HNS) ativado, como as contas do Azure Data Lake Storage Gen2 | Não suporta contas de uso geral v1 | None | Não suporta contas de uso geral v1 |
| Tipo de acionador | Blob Storage | Blob Storage | Armazenamento de filas | Grelha de Eventos |
| Versão da extensão | Qualquer | Armazenamento v5.x+ | Qualquer | Qualquer |
| Processa blobs existentes | Sim | Não | Não | Não |
| Filtros | Padrão de nome para blob | Filtros de eventos | n/d | Filtros de eventos |
| Requer subscrição de eventos | Não | Sim | Não | Sim |
| Suporta plano de Consumo Flexível | Não | Sim | Sim | Sim |
| Suporta grande escala² | Não | Sim | Sim | Sim |
| Funciona com restrições de acesso de entrada | Sim | Não | Sim | Sim3 |
| Descrição | 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 Blob. | Consome eventos de armazenamento de blob de uma assinatura de evento. Requer um Source valor de parâmetro de EventGrid. Para mais informações, veja Tutorial: Acionar Funções do Azure em contentores de blob usando uma subscrição para eventos. |
A cadeia de caracteres do nome do blob é adicionada manualmente a uma fila de armazenamento quando um blob é adicionado ao contentor. Um gatilho de armazenamento em fila passa esse valor diretamente para uma associação de entrada de armazenamento de Blob na mesma função. | Fornece a flexibilidade de acionar eventos além daqueles eventos que vêm de um contêiner de armazenamento. Use quando for necessário que eventos não relacionados ao armazenamento também acionem a sua função. Para mais informações, veja Como trabalhar com gatilhos e ligações da Grelha de Eventos em Funções do Azure. |
- A limitação da conta apenas para blobs aplica-se apenas ao gatilho de armazenamento Blob baseado em polling. As ligações de entrada e saída de armazenamento de Blob suportam contas somente de blob.
- Alta escala pode ser vagamente definida como contentores que contêm mais de 100.000 blobs ou contas de armazenamento que recebem mais de 100 atualizações de blob por segundo.
- 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 encripta todos os dados numa conta de armazenamento em repouso. Para mais informações, consulte Armazenamento do Azure encriptação para dados em repouso.
Por defeito, os dados são encriptados com chaves geridas 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. Estas chaves devem estar presentes no Azure Key Vault para que as Funções possam aceder à 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 tiverem de permanecer numa única região, utilize uma conta de armazenamento associada à aplicação de função que tenha redundância dentro da região. Também usa uma conta de armazenamento redundante dentro da região com Azure Durable Functions.
A plataforma armazena outros dados de cliente geridos pela plataforma apenas na região quando aloja a aplicação num Ambiente do Serviço de Aplicações (ASE) com balanceamento de carga interno. Para saber mais, consulte Redundância de zona ASE.
Considerações sobre o ID do host
As considerações sobre o ID do host nesta secção não se aplicam ao Consumo Flex. Neste plano de alojamento, o valor do ID do host é criado de forma a evitar estes potenciais problemas.
O Functions utiliza um valor de ID de host para identificar de forma única uma aplicação de funções específica em artefactos armazenados. Por predefinição, o ambiente de execução gera automaticamente este ID a partir do nome da aplicação de funções, truncado aos primeiros 32 caracteres. O runtime utiliza este ID ao armazenar informação de correlação e rastreio por aplicação na conta de armazenamento ligada. Quando as aplicações de funções têm nomes com mais de 32 caracteres e os primeiros 32 caracteres são idênticos, esta truncação pode resultar em valores duplicados do ID do host. Quando duas aplicações de função com IDs de host idênticos usam a mesma conta de armazenamento, ocorre uma colisão de ID de host porque os dados armazenados não podem ser ligados de forma única à aplicação de função correta.
Nota
O mesmo tipo de colisão do ID do anfitrião pode ocorrer entre uma aplicação de funções num slot de produção e a mesma aplicação de funções num slot de teste, quando ambos os slots utilizam a mesma conta de armazenamento.
Na versão 4.x do runtime Functions, regista-se um erro e o host para, resultando numa falha total. Para mais informações, veja Truncação do HostID pode causar colisões.
Evitando colisões de ID do host
Utilize as seguintes estratégias para evitar colisões de IDs de anfitrião:
- Use contas de armazenamento separadas para que cada host em colisão escreva numa conta diferente.
- Renomeie uma das suas aplicações de funções para que tenha um nome com menos de 32 caracteres, o que altera o ID de anfitrião calculado da aplicação e elimina 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.
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 acionador do Armazenamento de Blobs controla se processa blobs individuais ao gravar registos num caminho específico do ID do anfitrião no armazenamento. Quando o ID do host é alterado ou o utilizador especifica uma nova conta de armazenamento, os blobs processados anteriormente podem ser reprocessados.
Substituir o ID do host
Pode definir um ID de host explícito para a sua aplicação de funções nas definições da aplicação usando a AzureFunctionsWebHost__hostid definição. Para obter mais informações, consulte AzureFunctionsWebHost__hostid.
Quando ocorre uma colisão entre slots, 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.
Criar uma aplicação sem Ficheiros do Azure
O serviço Ficheiros do Azure fornece um sistema de ficheiros partilhado que suporta cenários de grande escala. Quando a sua aplicação de funções corre num plano Elastic Premium ou no Windows num plano de Consumo, uma partilha Ficheiros do Azure é criada por defeito na sua conta de armazenamento. As funções podem usar esta partilha para funcionalidades como streaming de registos e como localização partilhada de conteúdo da aplicação. O local de implementação depende da tecnologia de implementação e da configuração da aplicação. Por exemplo, uma aplicação que utiliza uma URL de pacote externa executa o seu pacote a partir da URL configurada em vez da partilha Ficheiros do Azure.
A utilização do Ficheiros do Azure requer uma cadeia de ligação, que armazena nas definições da aplicação como WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. O Ficheiros do Azure atualmente não suporta ligações baseadas em identidade. Se o seu cenário exigir que não armazene quaisquer segredos nas definições da app, deve remover a dependência da sua app do Ficheiros do Azure. Pode evitar esta dependência criando a sua aplicação sem a dependência padrão do Ficheiros do Azure.
Nota
Deve também considerar executar a sua aplicação de funções no plano Flex Consumption, que oferece maior controlo sobre o pacote de implementação, incluindo a possibilidade de usar ligações de identidade geridas. Para obter mais informações, consulte Definir configurações de implantação.
Para executar a sua aplicação sem a partilha Ficheiros do Azure, deve cumprir os seguintes requisitos:
Deve implementar o seu pacote num contentor do Armazenamento de Blobs do Azure que não permita acesso anónimo e definir a URL Armazenamento de Blobs do pacote como
WEBSITE_RUN_FROM_PACKAGEconfiguração da aplicação.Para evitar armazenar uma credencial de implementação no URL do pacote, conceda à identidade gerida da aplicação de funções acesso ao pacote. Quando utiliza uma identidade atribuída pelo utilizador, também defina
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID. Se não conseguir usar a identidade gerida, use uma URL de assinatura de acesso partilhada (SAS) e renove-a antes que o SAS expire.Para remover a cadeia de ligação da conta de armazenamento padrão do host das definições da tua app, configura
AzureWebJobsStoragepara usar uma identidade gerida.Deve atualizar manualmente o pacote de implementação e manter o URL do pacote de implementação. Para informações sobre como reiniciar a aplicação e sincronizar os gatilhos quando atualiza o pacote, veja Executar a partir de um URL de pacote externo.
Você também deve observar as seguintes considerações:
- A sua aplicação não pode depender de um sistema de ficheiros partilhado e gravável.
- A edição do portal não é suportada.
- As experiências de streaming de logs em clientes, como o portal do Azure, padrão utilizam os logs do sistema de ficheiros. Em vez disso, você deve confiar nos logs do Application Insights.
Se os requisitos anteriores se adequarem ao seu cenário, pode avançar para criar uma aplicação de funções sem o Ficheiros 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 definições da aplicação do modelo ARM ou do ficheiro Bicep e depois implemente a aplicação usando o modelo modificado.
- O portal do Azure: desmarque Adicionar uma ligação aos Ficheiros do Azure no separador Armazenamento ao criar a aplicação no portal do Azure.
O Ficheiros do Azure é usado para permitir a escalonação dinâmica de Funções. A escalabilidade pode ser limitada quando executa a sua aplicação sem o serviço Ficheiros do Azure no plano Elastic Premium e nos planos de Consumo em execução no Windows.
O Flex Consumption não depende de uma partilha de conteúdo do Ficheiros do Azure. Utiliza armazenamento Blob configurável para implementação e suporta ligações com identidade gerida. Para obter mais informações, consulte Definir configurações de implantação.
As aplicações dedicadas de planos não têm a dependência padrão de partilha de conteúdo do Ficheiros do Azure descrita nesta secção.
As funções no Azure Container Apps não têm a dependência padrão de partilha de conteúdo do Ficheiros do Azure descrita nesta secção.
Montar compartilhamentos de arquivos
Esta funcionalidade está disponível apenas quando a correr em Linux.
Pode montar partilhas Ficheiros do Azure nas suas aplicações de funções Linux, que pode usar para aceder a ficheiros existentes, modelos de aprendizagem automática ou grandes binários nas suas funções. Para orientações conceptuais sobre a escolha entre montagens de armazenamento, bindings e bases de dados externas, veja Escolha uma estratégia de acesso a ficheiros para Funções do Azure.
O Flex Consumption suporta apenas montagens do Ficheiros do Azure através de Server Message Block (SMB).
Use o seguinte comando para montar uma partilha existente na sua aplicação de funções Linux.
az webapp config storage-account add (adiciona uma nova conta de armazenamento à configuração do webapp)
Neste comando, share-name é o nome da partilha Ficheiros do Azure existente.
custom-id pode ser qualquer sequência de caracteres que defina de forma exclusiva a partilha quando montada na aplicação 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 um exemplo completo, veja Crie uma aplicação de Python função e monte uma partilha de Ficheiros do Azure.
Para Funções no Azure Container Apps, configure um volume Ficheiros do Azure na aplicação container. Para mais informações, consulte Utilizar montagens de armazenamento nas Azure Container Apps.
Montagens de armazenamento não são suportadas no plano de Consumo.
Importante
As aplicações funcionais que ainda estão a correr o runtime final de vida v3 no Linux num plano de Consumo deixam de funcionar após 30 de setembro de 2026. Para evitar interrupções no serviço, migre a sua aplicação para o runtime da v4.
A opção de alojar aplicações funcionais no Linux num plano Consumption será retirada a 30 de setembro de 2028. O plano Linux Consumption não está a receber novas funcionalidades nem versões de linguagem. As aplicações a correr no Windows num plano de Consumo não estão atualmente afetadas. Migre as suas aplicações para o plano Flex Consumption antes da data de reforma.