Azure Functions: Entwicklerhandbuch

  • Artikel
  • 19 Minuten Lesedauer

In Azure Functions nutzen bestimmte Funktionen einige wichtige technische Konzepte und Komponenten gemeinsam, unabhängig von der verwendeten Sprache oder Bindung. Bevor Sie sich mit den spezifischen Details einer bestimmten Sprache oder Bindung beschäftigen, sollten Sie diese Übersicht lesen, die für alle Funktionen gilt.

Dieser Artikel setzt voraus, dass Sie die Einführung in Azure Functions bereits gelesen haben.

Funktionscode

Ein Funktion ist das primäre Konzept in Azure Functions. Eine Funktion enthält zwei wichtige Komponenten: Ihren Code, der in einer Vielzahl von Programmiersprachen geschrieben sein kann, und die Datei „function.json“ mit Konfigurationsinformationen. Für kompilierte Sprachen wird diese Konfigurationsdatei automatisch aus Anmerkungen im Code generiert. Für Skriptsprachen müssen Sie die Konfigurationsdatei selbst bereitstellen.

Die Datei „function.json“ definiert den Trigger, die Bindungen und weitere Konfigurationseinstellungen der Funktion. Jede Funktion verfügt nur über einen einzigen Trigger. Anhand dieser Konfigurationsdatei ermittelt die Runtime, welche Ereignisse überwacht werden sollen und wie Daten in die Funktionsausführung übergeben und aus dieser zurückgegeben werden. Im Folgenden finden Sie eine function.json-Beispieldatei.

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

Weitere Informationen finden Sie unter Konzepte für Azure Functions-Trigger und -Bindungen.

In der Eigenschaft bindings werden sowohl Trigger als auch Bindungen konfiguriert. Einige Einstellungen gelten für alle Bindungen, einige Einstellungen sind spezifisch für einen bestimmten Bindungstyp. Jede Bindung erfordert folgende Einstellungen:

Eigenschaft Werte Typ Kommentare
type Der Name der Bindung.

Beispiel: queueTrigger.		 Zeichenfolge
direction in, out Zeichenfolge Gibt an, ob die Bindung zum Empfangen von Daten in der Funktion oder zum Senden von Daten aus der Funktion dient.
name Der Funktionsbezeichner.

Beispiel: myQueue.		 Zeichenfolge Der Name, der für die gebundenen Daten in der Funktion verwendet wird. In C# ist dies ein Argumentname, in JavaScript ist es der Schlüssel in einer Schlüssel-Wert-Liste.

Funktionen-App

Eine Funktions-App bietet einen Ausführungskontext in Azure, in dem Ihre Funktionen ausgeführt werden. Daher ist dies die Bereitstellungs- und Verwaltungseinheit für Ihre Funktionen. Eine Funktions-App besteht aus einer oder mehreren individuellen Funktionen, die zusammen verwaltet, bereitgestellt und skaliert werden. Der Tarif, die Bereitstellungsmethode und die Runtimeversion sind für alle Funktionen in einer Funktions-App gleich. Eine Funktionen-App ist somit eine Möglichkeit, mit der Sie Ihre Funktionen organisieren und kollektiv verwalten können. Weitere Informationen finden Sie unter Verwalten einer Funktions-App.

Hinweis

Alle Funktionen in einer Funktions-App müssen in der gleichen Programmiersprache erstellt werden. In Vorgängerversionen der Azure Functions-Runtime war dies nicht erforderlich.

Ordnerstruktur

Der Code für alle Funktionen in einer bestimmten Funktions-App befindet sich in einem Stammprojektordner, der eine Hostkonfigurationsdatei enthält. Die Datei host.json enthält die runtimespezifische Konfiguration und befindet sich im Stammordner der Funktions-App. Ein Ordner bin enthält Pakete und andere Bibliotheksdateien, die von der Funktions-App benötigt werden. Bestimmte Ordnerstrukturen, die von der Funktions-App benötigt werden, sind von der Sprache abhängig:

In der Version 2.x und höheren Versionen der Functions-Runtime müssen sich alle Funktionen in der Funktions-App denselben Sprachstapel teilen.

