Freigeben über

Azure Blob Storage-Eingabebindung für Azure Functions

  • Artikel

Die Eingabebindung ermöglicht Ihnen das Lesen von Blob Storage-Daten als Eingabe für eine Azure-Funktion.

Informationen zu Setup- und Konfigurationsdetails finden Sie in der Übersicht.

Wichtig

In diesem Artikel werden Registerkarten verwendet, um mehrere Versionen des Node.js-Programmiermodells zu unterstützen. Das v4-Modell ist allgemein verfügbar und bietet JavaScript- und TypeScript-Entwicklern eine flexiblere und intuitivere Erfahrung. Weitere Informationen zur Funktionsweise des v4-Modells finden Sie im Azure Functions Node.js-Entwicklerhandbuch. Weitere Informationen zu den Unterschieden zwischen v3 und v4 finden Sie im Migrationshandbuch.

Azure Functions unterstützt zwei Programmiermodelle für Python. Wie Sie Ihre Bindung definieren, hängt vom gewählten Python-Programmiermodell ab.

Mit dem Python v2-Programmiermodell können Sie Bindungen mithilfe von Decorators direkt im Python-Funktionscode definieren. Weitere Informationen finden Sie im Python Developer-Leitfaden.

In diesem Artikel werden beide Programmiermodelle unterstützt.

Beispiel

Eine C#-Funktion kann mit einem der folgenden C#-Modi erstellt werden:

  • Isoliertes Workermodell: Kompilierte C#-Funktion, die in einem Workerprozess ausgeführt wird, der von der Runtime isoliert ist. Ein isolierter Workerprozess ist erforderlich, um C#-Funktionen zu unterstützen, die in LTS- und Nicht-LTS-Versionen von .NET und .NET Framework ausgeführt werden. Erweiterungen für isolierte Workerprozessfunktionen verwenden Microsoft.Azure.Functions.Worker.Extensions.*-Namespaces.
  • In-Process-Modell: Kompilierte C#-Funktion, die im gleichen Prozess wie die Functions-Runtime ausgeführt wird. In einer Variante dieses Modells kann Functions mithilfe von C#-Skripts ausgeführt werden. Dies wird hauptsächlich für die Bearbeitung im C#-Portal unterstützt. Erweiterungen für In-Process-Funktionen verwenden Microsoft.Azure.WebJobs.Extensions.*-Namespaces.

Wichtig

Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, um den vollständigen Support zu ermöglichen.

Das folgende Beispiel ist eine C#-Funktion, die in einem isolierten Workerprozess ausgeführt wird und einen Blobtrigger mit Blobbindungen für Blobeingabe und -ausgabe verwendet. Die Funktion wird durch die Erstellung eines Blobs im Container test-samples-trigger ausgelöst. Sie liest eine Textdatei aus dem Container test-samples-input und erstellt basierend auf dem Namen der ausgelösten Datei eine neue Textdatei in einem Ausgabecontainer.

    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";
        }
    }
}

Dieser Abschnitt enthält folgende Beispiele:

HTTP-Trigger: Suchen des Blobnamens in einer Abfragezeichenfolge

Das folgende Beispiel zeigt eine Java-Funktion, die mithilfe der Anmerkung HttpTrigger einen Parameter mit dem Namen einer Datei in einem Blob Storage-Container empfängt. Die Anmerkung BlobInput liest dann die Datei und übergibt ihren Inhalt als byte[] an die Funktion.

  @FunctionName("getBlobSizeHttp")
  @StorageAccount("Storage_Account_Connection_String")
  public HttpResponseMessage blobSize(
    @HttpTrigger(name = "req", 
      methods = {HttpMethod.GET}, 
      authLevel = AuthorizationLevel.ANONYMOUS) 
    HttpRequestMessage<Optional<String>> request,
    @BlobInput(
      name = "file", 
      dataType = "binary", 
      path = "samples-workitems/{Query.file}") 
    byte[] content,
    final ExecutionContext context) {
      // build HTTP response with size of requested blob
      return request.createResponseBuilder(HttpStatus.OK)
        .body("The size of \"" + request.getQueryParameters().get("file") + "\" is: " + content.length + " bytes")
        .build();
  }

