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.
O gatilho Blob storage inicia uma função quando é detetado um blob novo ou atualizado. O conteúdo do blob é fornecido como entrada para a função.
Gorjeta
Existem várias formas de executar o código da sua função com base nas alterações a blobs num contentor de storage. Se optar por usar o gatilho Blob storage, existem duas implementações disponíveis: uma baseada em polling (referida neste artigo) e outra baseada em eventos. É recomendável usar a implementação baseada em eventos, pois ela tem latência menor do que a outra. Além disso, o plano Flex Consumption suporta apenas o gatilho de Blob storage baseado em eventos.
Para detalhes sobre as diferenças entre as duas implementações do gatilho de Blob storage, bem como outras opções de disparo, consulte Trabalhar com blobs.
Para informações sobre a configuração e detalhes de configuração, consulte a visão geral .
Importante
Este artigo usa guias para oferecer suporte a várias versões do modelo de programação Node.js. O modelo v4 está geralmente disponível e foi projetado para ter uma experiência mais flexível e intuitiva para desenvolvedores JavaScript e TypeScript. Para mais detalhes sobre como funciona o modelo v4, consulte o guia para desenvolvedores Azure Functions Node.js. Para saber mais sobre as diferenças entre v3 e v4, consulte o guia de migração.
O Azure Functions suporta dois modelos de programação para Python. A maneira como você define suas ligações depende do modelo de programação escolhido.
O modelo de programação Python v2 permite definir ligações usando decoradores diretamente em seu código de função Python. Para obter mais informações, consulte o guia do desenvolvedor do Python.
Este artigo suporta ambos os modelos de programação.
Exemplo
Uma função C# pode ser criada usando um dos seguintes modos C#:
-
Modelo de trabalho isolado: função C# compilada que é executada em um processo de trabalho isolado do tempo de execução. É necessário um processo trabalhador isolado para suportar funções C# a correr em versões LTS e não-LTS, como .NET e o framework .NET. Extensões para funções de processos trabalhadores isolados usam espaços de nomes
Microsoft.Azure.Functions.Worker.Extensions.*. -
Modelo em processo: função C# compilada que é executada no mesmo processo que o tempo de execução do Functions. Em uma variação desse modelo, as funções podem ser executadas usando scripts em C#, que são suportados principalmente para edição de portal em C#. Extensões para funções em processo utilizam espaços de nomes
Microsoft.Azure.WebJobs.Extensions.*.
Importante
O Suporte para o modelo em processo terminará a 10 de novembro de 2026. Recomendamos vivamente que migre as suas aplicações para o modelo de trabalhador isolado para suporte total.
O exemplo a seguir é uma função C# que é executada em um processo de trabalho isolado e usa um gatilho de blob com ligações de blob de entrada e saída de blob. A função é acionada pela criação de um blob no contêiner test-samples-trigger . Ele lê um arquivo de texto do contêiner test-samples-input e cria um novo arquivo de texto em um contêiner de saída com base no nome do arquivo acionado.
public static class BlobFunction
{
[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
[BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
[BlobInput("test-samples-input/sample1.txt")] string myBlob,
FunctionContext context)
{
var logger = context.GetLogger("BlobFunction");
logger.LogInformation("Triggered Item = {myTriggerItem}", myTriggerItem);
logger.LogInformation("Input Item = {myBlob}", myBlob);
// Blob Output
return "blob-output content";
}
}
Esta função usa uma matriz de bytes para gravar um log quando um blob é adicionado ou atualizado no myblob contêiner.
Baseado em sondagens:
O exemplo seguinte utiliza o gatilho de sondagem por defeito:
@FunctionName("blobprocessor")
public void run(
@BlobTrigger(name = "file",
dataType = "binary",
path = "myblob/{name}",
connection = "MyStorageAccountAppSetting") byte[] content,
@BindingName("name") String filename,
final ExecutionContext context
) {
context.getLogger().info("Name: " + filename + " Size: " + content.length + " bytes");
}
O exemplo seguinte utiliza um gatilho de grelha de eventos:
@FunctionName("blobprocessor")
public void run(
@BlobTrigger(name = "file",
dataType = "binary",
path = "myblob/{name}",
source = "EventGrid",
connection = "MyStorageAccountAppSetting") byte[] content,
@BindingName("name") String filename,
final ExecutionContext context
) {
context.getLogger().info("Name: " + filename + " Size: " + content.length + " bytes");
}
Este exemplo do tipo SDK usa BlobClient para access propriedades do blob.
@FunctionName("processBlob")
public void run(
@BlobTrigger(
name = "content",
path = "images/{name}",
connection = "AzureWebJobsStorage") BlobClient blob,
@BindingName("name") String file,
ExecutionContext ctx)
{
ctx.getLogger().info("Size = " + blob.getProperties().getBlobSize());
}
Este exemplo SDK usa BlobContainerClient para access informação sobre blobs no contentor que desencadeou a função.
@FunctionName("containerOps")
public void run(
@BlobTrigger(
name = "content",
path = "images/{name}",
connection = "AzureWebJobsStorage") BlobContainerClient container,
ExecutionContext ctx)
{
container.listBlobs()
.forEach(b -> ctx.getLogger().info(b.getName()));
}
Este exemplo de tipos de SDK usa BlobClient para obter informações da associação de entrada sobre o blob que disparou a execução.
@FunctionName("checkAgainstInputBlob")
public void run(
@BlobInput(
name = "inputBlob",
path = "inputContainer/input.txt") BlobClient inputBlob,
@BlobTrigger(
name = "content",
path = "images/{name}",
connection = "AzureWebJobsStorage",
dataType = "string") String triggerBlob,
ExecutionContext ctx)
{
ctx.getLogger().info("Size = " + inputBlob.getProperties().getBlobSize());
}
Este exemplo mostra como obter o BlobClient tanto de um Storage Blob trigger como da ligação de entrada num trigger HTTP:
import "@azure/functions-extensions-blob"; // This is the mandatory first import for SDK binding
import { StorageBlobClient } from "@azure/functions-extensions-blob";
import { app, InvocationContext } from "@azure/functions";
export async function storageBlobTrigger(
blobStorageClient: StorageBlobClient, // SDK binding provides this client
context: InvocationContext
): Promise<void> {
context.log(`Blob trigger processing: ${context.triggerMetadata.name}`);
// Access to full SDK capabilities
const blobProperties = await blobStorageClient.blobClient.getProperties();
context.log(`Blob size: ${blobProperties.contentLength}`);
// Download blob content
const downloadResponse = await blobStorageClient.blobClient.download();
context.log(`Content: ${downloadResponse}`);
}
// Register the function
app.storageBlob("storageBlobTrigger", {
path: "snippets/{name}",
connection: "AzureWebJobsStorage",
sdkBinding: true, // Enable SDK binding
handler: storageBlobTrigger,
});
Este exemplo mostra como obter o ContainerClient tanto de uma ligação de entrada Storage Blob usando um trigger HTTP:
import "@azure/functions-extensions-blob"; // This is the mandatory first import for SDK binding
import { StorageBlobClient } from "@azure/functions-extensions-blob";
import {
app,
HttpRequest,
HttpResponseInit,
input,
InvocationContext,
} from "@azure/functions";
const blobInput = input.storageBlob({
path: "snippets",
connection: "AzureWebJobsStorage",
sdkBinding: true,
});
export async function listBlobs(
request: HttpRequest,
context: InvocationContext
): Promise<HttpResponseInit> {
// Get input binding for a specific container
const storageBlobClient = context.extraInputs.get(
blobInput
) as StorageBlobClient;
// List all blobs in the container
const blobs = [];
for await (const blob of storageBlobClient.containerClient.listBlobsFlat()) {
blobs.push(blob.name);
}
return { jsonBody: { blobs } };
}
app.http("listBlobs", {
methods: ["GET"],
authLevel: "function",
extraInputs: [blobInput],
handler: listBlobs,
});
O exemplo a seguir mostra um código TypeScript de gatilho de blob. A função grava um log quando um blob é adicionado ou atualizado no samples-workitems contêiner.
A string {name} no caminho do blob trigger samples-workitems/{name} cria uma expressão binding que podes usar em código de função para access o nome do ficheiro do blob que disparou. Para obter mais informações, consulte Padrões de nome de blob mais adiante neste artigo.
import { app, InvocationContext } from '@azure/functions';
export async function storageBlobTrigger1(blob: Buffer, context: InvocationContext): Promise<void> {
context.log(
`Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
);
}
app.storageBlob('storageBlobTrigger1', {
path: 'samples-workitems/{name}',
connection: 'MyStorageAccountAppSetting',
handler: storageBlobTrigger1,
});
O exemplo a seguir mostra um código JavaScript de gatilho de blob. A função grava um log quando um blob é adicionado ou atualizado no samples-workitems contêiner.
A string {name} no caminho do blob trigger samples-workitems/{name} cria uma expressão binding que podes usar em código de função para access o nome do ficheiro do blob que disparou. Para obter mais informações, consulte Padrões de nome de blob mais adiante neste artigo.
const { app } = require('@azure/functions');
app.storageBlob('storageBlobTrigger1', {
path: 'samples-workitems/{name}',
connection: 'MyStorageAccountAppSetting',
handler: (blob, context) => {
context.log(
`Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
);
},
});
O exemplo seguinte demonstra como criar uma função que executa quando um ficheiro é adicionado ao contentor source blob storage.
O arquivo de configuração de função (function.json) inclui uma associação com o type de blobTrigger e direction definido como in.
{
"bindings": [
{
"name": "InputBlob",
"type": "blobTrigger",
"direction": "in",
"path": "source/{name}",
"connection": "MyStorageAccountConnectionString"
}
]
}
Aqui está o código associado para o arquivo run.ps1 .
param([byte[]] $InputBlob, $TriggerMetadata)
Write-Host "PowerShell Blob trigger: Name: $($TriggerMetadata.Name) Size: $($InputBlob.Length) bytes"
Este exemplo usa tipos SDK para access diretamente o objeto subjacente BlobClient fornecido pelo gatilho Blob storage:
import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob
app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)
@app.blob_trigger(
arg_name="client", path="PATH/TO/BLOB", connection="AzureWebJobsStorage"
)
def blob_trigger(client: blob.BlobClient):
logging.info(
f"Python blob trigger function processed blob \n"
f"Properties: {client.get_blob_properties()}\n"
f"Blob content head: {client.download_blob().read(size=1)}"
)
Para exemplos de utilização de outros tipos de SDK, veja as amostras ContainerClient e StorageStreamDownloader. Para um tutorial passo a passo sobre como incluir bindings do tipo SDK na sua aplicação de funções, siga as associações SDK Python para Blob Sample.
Para saber mais, incluindo quais outras associações de tipo SDK são suportadas, consulte Associações de tipo SDK.
Este exemplo regista o nome e o tamanho do blob a partir do gatilho do blob recebido.
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="BlobTrigger1")
@app.blob_trigger(arg_name="myblob",
path="samples-workitems/{name}",
connection="MyStorageAccountAppSetting")
def test_function(myblob: func.InputStream):
logging.info(f"Python blob trigger function processed blob \n"
f"Name: {myblob.name}\n"
f"Blob Size: {myblob.length} bytes")
Atributos
Tanto in-process como isolated worker process C# usam o atributo BlobAttribute para definir a função. Em vez disso, o script C# usa um arquivo de configuração function.json, conforme descrito no guia de script C#.
O construtor do atributo usa os seguintes parâmetros:
| Parâmetro | Descrição |
|---|---|
| BlobPath | O caminho para o blob. |
| Ligação | O nome de uma configuração de aplicação ou coleção de definições que especifica como se ligar ao Azure Blobs. Consulte Conexões. |
| Access | Indica se você estará lendo ou escrevendo. |
| Fonte | Define a origem do evento de acionamento. Use BlobTriggerSource.EventGrid para um gatilho de blob baseado em Grade de Eventos, que fornece latência mais baixa. O padrão é BlobTriggerSource.LogsAndContainerScan, que usa o mecanismo de sondagem padrão para detetar alterações no contêiner. |
Aqui está um BlobTrigger atributo em uma assinatura de método:
[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
[BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
[BlobInput("test-samples-input/sample1.txt")] string myBlob,
FunctionContext context)
Quando estiver desenvolvendo localmente, adicione as configurações do aplicativo no arquivo local.settings.json na Values coleção.
Decoradores
Aplica-se apenas ao modelo de programação Python v2.
Para funções Python v2 definidas usando decoradores, as seguintes propriedades no decorador blob_trigger definem o gatilho Blob Storage:
| Propriedade | Descrição |
|---|---|
arg_name |
Declara o nome do parâmetro na assinatura da função. Quando a função é acionada, o valor desse parâmetro tem o conteúdo da mensagem de fila. |
path |
O contentor para monitorizar. Pode ser um padrão de nome de blob. |
connection |
A conta storage connection string. |
source |
Define a origem do evento de acionamento. Use EventGrid para um gatilho de blob baseado em Grade de Eventos, que fornece latência mais baixa. O padrão é LogsAndContainerScan, que usa o mecanismo de sondagem padrão para detetar alterações no contêiner. |
Para funções Python definidas usando function.json, consulte a seção Configuração .
Anotações
O atributo @BlobTrigger é usado para te dar access ao blob que desencadeou a função. Consulte o exemplo de gatilho para obter detalhes. Use a source propriedade para definir a origem do evento de acionamento. Use EventGrid para um gatilho de blob baseado em Grade de Eventos, que fornece latência mais baixa. O padrão é LogsAndContainerScan, que usa o mecanismo de sondagem padrão para detetar alterações no contêiner. |
Configuração
Aplica-se apenas ao modelo de programação Python v1.
A tabela a seguir explica as propriedades que você pode definir no options objeto passado para o app.storageBlob() método.
| Propriedade | Descrição |
|---|---|
| caminho | O contentor para monitorizar. Pode ser um padrão de nome de blob. |
| conexão | O nome de uma configuração de aplicação ou coleção de definições que especifica como se ligar ao Azure Blobs. Consulte Conexões. |
| fonte | Define a origem do evento de acionamento. Use EventGrid para um gatilho de blob baseado em Grade de Eventos, que fornece latência mais baixa. O padrão é LogsAndContainerScan, que usa o mecanismo de sondagem padrão para detetar alterações no contêiner. |
A tabela a seguir explica as propriedades de configuração de associação definidas no arquivo function.json .
| function.json propriedade | Descrição |
|---|---|
| tipo | Deve ser definido como blobTrigger. Esta propriedade é definida automaticamente quando cria o gatilho no Azure portal. |
| direção | Deve ser definido como in. Esta propriedade é definida automaticamente quando cria o gatilho no Azure portal. As exceções são observadas na seção de uso . |
| Designação | O nome da variável que representa o blob no código da função. |
| caminho | O contentor para monitorizar. Pode ser um padrão de nome de blob. |
| conexão | O nome de uma configuração de aplicação ou coleção de definições que especifica como se ligar ao Azure Blobs. Consulte Conexões. |
| fonte | Define a origem do evento de acionamento. Use EventGrid para um gatilho de blob baseado em Grade de Eventos, que fornece latência mais baixa. O padrão é LogsAndContainerScan, que usa o mecanismo de sondagem padrão para detetar alterações no contêiner. |
Consulte a seção Exemplo para obter exemplos completos.
Metadados
O gatilho de blob fornece várias propriedades de metadados. Essas propriedades podem ser usadas como parte de expressões de associação em outras associações ou como parâmetros em seu código. Estes valores têm a mesma semântica que o tipo CloudBlob.
| Propriedade | Tipo | Descrição |
|---|---|---|
BlobTrigger |
string |
O caminho para o blob de acionamento. |
Uri |
System.Uri |
O URI do blob para o local principal. |
Properties |
BlobProperties | As propriedades do sistema do blob. |
Metadata |
IDictionary<string,string> |
Os metadados definidos pelo usuário para o blob. |
O exemplo a seguir registra o caminho para o blob de acionamento, incluindo o contêiner:
public static void Run(string myBlob, string blobTrigger, ILogger log)
{
log.LogInformation($"Full blob path: {blobTrigger}");
}
Metadados
O gatilho de blob fornece várias propriedades de metadados. Essas propriedades podem ser usadas como parte de expressões de associação em outras associações ou como parâmetros em seu código.
| Propriedade | Descrição |
|---|---|
blobTrigger |
O caminho para o blob de acionamento. |
uri |
O URI do blob para o local principal. |
properties |
As propriedades do sistema do blob. |
metadata |
Os metadados definidos pelo usuário para o blob. |
Os metadados podem ser obtidos da triggerMetadata propriedade do objeto fornecido context , conforme mostrado no exemplo a seguir, que registra o caminho para o blob de acionamento (blobTrigger), incluindo o contêiner:
context.log(`Full blob path: ${context.triggerMetadata.blobTrigger}`);
Metadados
Os metadados estão disponíveis através do $TriggerMetadata parâmetro.
Utilização
Os tipos de vinculação suportados pelo gatilho Blob dependem da versão do pacote de extensão e da modalidade C# usada em seu aplicativo de função.
O gatilho de blob pode se ligar aos seguintes tipos:
| Tipo | Descrição |
|---|---|
string |
O conteúdo de blob como uma cadeia de caracteres. Use quando o conteúdo do blob for texto simples. |
byte[] |
Os bytes do conteúdo do blob. |
| Tipos serializáveis JSON | Quando um blob contém dados JSON, o Functions tenta desserializar os dados JSON em um tipo de objeto CLR (POCO) simples. |
| Fluxo1 | Um fluxo de entrada do conteúdo do blob. |
|
BlobClient1, BlockBlobClient1, PageBlobClient1, AppendBlobClient1, BlobBaseClient1 |
Um cliente conectado ao blob. Esse conjunto de tipos oferece mais controle para processar o blob e pode ser usado para gravar novamente no blob se a conexão tiver permissão suficiente. |
1 Para usar estes tipos, precisa de consultar Microsoft. Azure. Funções.Trabalhadores.Extensões. Storage. Blobs 6.0.0 ou posterior e as dependências common para ligações de tipos SDK.
A ligação ao string, ou Byte[] só é recomendada quando o tamanho do blob é pequeno. Isso é recomendado porque todo o conteúdo do blob é carregado na memória. Para a maioria dos blobs, use um Stream ou BlobClient tipo. Para mais informações, veja Concorrência e uso de memória.
Se receber uma mensagem de erro ao tentar associar a um dos tipos de SDK Storage, certifique-se de que tem uma referência para a versão correta Storage SDK.
Também pode usar o StorageAccountAttribute para especificar a conta storage a usar. Podes fazer isto quando precisares de usar uma conta de storage diferente das outras funções na biblioteca. O construtor assume o nome de uma definição de aplicação que contém uma storage connection string. O atributo pode ser aplicado no nível de parâmetro, método ou classe. O exemplo a seguir mostra o nível da classe e o nível do método:
[StorageAccount("ClassLevelStorageAppSetting")]
public static class AzureFunctions
{
[FunctionName("BlobTrigger")]
[StorageAccount("FunctionLevelStorageAppSetting")]
public static void Run( //...
{
....
}
A conta de storage a utilizar é determinada pela seguinte ordem:
- A
BlobTriggerpropriedade doConnectionatributo. - O
StorageAccountatributo aplicado ao mesmo parâmetro que oBlobTriggeratributo. - O
StorageAccountatributo aplicado à função. - O
StorageAccountatributo aplicado à classe. - A storage padrão tem em conta a aplicação funcional, que está definida na configuração
AzureWebJobsStorageda aplicação.
Observação
O suporte para ligação a tipos de SDK está atualmente em pré-visualização e limitado ao Azure Blob Storage SDK. Para obter mais informações, consulte Tipos de SDK no artigo de referência Java.
Access os dados do blob através de um parâmetro que corresponde ao nome designado pelo parâmetro de nome da ligação no ficheiro function.json.
Access dados de blob através do parâmetro digitado como InputStream. Consulte o exemplo de gatilho para obter detalhes.
As funções também suportam bindings de tipos de SDK em Python para Azure Blob storage, o que permite trabalhar com dados de blob usando estes tipos de SDK subjacentes:
Observação
Somente tipos de SDK síncronos são suportados.
Importante
O suporte a tipos de SDK para Python está geralmente disponível e só é suportado para o modelo de programação Python v2. Para obter mais informações, consulte Tipos de SDK em Python.
Ligações
A propriedade connection é uma referência à configuração do ambiente que especifica como a aplicação deve ligar-se a Azure Blobs. Pode especificar:
- O nome de uma definição de aplicação que contém um connection string
- O nome de um prefixo compartilhado para várias configurações de aplicativo, definindo em conjunto uma conexão baseada em identidade.
Se o valor configurado for uma correspondência exata para uma única configuração e uma correspondência de prefixo para outras configurações, a correspondência exata será usada.
Connection string
Para obter uma connection string, siga os passos mostrados em Gerir storage conta access chaves. O connection string deve ser para uma conta de storage de uso geral, não para uma conta Blob storage.
Esta connection string deve ser armazenada numa configuração de aplicação com um nome correspondente ao valor especificado pela propriedade connection da configuração de ligação.
Se o nome da configuração do aplicativo começar com "AzureWebJobs", você poderá especificar apenas o restante do nome aqui. Por exemplo, se você definir connection como "MyStorage", o tempo de execução do Functions procurará uma configuração de aplicativo chamada "AzureWebJobsMyStorage". Se deixares connection vazio, o runtime das Funções usa a Storage connection string predefinida na definição da app, chamada AzureWebJobsStorage.
Conexões baseadas em identidade
Se estiveres a usar versão 5.x ou superior da extensão (bundle 3.x ou superior para stacks de línguas não-.NET), em vez de usar um connection string com um segredo, podes fazer com que a aplicação use uma identidade Microsoft Entra. Para usar uma identidade, defina as configurações sob um prefixo comum que mapeia para a connection propriedade na configuração de gatilho e ligação.
Se estiver a definir connection para "AzureWebJobsStorage", veja Ligar ao storage anfitrião com identidade. Para todas as outras conexões, a extensão requer as seguintes propriedades:
| Propriedade | Modelo de variável de ambiente | Descrição | Valor de exemplo |
|---|---|---|---|
| URI do serviço de Blob |
<CONNECTION_NAME_PREFIX>__serviceUri
1 |
O URI do plano de dados do serviço de blob ao qual você está se conectando, usando o esquema HTTPS. | https://<storage_account_name>.blob.core.windows.net |
<CONNECTION_NAME_PREFIX>__blobServiceUri 1 pode ser usado como um alias. Se a configuração de conexão será usada por um gatilho de blob, blobServiceUri também deve ser acompanhada por queueServiceUri. Ver abaixo.
O serviceUri formulário não pode ser usado quando a configuração geral da conexão deve ser usada em blobs, filas e/ou tabelas. O URI só pode designar o serviço de blob. Como alternativa, você pode fornecer um URI especificamente para cada serviço, permitindo que uma única conexão seja usada. Se ambas as versões forem fornecidas, o formulário multisserviço será usado. Para configurar a conexão para vários serviços, em vez de <CONNECTION_NAME_PREFIX>__serviceUri, defina:
| Propriedade | Modelo de variável de ambiente | Descrição | Valor de exemplo |
|---|---|---|---|
| URI do serviço de Blob | <CONNECTION_NAME_PREFIX>__blobServiceUri |
O URI do plano de dados do serviço de blob ao qual você está se conectando, usando o esquema HTTPS. | https://<storage_account_name>.blob.core.windows.net |
| URI do Serviço de Fila (necessário para gatilhos deblob 2) | <CONNECTION_NAME_PREFIX>__queueServiceUri |
O URI do plano de dados de um serviço de fila, usando o esquema HTTPS. Esse valor só é necessário para gatilhos de blob. | https://<storage_account_name>.queue.core.windows.net |
2 O blob trigger lida com a falha em múltiplas tentativas escrevendo blobs venenosos numa fila. No formulário, a serviceUriAzureWebJobsStorage conexão é usada. No entanto, ao especificar blobServiceUri, um URI de serviço de fila também deve ser fornecido com queueServiceUri. Recomenda-se que utilize o serviço da mesma conta de storage que o serviço de blobs. Também precisa de garantir que o gatilho pode ler e escrever mensagens no serviço de fila configurado, atribuindo um papel como Storage Queue Data Contributor.
Outras propriedades podem ser definidas para personalizar a conexão. Consulte Propriedades comuns para conexões baseadas em identidade.
Quando alojadas no serviço Azure Functions, as ligações baseadas em identidade utilizam uma identidade gerida. A identidade atribuída ao sistema é usada por padrão, embora uma identidade atribuída ao usuário possa ser especificada com as credential propriedades e clientID . Observe que não há suporte para a configuração de uma identidade atribuída pelo usuário com uma ID de recurso. Quando executado em outros contextos, como desenvolvimento local, sua identidade de desenvolvedor é usada, embora isso possa ser personalizado. Consulte Desenvolvimento local com conexões baseadas em identidade.
Conceder permissão à identidade
Qualquer identidade que esteja sendo usada deve ter permissões para executar as ações pretendidas. Para a maioria dos serviços Azure, isto significa que precisa de atribuir um papel no Azure RBAC, usando papéis incorporados ou personalizados que forneçam essas permissões.
Importante
Algumas permissões podem ser expostas pelo serviço de destino que não são necessárias para todos os contextos. Sempre que possível, aderir ao princípio do menor privilégio, concedendo à identidade apenas os privilégios necessários. Por exemplo, se o aplicativo só precisa ser capaz de ler de uma fonte de dados, use uma função que só tenha permissão para ler. Seria inadequado atribuir uma função que também permita escrever a esse serviço, pois isso seria uma permissão excessiva para uma operação de leitura. Da mesma forma, convém garantir que a atribuição de função tenha escopo apenas sobre os recursos que precisam ser lidos.
Tens de criar uma atribuição de funções que dê acesso ao teu contentor de blobs em tempo de execução. Cargos de gestão como Proprietário não são suficientes. A tabela seguinte mostra os papéis incorporados recomendados ao utilizar a extensão Blob Storage em funcionamento normal. Seu aplicativo pode exigir permissões adicionais com base no código que você escreve.
| Tipo de vinculação | Exemplo de funções internas |
|---|---|
| Acionador |
Storage Proprietário dos Dados do BlobandStorage Contribuidor de Dados da Fila1 Permissões extras também devem ser concedidas à conexão AzureWebJobsStorage.2 |
| Vinculação de entrada | Storage Leitor de Dados Blob |
| Vinculação de saída | Storage Blob Data Owner |
1 O blob trigger gere a falha em múltiplas tentativas escrevendo blobs venenos numa fila na conta storage especificada pela ligação.
2 A conexão AzureWebJobsStorage é usada internamente para blobs e filas que habilitam o gatilho. Se estiver configurado para usar uma conexão baseada em identidade, ele precisará de permissões extras além do requisito padrão. As permissões necessárias são cobertas pelas funções Storage Blob Data Owner, Storage Queue Data Contributor e Storage Account Contributor. Para saber mais, veja Ligar ao storage anfitrião com identidade.
Padrões de nome de blob
Você pode especificar um padrão de nome de path blob na propriedade em function.json ou no construtor de atributo BlobTrigger . O padrão de nome pode ser um filtro ou uma expressão de ligação. As seguintes secções fornecem exemplos.
Gorjeta
Um nome de contêiner não pode conter um resolvedor no padrão de nome.
Obter nome de arquivo e extensão
O exemplo a seguir mostra como vincular ao nome do arquivo de blob e à extensão separadamente:
"path": "input/{blobname}.{blobextension}",
Se o blob for nomeado original-Blob1.txt, os blobname valores das variáveis e blobextension no código da função serão original-Blob1 e txt.
Filtrar no nome do blob
O exemplo a seguir é acionado somente em blobs no input contêiner que começam com a cadeia de caracteres "original-":
"path": "input/original-{name}",
Se o nome do blob for .
Filtrar por tipo de ficheiro
O exemplo a seguir é acionado somente em arquivos .png :
"path": "samples/{name}.png",
Filtrar chaves em nomes de arquivo
Para procurar chaves em nomes de arquivos, fuja das chaves usando duas chaves. O exemplo a seguir filtra blobs que têm chaves no nome:
"path": "images/{{20140101}}-{name}",
Se o blob for nomeado {20140101}-soundfile.mp3, o valor da name variável no código da função será soundfile.mp3.
Sondagem e latência
A sondagem funciona como um híbrido entre a inspeção de logs e a execução de verificações periódicas de contêineres. Os blobs são verificados em grupos de 10.000 de cada vez com um token de continuação usado entre intervalos. Se seu aplicativo de função estiver no plano de consumo, pode haver um atraso de até 10 minutos no processamento de novos blobs se um aplicativo de função estiver ocioso.
Aviso
Os registos Storage são criados numa base de "melhor esforço". Não há garantia de que todos os eventos sejam capturados. Em algumas condições, os logs podem ser perdidos.
Se precisar de um processamento de blob mais rápido ou fiável, deve considerar mudar o seu alojamento para um plano App Service com o Always On ativado, o que pode resultar em custos mais elevados. Você também pode considerar o uso de um gatilho diferente do clássico gatilho de blob de sondagem. Para mais informações e uma comparação das várias opções de disparo para blob storage contentores, veja Trigger on a blob container.
Recibos de Blob
O runtime do Azure Functions garante que nenhuma função de disparo de blob seja chamada mais do que uma vez para o mesmo blob novo ou atualizado. Para determinar se uma determinada versão de blob foi processada, ele mantém recibos de blob.
Azure Functions armazena recibos de blob num contentor chamado azure-webjobs-hosts na conta Azure storage da sua aplicação de função (definida pela definição da aplicação AzureWebJobsStorage). Um recibo de blob tem as seguintes informações:
- A função acionada (
<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>, por exemplo:MyFunctionApp.Functions.CopyBlob) - O nome do contêiner
- O tipo de blob (
BlockBlobouPageBlob) - O nome do blob
- O ETag (um identificador de versão de blob, por exemplo:
0x8D1DC6E70A277EF)
Para forçar o reprocessamento de um blob, apague manualmente o recibo do blob desse blob do contentor azure-webjobs-hosts. Embora o reprocessamento possa não ocorrer imediatamente, é garantido que ocorrerá em um momento posterior. Para reprocessar imediatamente, o blob scaninfo em azure-webjobs-hosts/blobscaninfo pode ser atualizado. Todos os blobs com um carimbo de data/hora modificado pela última vez após a LatestScan propriedade serão verificados novamente.
Bolhas venenosas
Quando uma função de disparo de blob falha para um dado blob, o Azure Functions tenta essa função um total de cinco vezes por defeito.
Se as cinco tentativas falharem, Azure Functions adiciona uma mensagem a uma fila de Storage chamada webjobs-blobtrigger-poison. O número máximo de novas tentativas é configurável. A mesma configuração MaxDequeueCount é usada para manipulação de blob venenoso e manipulação de mensagens de fila de veneno. A mensagem de fila para blobs temporários é um objeto JSON que contém as seguintes propriedades:
- FunctionId (no formato
<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>) - BlobType (
BlockBlobouPageBlob) - Nome do Contêiner
- BlobName
- ETag (um identificador de versão de blob, por exemplo:
0x8D1DC6E70A277EF)
Uso de memória e simultaneidade
Quando você se associa a um tipo de saída que não oferece suporte a streaming, como string, ou Byte[], o tempo de execução deve carregar o blob inteiro na memória mais de uma vez durante o processamento. Isso pode resultar em um uso de memória maior do que o esperado ao processar blobs. Sempre que possível, use um tipo de suporte a fluxo. O suporte a tipos depende do modo C# e da versão da extensão. Para mais informações, consulte Tipos de ligação.
Neste momento, o tempo de execução deve carregar o blob inteiro na memória mais de uma vez durante o processamento. Isso pode resultar em um uso de memória maior do que o esperado ao processar blobs.
O uso de memória pode ser ainda mais afetado quando várias instâncias de função estão processando simultaneamente dados de blob. Se você estiver tendo problemas de memória usando um gatilho de Blob, considere reduzir o número de execuções simultâneas permitidas. Reduzir a simultaneidade pode ter o efeito colateral de aumentar o acúmulo de blobs esperando para serem processados. Os limites de memória do seu aplicativo de função dependem do plano. Para obter mais informações, consulte Limites de serviço.
A forma como podes controlar o número de execuções concorrentes depende da versão da extensão Storage que estás a usar.
Ao usar a versão 5.0.0 da extensão Storage ou uma versão posterior, controla a concorrência de gatilhos usando a definição maxDegreeOfParallelism na configuração blobs em host.json.
Os limites aplicam-se separadamente a cada função que usa um gatilho de blob.
host.json propriedades
O arquivo host.json contém configurações que controlam o comportamento do gatilho de blob. Consulte a secção de definições host.json para detalhes sobre as definições disponíveis.