Oben sehen Sie die standardmäßige (und empfohlene) Ordnerstruktur für eine Funktions-App. Falls Sie den Dateispeicherort des Codes einer Funktion ändern möchten, ändern Sie den Abschnitt scriptFile der Datei scriptFile. Außerdem empfehlen wir, das Projekt mithilfe der Paketbereitstellung in Ihrer Funktions-App in Azure bereitzustellen. Sie können auch vorhandene Tools wie Continuous Integration und Continuous Deployment und Azure DevOps verwenden.

Hinweis

Wenn Sie ein Paket manuell bereitstellen, müssen die Datei host.json und die Funktionsordner direkt im Ordner bereitgestellt werden. Schließen Sie den Ordner wwwroot nicht in Ihre Bereitstellungen ein. Andernfalls erhalten Sie wwwroot\wwwroot-Ordner.

Verwenden von lokalen Tools und Veröffentlichung

Funktions-Apps können mit verschiedenen Tools erstellt und veröffentlicht werden, darunter Visual Studio, Visual Studio Code, IntelliJ, Eclipse und Azure Functions Core Tools. Weitere Informationen finden Sie unter Lokales Codieren und Testen von Azure Functions.

Bearbeiten von Funktionen im Azure-Portal

Mit dem integrierten Functions-Editor im Azure-Portal können Sie Ihren Code und die Datei function.json direkt inline aktualisieren. Dies wird nur für kleine Änderungen oder Proof of Concept-Projekte empfohlen. Die bewährte Methode ist die Verwendung eines lokalen Entwicklungstools wie Visual Studio Code.

Parallele Ausführung

Wenn die Auslösung mehrerer Ereignisse schneller erfolgt als die Runtime einer Singlethreadfunktion sie verarbeiten kann, kann die Runtime die Funktion mehrmals parallel aufrufen. Wenn eine Funktionen-App den verbrauchsbasierten Hostingplan verwendet, kann die App automatisch aufskaliert werden. Jede Instanz der Funktionen-App – unabhängig davon, ob die App im verbrauchsbasierten Hostingplan oder einem regulären App Service-Hostingplan ausgeführt wird – kann gleichzeitige Funktionsaufrufe über mehrere Threads parallel verarbeiten. Die maximale Anzahl gleichzeitiger Funktionsaufrufe in jeder Funktionen-App-Instanz variiert je nach Art des verwendeten Triggers sowie je nach den Ressourcen, die von anderen Funktionen innerhalb der Funktionen-App verwendet werden.

Versionsverwaltung der Functions-Runtime

Sie können die Version der Functions-Runtime mit der App-Einstellung FUNCTIONS_EXTENSION_VERSION konfigurieren. Der Wert „~3“ bedeutet beispielsweise, dass für Ihre Funktions-App „3.x“ als Hauptversion verwendet wird. Funktions-Apps werden auf jede neue Nebenversion aktualisiert, wenn sie freigegeben werden. Weitere Informationen finden Sie unter Einstellen von Runtimeversionen von Azure Functions als Ziel, einschließlich der Informationen zum Anzeigen der genauen Version Ihrer Funktions-App.

Repositorys

Der Code für Azure Functions ist Open Source und in GitHub-Repositorys gespeichert:

Bindungen

Hier finden Sie eine Tabelle aller unterstützten Bindungen.

Die folgende Tabelle zeigt die Bindungen, die in den Hauptversionen der Azure Functions-Runtime unterstützt werden:

type 1.x 2.x und höher1 Trigger Eingabe Output
Blob Storage ✔ ✔ ✔ ✔ ✔
Azure Cosmos DB ✔ ✔ ✔ ✔ ✔
Azure SQL (Vorschauversion)2 ✔ ✔ ✔ ✔
Dapr3 ✔ ✔ ✔ ✔
Event Grid ✔ ✔ ✔ ✔
Event Hubs ✔ ✔ ✔ ✔
HTTP und Webhooks ✔ ✔ ✔ ✔
IoT Hub ✔ ✔ ✔
Kafka2 ✔ ✔ ✔
Mobile Apps ✔ ✔ ✔
Notification Hubs ✔ ✔
Queue Storage ✔ ✔ ✔ ✔
RabbitMQ2 ✔ ✔ ✔
SendGrid ✔ ✔ ✔
Service Bus ✔ ✔ ✔ ✔
SignalR ✔ ✔ ✔ ✔
Tabellenspeicherung ✔ ✔ ✔ ✔
Zeitgeber ✔ ✔ ✔
Twilio ✔ ✔ ✔