Warteschlangentrigger: Empfangen des Blobnamens aus einer Warteschlangennachricht

Das folgende Beispiel zeigt eine Java-Funktion, die mithilfe der QueueTrigger-Anmerkung eine Nachricht mit dem Namen einer Datei in einem Blob Storage-Container empfängt. Die Anmerkung BlobInput liest dann die Datei und übergibt ihren Inhalt als byte[] an die Funktion.

  @FunctionName("getBlobSize")
  @StorageAccount("Storage_Account_Connection_String")
  public void blobSize(
    @QueueTrigger(
      name = "filename", 
      queueName = "myqueue-items-sample") 
    String filename,
    @BlobInput(
      name = "file", 
      dataType = "binary", 
      path = "samples-workitems/{queueTrigger}") 
    byte[] content,
    final ExecutionContext context) {
      context.getLogger().info("The size of \"" + filename + "\" is: " + content.length + " bytes");
  }

Verwenden Sie die @BlobInput-Anmerkung in der Laufzeitbibliothek für Java-Funktionen für Parameter, deren Wert aus einem Blob empfangen wird. Diese Anmerkung kann mit nativen Java-Typen, POJOs oder Werten mit Optional<T>, die NULL-Werte annehmen können, verwendet werden.

Das folgende Beispiel zeigt eine durch die Warteschlange ausgelöste TypeScript-Funktion, die eine Kopie eines Blobs erstellt. Sie wird durch eine Warteschlangennachricht ausgelöst, die den Namen des zu kopierenden Blobs enthält. Der Name des neuen Blobs lautet {Name des Originalblobs}-Copy.

import { app, input, InvocationContext, output } from '@azure/functions';

const blobInput = input.storageBlob({
    path: 'samples-workitems/{queueTrigger}',
    connection: 'MyStorageConnectionAppSetting',
});

const blobOutput = output.storageBlob({
    path: 'samples-workitems/{queueTrigger}-Copy',
    connection: 'MyStorageConnectionAppSetting',
});

export async function storageQueueTrigger1(queueItem: unknown, context: InvocationContext): Promise<unknown> {
    return context.extraInputs.get(blobInput);
}

app.storageQueue('storageQueueTrigger1', {
    queueName: 'myqueue-items',
    connection: 'MyStorageConnectionAppSetting',
    extraInputs: [blobInput],
    return: blobOutput,
    handler: storageQueueTrigger1,
});

Das folgende Beispiel zeigt eine durch die Warteschlange ausgelöste JavaScript-Funktion, die eine Kopie eines Blobs erstellt. Sie wird durch eine Warteschlangennachricht ausgelöst, die den Namen des zu kopierenden Blobs enthält. Der Name des neuen Blobs lautet {Name des Originalblobs}-Copy.

const { app, input, output } = require('@azure/functions');

const blobInput = input.storageBlob({
    path: 'samples-workitems/{queueTrigger}',
    connection: 'MyStorageConnectionAppSetting',
});

const blobOutput = output.storageBlob({
    path: 'samples-workitems/{queueTrigger}-Copy',
    connection: 'MyStorageConnectionAppSetting',
});

app.storageQueue('storageQueueTrigger1', {
    queueName: 'myqueue-items',
    connection: 'MyStorageConnectionAppSetting',
    extraInputs: [blobInput],
    return: blobOutput,
    handler: (queueItem, context) => {
        return context.extraInputs.get(blobInput);
    },
});

Das folgende Beispiel zeigt eine in der Datei function.json definierte Blobeingabebindung, die die eingehenden Blobdaten für die PowerShell-Funktion verfügbar macht.