1 Ab Version 2.x der Runtime müssen alle Bindungen mit Ausnahme von HTTP und Timer registriert werden. Siehe Registrieren von Bindungserweiterungen.

2 Trigger werden im Verbrauchstarif nicht unterstützt. Erfordert runtimegesteuerte Trigger.

3 Wird nur in Kubernetes, IoT Edge und anderen selbstgehosteten Modi unterstützt.

Haben Sie Probleme mit Fehlern, die aus den Bindungen stammen? Lesen Sie die Dokumentation Fehlerbehandlung in Azure Functions.

Verbindungen

Ihr Funktionsprojekt verweist anhand des Namens auf Verbindungsinformationen aus seinem Konfigurationsanbieter. Die Verbindungsdetails werden nicht direkt akzeptiert, sodass sie in verschiedenen Umgebungen geändert werden können. Eine Triggerdefinition kann z. B. eine connection-Eigenschaft enthalten. Dies kann sich auf eine Verbindungszeichenfolge beziehen, aber Sie können die Verbindungszeichenfolge nicht direkt in einer Datei function.json festlegen. Stattdessen würden Sie connection auf den Namen einer Umgebungsvariablen festlegen, die die Verbindungszeichenfolge enthält.

Der Standardkonfigurationsanbieter verwendet Umgebungsvariablen. Diese werden möglicherweise von Anwendungseinstellungen festgelegt, wenn Sie im Azure Functions-Dienst ausgeführt werden, oder aus der lokalen Einstellungsdatei bei der lokalen Entwicklung.

Verbindungswerte

Wenn der Verbindungsname in einen einzelnen exakten Wert aufgelöst wird, identifiziert die Laufzeit den Wert als Verbindungszeichenfolge, die in der Regel ein Geheimnis enthält. Die Details einer Verbindungszeichenfolge werden durch den Dienst definiert, mit dem Sie eine Verbindung herstellen möchten.

Ein Verbindungsname kann jedoch auch auf eine Sammlung von mehreren Konfigurationselementen verweisen, die für das Konfigurieren identitätsbasierter Verbindungen nützlich ist. Umgebungsvariablen können als Sammlung behandelt werden, indem ein gemeinsames Präfix verwendet wird, das auf doppelte Unterstriche (__) endet. Auf die Gruppe kann dann verwiesen werden, indem der Verbindungsname auf dieses Präfix festgelegt wird.

Beispielsweise kann die connection-Eigenschaft für eine Azure-Blobtriggerdefinition „Storage1“ lauten. Solange kein einzelner Zeichenfolgenwert von einer Umgebungsvariablen namens „Storage1“ konfiguriert wurde, kann die blobServiceUri-Eigenschaft durch eine Umgebungsvariable namens Storage1__blobServiceUri über die Verbindung informiert werden. Die Verbindungseigenschaften unterscheiden sich für jeden Dienst. In der Dokumentation finden Sie Informationen zu der Komponente, die die Verbindung verwendet.

Hinweis

Wenn Sie Azure App Configuration oder Key Vault verwenden, um Einstellungen für Verbindungen mit verwalteter Identität bereitzustellen, sollten die Namen der Einstellungen ein gültiges Schlüsseltrennzeichen wie : oder / anstelle von __ verwenden, um sicherzustellen, dass die Namen richtig aufgelöst werden.

Beispiel: Storage1:blobServiceUri.

Konfigurieren einer identitätsbasierten Verbindung

Einige Verbindungen in Azure Functions können so konfiguriert werden, dass anstelle eines Geheimnisses eine Identität verwendet wird. Die Unterstützung hängt von der Erweiterung ab, die die Verbindung verwendet. In einigen Fällen ist möglicherweise weiterhin eine Verbindungszeichenfolge in Functions erforderlich, obwohl der Dienst, mit dem Sie eine Verbindung herstellen, identitätsbasierte Verbindungen unterstützt. Ein Tutorial zum Konfigurieren Ihrer Funktions-Apps mit verwalteten Identitäten finden Sie im Tutorial zum Erstellen einer Funktions-App mit identitätsbasierten Verbindungen.

Identitätsbasierte Verbindungen werden von den folgenden Komponenten unterstützt:

Verbindungsquelle Unterstützte Pläne Weitere Informationen
Azure Blobs-Trigger und -Bindungen Alle Azure Blobs-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Queues-Trigger und -Bindungen Alle Azure Queues-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Tables (bei Verwendung von Azure Storage) Alle Azure Tables-Erweiterung, Version 1.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Event Hubs Auslöser und Bindungen Alle Azure Event Hubs-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Service Bus Auslöser und Bindungen Alle Azure Service Bus-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Trigger und Bindungen bei Azure Cosmos DB Alle Azure Cosmos DB-Erweiterung, Version 4.0.0 oder höher,
Erweiterungspaket 4.0.2 oder höher
Durable Functions-Speicheranbieter (Azure Storage) – Vorschau Alle Durable Functions-Erweiterung, Version 2.7.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Vom Host benötigter Speicher („AzureWebJobsStorage“) – Vorschau All Verbinden zum Hostspeicher mit einer Identität

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.

Wählen Sie unten eine Registerkarte aus, um mehr über Berechtigungen für die einzelnen Komponenten zu erfahren:

Sie müssen eine Rollenzuweisung erstellen, die zur Laufzeit Zugriff auf Ihren Blobcontainer 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 zusätzliche Berechtigungen basierend auf dem von Ihnen geschriebenen Code.

Bindungstyp Integrierte Beispielrollen
Trigger Besitzer von SpeicherblobdatenundMitwirkender an Speicherblobdaten1

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. Diese werden durch die Rollen Besitzer von Speicherblobdaten, Mitwirkender an Storage-Warteschlangendaten und Speicherkontomitwirkender abgedeckt. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit dem Hostspeicher mit einer Identität.

Allgemeine Eigenschaften für identitätsbasierte Verbindungen

Eine identitätsbasierte Verbindung für einen Azure-Dienst akzeptiert die folgenden allgemeinen Eigenschaften, wobei <CONNECTION_NAME_PREFIX> der Wert Ihrer connection-Eigenschaft in der Trigger- oder Bindungsdefinition ist:

Eigenschaft Vorlage für Umgebungsvariable BESCHREIBUNG
Token-Anmeldeinformationen <CONNECTION_NAME_PREFIX>__credential Damit wird festgelegt, wie für die Verbindung ein Token abgerufen werden soll. Wird nur empfohlen, wenn eine vom Benutzer zugewiesene Identität angegeben wird. Dann muss sie auf „managedidentity“ festgelegt werden. Dies gilt nur, wenn sie im Azure Functions-Dienst gehostet wird.
Client-ID <CONNECTION_NAME_PREFIX>__clientId Wenn credential auf „managedidentity“ festgelegt ist, wird mit dieser Eigenschaft die vom Benutzer zugewiesene Identität angegeben, die beim Abrufen eines Tokens verwendet werden soll. Die Eigenschaft akzeptiert eine Client-ID, die einer vom Benutzer zugewiesenen Identität entspricht, die der Anwendung zugeordnet ist. Wenn nichts angegeben wird, wird die vom System zugewiesene Identität verwendet. Diese Eigenschaft wird in Szenarios für die lokale Entwicklung anders verwendet, wenn nicht festgelegt werden darf.

Für einen bestimmten Verbindungstyp können weitere Optionen unterstützt werden. Weitere Informationen finden Sie in der Dokumentation zu der Komponente, die die Verbindung herstellt.

Lokale Entwicklung mit identitätsbasierten Verbindungen

Hinweis

Die lokale Entwicklung mit identitätsbasierten Verbindungen erfordert aktualisierte Versionen der Azure Functions Core Tools. Sie können die derzeit installierte Version überprüfen, indem Sie func -v ausführen. Verwenden Sie für Functions v3 die Version 3.0.3904 oder höher. Verwenden Sie für Functions v4 die Version 4.0.3904 oder höher.

Bei lokaler Ausführung weist die Konfiguration oben die Laufzeit an, Ihre lokale Entwickleridentität zu verwenden. Die Verbindung versucht, ein Token von den folgenden Speicherorten in der angegebenen Reihenfolge abzurufen:

  • Lokaler Cache, der von Microsoft-Anwendungen gemeinsam genutzt wird
  • Aktueller Benutzerkontext in Visual Studio
  • Aktueller Benutzerkontext in Visual Studio Code
  • Aktueller Benutzerkontext in der Azure CLI