Die Konfiguration in der JSON-Datei lautet wie folgt:

{
  "bindings": [
    {
      "name": "InputBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "source/{name}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

Der Funktionscode lautet wie folgt:

# Input bindings are passed in via param block.
param([byte[]] $InputBlob, $TriggerMetadata)

Write-Host "PowerShell Blob trigger: Name: $($TriggerMetadata.Name) Size: $($InputBlob.Length) bytes"

In diesem Beispiel werden SDK-Typen verwendet, um direkt auf das zugrunde liegende BlobClient Objekt zuzugreifen, das von der Blob Storage-Eingabebindung bereitgestellt wird:

import logging

import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob

app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@app.route(route="file")
@app.blob_input(
    arg_name="client", path="PATH/TO/BLOB", connection="AzureWebJobsStorage"
)
def blob_input(req: func.HttpRequest, client: blob.BlobClient):
    logging.info(
        f"Python blob input function processed blob \n"
        f"Properties: {client.get_blob_properties()}\n"
        f"Blob content head: {client.download_blob().read(size=1)}"
    )
    return "ok"

Beispiele für die Verwendung anderer SDK-Typen finden Sie in den ContainerClient Und StorageStreamDownloader Beispielen.

Weitere Informationen, einschließlich der Aktivierung von SDK-Typbindungen in Ihrem Projekt, finden Sie unter SDK-Typbindungen.

Der Code erstellt eine Kopie eines Blobs.

import logging
import azure.functions as func

app = func.FunctionApp()

@app.function_name(name="BlobOutput1")
@app.route(route="file")
@app.blob_input(arg_name="inputblob",
                path="sample-workitems/test.txt",
                connection="<BLOB_CONNECTION_SETTING>")
@app.blob_output(arg_name="outputblob",
                path="newblob/test.txt",
                connection="<BLOB_CONNECTION_SETTING>")
def main(req: func.HttpRequest, inputblob: str, outputblob: func.Out[str]):
    logging.info(f'Python Queue trigger function processed {len(inputblob)} bytes')
    outputblob.set(inputblob)
    return "ok"

Attribute

Sowohl C#-Bibliotheken des Typs In-Process als auch des Typs Isolierter Workerprozess verwenden Attribute zum Definieren der Funktion. Das C#-Skript verwendet stattdessen eine Konfigurationsdatei function.json, wie im C#-Skript-Handbuch beschrieben.

Der isolierte Arbeitsprozess definiert eine Eingabebindung mithilfe eines BlobInputAttribute Attributs, das die folgenden Parameter verwendet:

Parameter BESCHREIBUNG
BlobPath Der Pfad des Blobs.
Connection Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.

Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values-Sammlung hinzu.

Decorator-Elemente

Gilt nur für das Python v2-Programmiermodell.

Für Python v2-Funktionen, die mithilfe von Decorators definiert wurden, definieren die folgenden Eigenschaften für die Decorators blob_input und blob_output die Blob Storage-Trigger:

Eigenschaft BESCHREIBUNG
arg_name Der Name der Variablen, die das Blob im Funktionscode darstellt.
path Der Pfad zum Blob Für den Decorator blob_input ist es der gelesene Blob. Für den Decorator blob_output handelt es sich um die Ausgabe oder Kopie des Eingabeblobs.
connection Die Verbindungszeichenfolge für das Speicherkonto.
data_type Gibt für dynamisch typisierte Sprachen den zugrunde liegenden Datentyp an. Mögliche Werte sind string, binary oder stream. Weitere Details finden Sie in den Konzepten für Trigger und Bindungen.

Informationen zu Python-Funktionen, die mithilfe von function.json definiert wurden, finden Sie im Abschnitt Konfiguration.

Anmerkungen

Das @BlobInput-Attribut gewährt Ihnen Zugriff auf das Blob, das die Funktion ausgelöst hat. Wenn Sie ein Bytearray mit dem Attribut verwenden, legen Sie dataType auf binary fest. Weitere Detailinformationen finden Sie im Eingabebeispiel.

Konfiguration

Gilt nur für das Python v1-Programmiermodell.

In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options-Objekt festlegen können, das an die input.storageBlob()-Methode übergeben wurde.

Eigenschaft Beschreibung
path Der Pfad des Blobs.
connection Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.

function.json-Eigenschaft BESCHREIBUNG
type Muss auf blob festgelegt sein.
direction Muss auf in festgelegt sein. Ausnahmen sind im Abschnitt Verwendung angegeben.
name Der Name der Variablen, die das Blob im Funktionscode darstellt.
path Der Pfad des Blobs.
connection Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen.
dataType Gibt für dynamisch typisierte Sprachen den zugrunde liegenden Datentyp an. Mögliche Werte sind string, binary oder stream. Weitere Details finden Sie in den Konzepten für Trigger und Bindungen.

Vollständige Beispiele finden Sie im Abschnitt „Beispiele“.

Verwendung

Die von der Blobeingabe unterstützten Bindungstypen hängen von der Version des Erweiterungspakets und der C#-Modalität ab, die in Ihrer Funktions-App verwendet wird.

Wenn die Funktion ein einzelnes Blob verarbeiten soll, kann die Blobeingabebindung an die folgenden Typen gebunden werden:

type BESCHREIBUNG
string Den Blobinhalt als Zeichenfolge. Verwenden Sie diese Option, wenn der Inhalt des Blobs einfacher Text ist.
byte[] Die Bytes des Blobinhalts.
Serialisierbare JSON-Typen Wenn ein Blob JSON-Daten enthält, versucht Functions, die JSON-Daten in einen POCO-Objekttyp (Plain-Old CLR Object) zu deserialisieren.
Stream1 Ein Eingabestream des Blobinhalts.
BlobClient1,
BlockBlobClient1,
PageBlobClient1,
AppendBlobClient1,
BlobBaseClient1		 Ein Client, der mit dem Blob verbunden ist. Diese Typen bieten die größte Kontrolle für die Verarbeitung des Blobs und können zum Zurückschreiben in das Blob verwendet werden, wenn die Verbindung über ausreichende Berechtigungen verfügt.

Wenn die Funktion mehrere Blobs aus einem Container verarbeiten soll, kann die Blobeingabebindung an die folgenden Typen gebunden werden:

type BESCHREIBUNG
T[] oder List<T>, wobei T einer der einzelnen Blob-Eingabebindungstypen ist. Ein Array oder eine Liste mit mehreren Blobs. Jeder Eintrag stellt ein Blob aus dem Container dar. Sie können auch an beliebige Schnittstellen binden, die von diesen Typen implementiert werden, z. B. IEnumerable<T>.
BlobContainerClient1 Ein Client, der mit dem Container verbunden ist. Dieser Typ bietet die größte Kontrolle für die Verarbeitung des Containers und kann zum Schreiben in den Container verwendet werden, wenn die Verbindung über ausreichende Berechtigungen verfügt.

1 Um diese Typen zu verwenden, müssen Sie auf Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 oder höher und die gemeinsamen Abhängigkeiten für SDK-Typbindungen verweisen.

Die Bindung an string oder Byte[] wird nur bei kleinen Blobs empfohlen. Der Grund für diese Empfehlung ist, dass der gesamte Blobinhalt in den Arbeitsspeicher geladen wird. Für die meisten Blobs sollte der Typ Stream oder BlobClient verwendet werden. Weitere Informationen finden Sie unter Parallelität und Arbeitsspeichernutzung.

Wenn beim Versuch, eine Bindung an einen der Storage SDK-Typen einzurichten, ein Fehler auftritt, vergewissern Sie sich, dass Sie über einen Verweis auf die richtige Storage SDK-Version verfügen.

Sie können auch StorageAccountAttribute verwenden, um das zu verwendende Speicherkonto anzugeben. Sie können so vorgehen, wenn Sie ein anderes Speicherkonto als andere Funktionen in der Bibliothek verwenden müssen. Der Konstruktor akzeptiert den Namen einer App-Einstellung mit einer Speicherverbindungszeichenfolge. Das Attribut kann auf Parameter-, Methoden- oder Klassenebene angewendet werden. Das folgende Beispiel zeigt die Anwendung auf Klassen- und Methodenebene:

[StorageAccount("ClassLevelStorageAppSetting")]
public static class AzureFunctions
{
    [FunctionName("BlobTrigger")]
    [StorageAccount("FunctionLevelStorageAppSetting")]
    public static void Run( //...
{
    ....
}

Das zu verwendende Speicherkonto wird anhand von Folgendem bestimmt (in der angegebenen Reihenfolge):

  • Die Eigenschaft Connection des Attributs BlobTrigger.
  • Das Attribut StorageAccount, das auf den gleichen Parameter angewendet wird wie das Attribut BlobTrigger.
  • Das Attribut StorageAccount, das auf die Funktion angewendet wird.
  • Das Attribut StorageAccount, das auf die Klasse angewendet wird.
  • Das Standardspeicherkonto für die Funktions-App, das in der AzureWebJobsStorage-Anwendungseinstellung definiert ist.

Das @BlobInput-Attribut gewährt Ihnen Zugriff auf das Blob, das die Funktion ausgelöst hat. Wenn Sie ein Bytearray mit dem Attribut verwenden, legen Sie dataType auf binary fest. Weitere Detailinformationen finden Sie im Eingabebeispiel.

Greifen Sie mit context.extraInputs.get() auf die Blobdaten zu.

Greifen Sie auf die Blobdaten über einen Parameter zu, der mit dem Namen übereinstimmt, der durch den name-Parameter der Bindung in der Datei function.json festgelegt ist.

Greifen Sie über den als InputStream typisierten Parameter auf Blob-Daten zu. Weitere Detailinformationen finden Sie im Eingabebeispiel.

Funktionen unterstützen auch Python SDK-Typbindungen für Azure Blob Storage, mit denen Sie mit BLOB-Daten mit diesen zugrunde liegenden SDK-Typen arbeiten können:

Wichtig

Die SDK-Typenunterstützung für Python befindet sich derzeit in der Vorschau und wird nur für das Python v2-Programmiermodell unterstützt. Weitere Informationen finden Sie unter SDK-Typen in Python.

Verbindungen

Die Eigenschaft connection ist ein Verweis auf die Umgebungskonfiguration, die angibt, wie die App eine Verbindung mit Azure-Blobs herstellen soll. Folgendes kann angegeben werden:

Wenn der konfigurierte Wert sowohl eine genaue Übereinstimmung für eine einzelne Einstellung als auch eine Präfix-Übereinstimmung für andere Einstellungen ist, wird die genaue Übereinstimmung verwendet.

Verbindungszeichenfolge

Um eine Verbindungszeichenfolge zu erhalten, folgen Sie den Schritten unter Verwaltung der Zugriffsschlüssel für Speicherkonten. Bei der Verbindungszeichenfolge muss es sich um eine Verbindungszeichenfolge für ein allgemeines Speicherkonto (nicht für ein Blobspeicherkonto) handeln.

Diese Verbindungszeichenfolge sollte in einer Anwendungseinstellung mit einem Namen gespeichert werden, der dem in der Eigenschaft connection der Bindungskonfiguration angegebenen Wert entspricht.

Falls der Name der App-Einstellung mit „AzureWebJobs“ beginnt, können Sie hier nur den Rest des Namens angeben. Wenn Sie connection also beispielsweise auf „MyStorage“ festlegen, sucht die Functions-Laufzeit nach einer App-Einstellung namens „AzureWebJobsMyStorage“. Ohne Angabe für connection verwendet die Functions-Laufzeit die standardmäßige Storage-Verbindungszeichenfolge aus der App-Einstellung AzureWebJobsStorage.

Identitätsbasierte Verbindungen

Wenn Sie Version 5.x oder höher der Erweiterung verwenden (Bündel 3.x oder höher für non-.NET Sprachstapel), anstatt einen Verbindungszeichenfolge mit einem geheimen Schlüssel zu verwenden, können Sie die App über eine Microsoft Entra-Identität verfügen. Um eine Identität zu verwenden, definieren Sie Einstellungen unter einem gemeinsamen Präfix, das der Eigenschaft connection in der Trigger- und Bindungskonfiguration zugeordnet ist.

Wenn Sie connection auf „AzureWebJobsStorage“ festlegen, finden Sie weitere Informationen unter Herstellen einer Verbindung zum Hostspeicher mit einer Identität. Für alle anderen Verbindungen erfordert die Erweiterung die folgenden Eigenschaften:

Eigenschaft Vorlage für Umgebungsvariable BESCHREIBUNG Beispielwert
Blob-Dienst-URI <CONNECTION_NAME_PREFIX>__serviceUri1 Der URI der Datenebene des Blob-Dienstes, mit dem Sie sich mithilfe des HTTPS-Schemas verbinden. https://<storage_account_name>.blob.core.windows.net

1 <CONNECTION_NAME_PREFIX>__blobServiceUri kann als Alias verwendet werden. Wenn die Verbindungskonfiguration von einem Blobtrigger verwendet wird, muss blobServiceUri auch von queueServiceUri begleitet werden. Siehe unten.

Das Format serviceUri kann nicht verwendet werden, wenn die gesamte Verbindungskonfiguration über Blobs, Warteschlangen und/oder Tabellen hinweg verwendet werden soll. Der URI kann nur den Blob-Dienst festlegen. Alternativ können Sie einen URI speziell für jeden Dienst bereitstellen, sodass eine einzelne Verbindung verwendet werden kann. Wenn beide Versionen bereitgestellt werden, wird das Format für mehrere Dienste verwendet. Um die Verbindung für mehrere Dienste anstelle von <CONNECTION_NAME_PREFIX>__serviceUri zu konfigurieren, legen Sie Folgendes fest:

Eigenschaft Vorlage für Umgebungsvariable BESCHREIBUNG Beispielwert
Blob-Dienst-URI <CONNECTION_NAME_PREFIX>__blobServiceUri Der URI der Datenebene des Blob-Dienstes, mit dem Sie sich mithilfe des HTTPS-Schemas verbinden. https://<storage_account_name>.blob.core.windows.net
URI des Warteschlangendiensts (für Blobtrigger2 erforderlich) <CONNECTION_NAME_PREFIX>__queueServiceUri Der Datenebenen-URI eines Warteschlangendiensts unter Verwendung des HTTPS-Schemas. Dieser Wert wird nur für Blobtrigger benötigt. https://<Speicherkontoname>.queue.core.windows.net

2 Fehler bei mehreren erneuten Versuchen werden vom Blobtrigger durch Schreiben nicht verarbeitbarer Blobs in eine Warteschlange behandelt. Im serviceUri-Formular wird die AzureWebJobsStorage-Verbindung verwendet. Beim Angeben von blobServiceUri muss jedoch auch ein Warteschlangendienst-URI mit queueServiceUri bereitgestellt werden. Es wird empfohlen, den Dienst von demselben Speicherkonto aus zu verwenden wie den Blob-Dienst. Sie müssen ebenfalls sicherstellen, dass der Trigger Nachrichten im konfigurierten Warteschlangendienst lesen und schreiben kann, indem Sie eine Rolle wie Mitwirkender für Storage-Warteschlangendaten zuweisen.

Andere Eigenschaften können festgelegt werden, um die Verbindung anzupassen. Weitere Informationen finden Sie unter Allgemeine Eigenschaften für identitätsbasierte Verbindungen.

Identitätsbasierte Verbindungen verwenden eine verwaltete Identität, wenn sie im Azure Functions-Dienst gehostet werden. Standardmäßig wird eine vom System zugewiesene Identität verwendet, auch wenn mit den Eigenschaften credential und clientID eine vom Benutzer zugewiesene Identität angegeben werden kann. Beachten Sie, dass das Konfigurieren einer benutzerseitig zugewiesenen Identität mit einer Ressourcen-ID nicht unterstützt wird. Bei Ausführung in anderen Kontexten (z. B. bei der lokalen Entwicklung) wird stattdessen Ihre Entwickleridentität verwendet, Dieses Verhalten kann angepasst werden. Weitere Informationen finden Sie unter Lokale Entwicklung mit identitätsbasierten Verbindungen.

Erteilen der Berechtigung für die Identität

Unabhängig davon, welche Identität verwendet wird, muss diese über Berechtigungen zum Ausführen der vorgesehenen Aktionen verfügen. Daher müssen Sie für die meisten Azure-Dienste eine Rolle in Azure RBAC zuweisen, indem Sie entweder integrierte oder benutzerdefinierte Rollen verwenden, die diese Berechtigungen bieten.

Wichtig

Vom Zieldienst werden möglicherweise einige nicht für alle Kontexte erforderliche Berechtigungen verfügbar gemacht. Befolgen Sie nach Möglichkeit das Prinzip der geringsten Berechtigung, und gewähren Sie der Identität nur die erforderlichen Berechtigungen. Wenn die App beispielsweise nur Daten aus einer Datenquelle lesen muss, verwenden Sie eine Rolle, die nur über Leseberechtigungen verfügt. Es wäre nicht angemessen, eine Rolle zu zuweisen, die auch das Schreiben in diesen Dienst zulässt, da dies eine übermäßige Berechtigung für einen Lesevorgang wäre. Ebenso sollten Sie sicherstellen, dass die Rollenzuweisung auf die Ressourcen begrenzt ist, die gelesen werden müssen.

Sie müssen eine Rollenzuweisung erstellen, die zur Laufzeit Zugriff auf Ihren Blob-Container ermöglicht. Verwaltungsrollen wie Besitzer sind nicht ausreichend. Die folgende Tabelle zeigt integrierte Rollen, die für den normalen Betrieb mit der Blob Storage-Erweiterung empfohlen werden. Ihre Anwendung erfordert möglicherweise weitere Berechtigungen basierend auf dem von Ihnen geschriebenen Code.

Bindungstyp Integrierte Beispielrollen
Trigger Besitzer von Speicherblobdaten und Mitwirkender an Speicherabfragedaten1

Außerdem müssen der AzureWebJobsStorage-Verbindung zusätzliche Berechtigungen erteilt werden.2
Eingabebindung Leser von Speicherblobdaten
Ausgabebindung Besitzer von Speicherblobdaten

1 Fehler bei mehreren erneuten Versuchen werden vom Blobtrigger durch Schreiben nicht verarbeitbarer Blobs in eine Warteschlange für das durch die Verbindung angegebene Speicherkonto behandelt.

2 Die AzureWebJobsStorage-Verbindung wird intern für Blobs und Warteschlangen verwendet, die den Trigger aktivieren. Wenn die Verwendung einer identitätsbasierten Verbindung konfiguriert ist, sind zusätzliche Berechtigungen erforderlich, die über die Standardanforderung hinausgehen. Die erforderlichen Berechtigungen werden durch die Rollen Besitzer von Storage-Blobdaten, Mitwirkender für Storage-Warteschlangendaten und Speicherkontomitwirkender abgedeckt. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit dem Hostspeicher mit einer Identität.

Nächste Schritte