Wenn keine dieser Optionen erfolgreich ist, tritt ein Fehler auf.

Ihre Identität verfügt möglicherweise bereits über Rollenzuweisungen für Azure-Ressourcen, die für die Entwicklung verwendet werden. Gegebenenfalls umfassen diese Rollen jedoch nicht den erforderlichen Datenzugriff. Verwaltungsrollen wie Besitzer sind nicht ausreichend. Überprüfen Sie, welche Berechtigungen für Verbindungen für jede Komponente erforderlich sind, und stellen Sie sicher, dass sie Ihnen selbst zugewiesen sind.

In einigen Fällen möchten Sie möglicherweise die Verwendung einer anderen Identität angeben. Sie können Konfigurationseigenschaften für die Verbindung hinzufügen, die auf die alternative Identität basierend auf einer Client-ID und einem geheimen Clientschlüssel für ein Azure Active Directory-Dienstprinzipal verweisen. Diese Konfigurationsoption wird nicht unterstützt, wenn das Hosting im Azure Functions-Dienst erfolgt. Um eine ID und ein Geheimnis auf Ihrem lokalen Computer zu verwenden, definieren Sie die Verbindung mit den folgenden zusätzlichen Eigenschaften:

Eigenschaft Vorlage für Umgebungsvariable BESCHREIBUNG
Mandanten-ID <CONNECTION_NAME_PREFIX>__tenantId Die ID des Azure Active Directory-Mandanten (Verzeichnis).
Client-ID <CONNECTION_NAME_PREFIX>__clientId Die Client-ID (Anwendungs-ID) einer App-Registrierung im Mandanten.
Geheimer Clientschlüssel <CONNECTION_NAME_PREFIX>__clientSecret Ein Clientgeheimnis, das für die App-Registrierung generiert wurde.

Beispiel für local.settings.json-Eigenschaften, die für identitätsbasierte Verbindungen mit Azure Blob erforderlich sind:

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

Verbinden mit dem Hostspeicher mit einer Identität (Vorschau)

Der Azure Functions-Host verwendet die AzureWebJobsStorage-Verbindung für Kernfunktionalität wie die Koordination der Singletonausführung von Timertriggern und den Standardspeicher für App-Schlüssel. Sie kann auch so konfiguriert werden, dass eine Identität genutzt wird.

Achtung

Andere Komponenten in Functions basieren für Standardverhalten auf „AzureWebJobsStorage“. Sie sollten sie nicht in eine identitätsbasierte Verbindung verschieben, wenn Sie ältere Versionen von Erweiterungen verwenden, die diese Art von Verbindung nicht unterstützen. Dazu zählen u. a. Trigger und Bindungen für Azure-Blobs, Event Hubs und Durable Functions. Ebenso wird AzureWebJobsStorage für Bereitstellungsartefakte verwendet, wenn der serverseitig integrierte Linux-Verbrauch verwendet wird. Wenn Sie diese Option aktivieren, müssen Sie die Bereitstellung über AzureWebJobsStorage durchführen.

Außerdem verwenden einige Apps „AzureWebJobsStorage“ für andere Speicherverbindungen in ihren Triggern, Bindungen und/oder in ihrem Funktionscode wieder. Stellen Sie sicher, dass alle Benutzer*innen von „AzureWebJobsStorage“ das identitätsbasierte Verbindungsformat verwenden können, bevor Sie diese Verbindung einer Verbindungszeichenfolge ändern.

Um eine identitätsbasierte Verbindung für „AzureWebJobsStorage“ zu verwenden, konfigurieren Sie die folgenden App-Einstellungen:

Einstellung BESCHREIBUNG Beispielwert
AzureWebJobsStorage__blobServiceUri Der Datenebenen-URI des Blob-Diensts des Speicherkontos im HTTPS-Schema. https://<storage_account_name>.blob.core.windows.net
AzureWebJobsStorage__queueServiceUri Der Datenebenen-URI des Warteschlangendiensts des Speicherkontos im HTTPS-Schema. https://<storage_account_name>.queue.core.windows.net
AzureWebJobsStorage__tableServiceUri Der Datenebenen-URI eines Tabellendiensts des Speicherkontos im HTTPS-Schema. https://<speicherkonto_name>.table.core.windows.net

Allgemeine Eigenschaften für identitätsbasierte Verbindungen können auch festgelegt werden.

Wenn Sie zum Konfigurieren von AzureWebJobsStorage ein Speicherkonto verwenden, das global das DNS-Standardsuffix und den Standarddienstnamen für Azure verwendet, können Sie gemäß dem https://<accountName>.blob/queue/file/table.core.windows.net-Format stattdessen AzureWebJobsStorage__accountName auf den Namen Ihres Speicherkontos festlegen. Die Endpunkte für jeden Speicherdienst werden für dieses Konto abgeleitet. Dies funktioniert nicht, wenn sich das Speicherkonto in einer Sovereign Cloud befindet oder über ein benutzerdefiniertes DNS verfügt.

Einstellung BESCHREIBUNG Beispielwert
AzureWebJobsStorage__accountName Der Kontoname eines Speicherkontos, der nur gültig ist, wenn sich das Konto nicht in einer Sovereign Cloud befindet und nicht über ein benutzerdefiniertes DNS verfügt. Diese Syntax ist für AzureWebJobsStorage eindeutig und kann nicht für andere identitätsbasierte Verbindungen verwendet werden. <storage_account_name>

Sie müssen eine Rollenzuweisung erstellen, die den Zugriff auf das Speicherkonto für "AzureWebJobsStorage" zur Laufzeit ermöglicht. Verwaltungsrollen wie Owner sind nicht ausreichend. Die Rolle Storage Blob Data Owner deckt die grundlegenden Anforderungen von Functions Host Storage ab - die Laufzeit benötigt sowohl Lese- als auch Schreibzugriff auf Blobs und die Möglichkeit, Container zu erstellen. Diese Verbindung wird von mehreren Erweiterungen als Standardspeicherort für Blobs, Warteschlangen und Tabellen verwendet. Dabei gelten gegebenenfalls zusätzliche Anforderungen, wie in der Tabelle unten aufgeführt. Möglicherweise benötigen Sie zusätzliche Berechtigungen, wenn Sie AzureWebJobsStorage für andere Zwecke verwenden.

Durchwahl Erforderliche Rollen Erklärung
Keine Erweiterung (nur Host) Besitzer von Speicherblobdaten Wird für die allgemeine Koordination verwendet, Standardschlüsselspeicher
Azure-Blobs (nur Trigger) Alle aus:
Speicherkontomitwirkender,
Besitzer von Speicherblobdaten,
Mitwirkender an Storage-Warteschlangendaten		 Der Blobtrigger verwendet intern Azure-Warteschlangen und schreibt Blobbelege. Zu diesem Zweck wird unabhängig von der für den Trigger konfigurierten Verbindung AzureWebJobsStorage verwendet.
Azure Event Hubs (nur Trigger) (keine Abweichung von der Standardanforderung)
Besitzer von Speicherblobdaten		 In Blobs, die die AzureWebJobsStorage-Verbindung verwenden, werden Prüfpunkte beibehalten.
Trigger mit Timer (keine Abweichung von der Standardanforderung)
Besitzer von Speicherblobdaten		 Damit pro Ereignis eine Ausführung sichergestellt wird, werden bei Verwendung der AzureWebJobsStorage-Verbindung Sperren für Blobs eingesetzt.
Langlebige Funktionen Alle aus:
Mitwirkender an Storage-Blobdaten,
Mitwirkender an Storage-Warteschlangendaten,
Mitwirkender an Storage-Tabellendaten		 Durable Functions verwendet Blobs, Warteschlangen und Tabellen, um Aktivitätsfunktionen zu koordinieren und den Orchestrierungszustand zu verwalten. Standardmäßig wird für all diese Zwecke die AzureWebJobsStorage-Verbindung verwendet. Sie können in der Konfiguration der Durable Functions-Erweiterung jedoch eine andere Verbindung angeben.

Melden von Problemen

Element BESCHREIBUNG Link
Laufzeit Script Host, Trigger und Bindungen, Sprachunterstützung Anlegen eines Eintrags
Vorlagen Vorlage für Codeprobleme bei der Erstellung Anlegen eines Eintrags
Portal Probleme mit der Benutzeroberfläche Anlegen eines Eintrags

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Ressourcen: