Freigeben über

Azure Functions: Entwicklerhandbuch

In Azure Functions teilen sich alle Funktionen einige wichtige technische Konzepte und Komponenten, unabhängig von Ihrer bevorzugten Entwicklungssprache oder -umgebung. Dieser Artikel ist sprachspezifisch. Wählen Sie am Anfang des Artikels Ihre bevorzugte Entwicklungssprache aus.

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

Wenn Sie lieber direkt einsteigen möchten, können Sie ein Schnellstart-Tutorial mit Visual Studio, Visual Studio Code oder über die Eingabeaufforderung durchführen.

Wenn Sie lieber direkt einsteigen möchten, können Sie ein Schnellstart-Tutorial mit Maven (Befehlszeile), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud oder Visual Studio Code durchführen.

Wenn Sie lieber direkt einsteigen möchten, können Sie ein Schnellstart-Tutorial mit Visual Studio Code oder über die Eingabeaufforderung durchführen.

Wenn Sie lieber direkt einsteigen möchten, können Sie ein Schnellstart-Tutorial mit Visual Studio Code oder über die Eingabeaufforderung durchführen.

Wenn Sie lieber direkt einsteigen möchten, können Sie ein Schnellstart-Tutorial mit Visual Studio Code oder über die Eingabeaufforderung durchführen.

Wenn Sie lieber direkt einsteigen möchten, können Sie ein Schnellstart-Tutorial mit Visual Studio Code oder über die Eingabeaufforderung durchführen.

Code-Projekt

Im Kern von Azure Functions ist ein sprachspezifisches Codeprojekt, das eine oder mehrere Einheiten der Codeausführung implementiert, die als Funktionen bezeichnet werden. Funktionen sind einfach Methoden, die in der Azure-Cloud basierend auf Ereignissen, als Reaktion auf HTTP-Anforderungen oder nach einem Zeitplan ausgeführt werden. Stellen Sie sich Ihr Azure Functions-Codeprojekt als Mechanismus zum Organisieren, Bereitstellen und gemeinsamen Verwalten Ihrer einzelnen Funktionen im Projekt vor, wenn diese in Azure ausgeführt werden. Weitere Informationen finden Sie unter Organisieren von Funktionen.

Die Art und Weise, wie Sie Ihr Codeprojekt gestalten und angeben, welche Methoden in Ihrem Projekt Funktionen sind, hängt von der Entwicklungssprache Ihres Projekts ab. Ausführliche sprachspezifische Anleitungen finden Sie im Leitfaden für C#-Entwickelnde.

Die Art und Weise, wie Sie Ihr Codeprojekt gestalten und angeben, welche Methoden in Ihrem Projekt Funktionen sind, hängt von der Entwicklungssprache Ihres Projekts ab. Ausführliche sprachspezifische Anleitungen finden Sie im Leitfaden für Java-Entwickelnde.

Die Art und Weise, wie Sie Ihr Codeprojekt gestalten und angeben, welche Methoden in Ihrem Projekt Funktionen sind, hängt von der Entwicklungssprache Ihres Projekts ab. Ausführliche sprachspezifische Anleitungen finden Sie im Leitfaden für Node.js-Entwickelnde.

Die Art und Weise, wie Sie Ihr Codeprojekt gestalten und angeben, welche Methoden in Ihrem Projekt Funktionen sind, hängt von der Entwicklungssprache Ihres Projekts ab. Ausführliche sprachspezifische Anleitungen finden Sie im Leitfaden für PowerShell-Entwickelnde.

Die Art und Weise, wie Sie Ihr Codeprojekt gestalten und angeben, welche Methoden in Ihrem Projekt Funktionen sind, hängt von der Entwicklungssprache Ihres Projekts ab. Ausführliche sprachspezifische Anleitungen finden Sie im Leitfaden für Python-Entwickelnde.

Alle Funktionen müssen über einen Trigger verfügen, der definiert, wie die Funktion gestartet wird und der Eingaben in die Funktion machen kann. Ihre Funktionen können optional Eingabe- und Ausgabebindungen definieren. Diese Bindungen vereinfachen Verbindungen mit anderen Diensten, ohne dass Sie mit Client-SDKs arbeiten müssen. Weitere Informationen finden Sie unter Konzepte für Azure Functions-Trigger und -Bindungen.

Azure Functions stellt eine Reihe sprachspezifischer Projekt- und Funktionsvorlagen bereit, die das Erstellen neuer Codeprojekte und das Hinzufügen von Funktionen zu Ihrem Projekt vereinfachen. Sie können jedes der Tools verwenden, die die Azure Functions-Entwicklung unterstützen, um mithilfe dieser Vorlagen neue Apps und Funktionen zu generieren.

Entwicklungstools

Die folgenden Tools bieten eine integrierte Entwicklungs- und Veröffentlichungsumgebung für Azure Functions in Ihrer bevorzugten Sprache:

Diese Tools sind in Azure Functions Core Tools integriert, sodass Sie sie mit der Functions-Runtime auf Ihrem lokalen Computer ausführen und debuggen können. Weitere Informationen finden Sie unter Lokales Codieren und Testen von Azure Functions.

Es gibt auch einen Editor im Azure-Portal, mit dem Sie Ihren Code und Ihre Definitionsdatei function.json direkt aktualisieren können. Sie sollten diesen Editor nur für kleine Änderungen oder das Erstellen von Proof-of-Concept-Funktionen verwenden. Sie sollten Ihre Funktionen nach Möglichkeit immer lokal entwickeln. Weitere Informationen finden Sie unter Erstellen Ihrer ersten Funktion im Azure-Portal.

Die Portalbearbeitung wird nur für Node.js Version 3 unterstützt, die die Datei function.json verwendet.

Bereitstellung

Wenn Sie Ihr Codeprojekt in Azure veröffentlichen, stellen Sie Ihr Projekt im Wesentlichen in einer vorhandenen Funktions-App-Ressource bereit. 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. Aus der Perspektive einer Azure-Ressource entspricht eine Funktions-App einer Websiteressource (Microsoft.Web/sites) im Azure App Service, was einer Web-App entspricht.

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. Weitere Informationen finden Sie unter Verwalten von Funktions-Apps.

Wenn die Funktions-App und andere erforderliche Ressourcen noch nicht in Azure vorhanden sind, müssen Sie diese Ressourcen zuerst erstellen, bevor Sie Ihre Projektdateien bereitstellen können. Sie können diese Ressourcen auf eine der folgenden Arten erstellen:

Zusätzlich zur toolbasierten Veröffentlichung unterstützt Functions andere Technologien zum Bereitstellen von Quellcode in einer vorhandenen Funktions-App. Weitere Informationen finden Sie unter Bereitstellungstechnologien in Azure Functions.

Verbinden mit Diensten

Eine wichtige Anforderung eines cloudbasierten Computediensts ist das Lesen von Daten aus anderen Clouddiensten und das Schreiben von Daten in andere Clouddienste. Functions bietet eine umfangreiche Gruppe von Bindungen, die es Ihnen erleichtern, eine Verbindung mit Diensten herzustellen, ohne mit Client-SDKs arbeiten zu müssen.

Unabhängig davon, ob Sie die von Functions bereitgestellten Bindungserweiterungen verwenden oder direkt mit Client-SDKs arbeiten, speichern Sie Verbindungsdaten an einem sicheren Ort und fügen Sie sie nicht in Ihren Code ein. Weitere Informationen finden Sie unter Verbindungen.

Bindungen

Functions stellt Bindungen für viele Azure-Dienste und einige Dienste von Drittanbietern bereit, die als Erweiterungen implementiert werden. Weitere Informationen finden Sie in der vollständigen Liste der unterstützten Bindungen.

Bindungserweiterungen können sowohl Ein- als auch Ausgaben unterstützen, und viele Trigger fungieren auch als Eingabebindungen. Mit Bindungen können Sie die Verbindung mit Diensten so konfigurieren, dass der Funktionshost den Datenzugriff für Sie verarbeiten kann. Weitere Informationen finden Sie unter Konzepte für Azure Functions-Trigger und -Bindungen.

Wenn Sie Probleme mit Fehlern haben, die von Bindungen stammen, lesen Sie die Dokumentation zu Azure Functions-Bindungsfehlercodes.

Client-SDKs

Während Functions Bindungen bereitstellt, um den Datenzugriff in Ihrem Funktionscode zu vereinfachen, können Sie dennoch ein Client-SDK in Ihrem Projekt verwenden, um direkt auf einen bestimmten Dienst zuzugreifen. Möglicherweise müssen Sie Client-SDKs direkt verwenden, wenn Ihre Funktionen eine Funktionalität des zugrunde liegenden SDK benötigen, die von der Bindungserweiterung nicht unterstützt wird.

Wenn Sie Client-SDKs verwenden, sollten Sie denselben Prozess zum Speichern und Zugreifen auf Verbindungszeichenfolgen verwenden, der von Bindungserweiterungen verwendet wird.

Wenn Sie eine Client-SDK-Instanz in Ihren Funktionen erstellen, sollten Sie die vom Client benötigten Verbindungsinformationen aus den Umgebungsvariablen abrufen.

Wenn Sie eine Client-SDK-Instanz in Ihren Funktionen erstellen, sollten Sie die vom Client benötigten Verbindungsinformationen aus den Umgebungsvariablen abrufen.

Wenn Sie eine Client-SDK-Instanz in Ihren Funktionen erstellen, sollten Sie die vom Client benötigten Verbindungsinformationen aus den Umgebungsvariablen abrufen.

Wenn Sie eine Client-SDK-Instanz in Ihren Funktionen erstellen, sollten Sie die vom Client benötigten Verbindungsinformationen aus den Umgebungsvariablen abrufen.

Wenn Sie eine Client-SDK-Instanz in Ihren Funktionen erstellen, sollten Sie die vom Client benötigten Verbindungsinformationen aus den Umgebungsvariablen abrufen.

Verbindungen

Als bewährte Sicherheitsmethode nutzt Azure Functions die Anwendungseinstellungsfunktionen von Azure App Service, um Zeichenfolgen, Schlüssel und andere Token, die für die Verbindung mit anderen Diensten erforderlich sind, sicherer zu speichern. Anwendungseinstellungen in Azure werden verschlüsselt gespeichert und können zur Laufzeit von Ihrer App als Umgebungsvariablen-name/value-Paare aufgerufen werden. Für Trigger und Bindungen, die eine Verbindungseigenschaft erfordern, legen Sie den Namen der Anwendungseinstellung anstelle der tatsächlichen Verbindungszeichenfolge fest. Sie können eine Bindung nicht direkt mit einer Verbindungszeichenfolge oder einem Schlüssel konfigurieren.

Betrachten Sie beispielsweise eine Triggerdefinition, die über eine connection-Eigenschaft verfügt. Anstatt die Verbindungszeichenfolge zu verwenden, legen Sie connection auf den Namen einer Umgebungsvariable fest, welche die Verbindungszeichenfolge enthält. Die Verwendung dieser Strategie für den Zugriff auf geheime Informationen erhöht die Sicherheit Ihrer Apps und vereinfacht das Ändern von Verbindungen in verschiedenen Umgebungen. Für noch mehr Sicherheit können Sie identitätsbasierte Verbindungen verwenden.

Der Standardkonfigurationsanbieter verwendet Umgebungsvariablen. Diese Variablen werden bei der Ausführung in Azure in den Anwendungseinstellungen und bei der lokalen Entwicklung in der lokalen Einstellungsdatei definiert.

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 Eigenschaft connection für eine Azure-Blobtriggerdefinition Storage1 lauten. Solange kein einzelner Zeichenfolgenwert von einer Umgebungsvariablen mit dem Namen Storage1 konfiguriert wurde, kann die Eigenschaft Storage1__blobServiceUri durch eine Umgebungsvariable mit dem Namen 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 verwaltete Identitätsverbindungen bereitzustellen, sollten Einstellungsnamen ein gültiges Schlüsseltrennzeichen wie z. B. : oder / anstelle der __ Namen verwenden, um sicherzustellen, dass Namen ordnungsgemäß 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 Laufzeitversion und der Erweiterung, die die Verbindung verwendet, ab. 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.

Hinweis

Bei der Ausführung in einem Verbrauchs- oder Elastic Premium-Plan verwendet Ihre App die Einstellungen WEBSITE_AZUREFILESCONNECTIONSTRING und WEBSITE_CONTENTSHARE zum Herstellen einer Verbindung mit Azure Files für das Speicherkonto, das von Ihrer Funktions-App verwendet wird. Die Verwendung einer verwalteten Identität beim Zugriff auf die Dateifreigabe wird von Azure Files nicht unterstützt. Weitere Informationen finden Sie unter Unterstützte Azure Files-Authentifizierungsszenarien.

Identitätsbasierte Verbindungen werden nur für Functions 4.x unterstützt. Wenn Sie Version 1.x verwenden, müssen Sie zuerst zu Version 4.x migrieren.

Die folgenden Komponenten unterstützen identitätsbasierte Verbindungen:

Verbindungsquelle Unterstützte Pläne Weitere Informationen
Azure Blobs-Trigger und -Bindungen All Azure Blobs-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Queues-Trigger und -Bindungen All Azure Queues-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Tables (bei Verwendung von Azure Storage) All Azure Tables-Erweiterung, Version 1.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure SQL-Datenbank All Verbinden einer Funktions-App in Azure SQL mit verwalteter Identität und SQL-Bindungen
Azure Event Hubs Auslöser und Bindungen All 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 All Azure Service Bus-Erweiterung, Version 5.0.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Azure Event Grid-Ausgabebindung All Azure Event Grid Erweiterung Version 3.3.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Trigger und Bindungen bei Azure Cosmos DB All Azure Cosmos DB-Erweiterung, Version 4.0.0 oder höher,
Erweiterungspaket 4.0.2 oder höher
Azure SignalR-Trigger und -Bindungen All Azure SignalR-Erweiterungsversion 1.7.0 oder höher
Erweiterungsbündel 3.6.1 oder höher
Durable Functions-Speicheranbieter (Azure Storage) All Durable Functions-Erweiterung, Version 2.7.0 oder höher,
Erweiterungspaket 3.3.0 oder höher
Vom Host benötigter Speicher („AzureWebJobsStorage“) 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 eine der folgenden Registerkarten aus, um mehr über Berechtigungen für jede Komponente zu erfahren:

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
Auslöser 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. 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.

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 Diese Eigenschaft bestimmt, wie ein Token für die Verbindung abgerufen werden soll. Die Eigenschaft sollte nicht in lokalen Entwicklungsszenarien festgelegt werden. Wenn Sie die verwaltete Identitätsauthentifizierung verwenden möchten, legen Sie diese Eigenschaft auf managedidentity. Wenn Sie eine Verbindung mit einer Ressource in einem anderen Mandanten herstellen möchten, verwenden Sie stattdessen managedidentityasfederatedidentity.
Client-ID <CONNECTION_NAME_PREFIX>__clientId Wenn credential auf managedidentity festgelegt ist, kann mit dieser Eigenschaft die benutzerseitig zugewiesene Identität angegeben werden, 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. Es ist nicht möglich, sowohl eine Ressourcen-ID als auch eine Client-ID anzugeben. Wenn nichts angegeben wird, wird die vom System zugewiesene Identität verwendet.

Diese Eigenschaft wird in mandantenübergreifenden Szenarien unterschiedlich verwendet. Weitere Informationen finden Sie im Abschnitt "Mandantenübergreifende Szenarien ".

Diese Eigenschaft wird in Szenarien für die lokale Entwicklung anders verwendet, in denen credential nicht festgelegt werden darf.
Ressourcen-ID <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Wenn credential auf managedidentity festgelegt ist, kann mit dieser Eigenschaft die benutzerseitig zugewiesene Identität angegeben werden, die beim Abrufen eines Tokens verwendet werden soll. Die Eigenschaft akzeptiert einen Ressourcenbezeichner, der einer der Anwendung zugewiesenen Benutzeridentität entspricht. Es ist nicht möglich, sowohl eine Ressourcen-ID als auch eine Client-ID anzugeben. Wenn nichts angegeben wird, wird die vom System zugewiesene Identität verwendet.

Für bestimmte Verbindungstypen können unter Umständen weitere Optionen unterstützt werden. Weitere Informationen zu der Komponente, die die Verbindung herstellt, finden Sie in der Dokumentation.

Azure SDK-Umgebungsvariablen

Vorsicht

Die Verwendung der Umgebungsvariablen EnvironmentCredential des Azure SDK wird aufgrund der potenziell unbeabsichtigten Auswirkungen auf andere Verbindungen nicht empfohlen. Sie werden auch nicht vollständig unterstützt, wenn sie in Azure Functions bereitgestellt werden.

Die Umgebungsvariablen EnvironmentCredential, die dem Azure SDK zugeordnet sind, können auch festgelegt werden, aber diese werden nicht vom Functions-Dienst für die Skalierung in Verbrauchsplänen verarbeitet. Diese Umgebungsvariablen sind nicht spezifisch für eine Verbindung und gelten als Standard, es sei denn, eine entsprechende Eigenschaft ist für eine bestimmte Verbindung nicht festgelegt. Wenn beispielsweise AZURE_CLIENT_ID festgelegt ist, wird dies so verwendet, als wäre <CONNECTION_NAME_PREFIX>__clientId konfiguriert worden. Die explizite <CONNECTION_NAME_PREFIX>__clientId-Einstellung würde diese Standardeinstellung außer Kraft setzen.

Lokale Entwicklung mit identitätsbasierten Verbindungen

Hinweis

Die lokale Entwicklung mit identitätsbasierten Verbindungen erfordert Version 4.0.3904 der Azure Functions Core Tools oder eine neuere Version.

Wenn Sie Ihr Funktionsprojekt lokal ausführen, weist die obige Konfiguration die Runtime an, Ihre lokale Entwicklungsidentitä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 einen Microsoft Entra-Dienstprinzipal verweisen. Diese Konfigurationsoption wird nicht unterstützt, wenn das Hosting im Azure Functions-Dienst erfolgt. Um eine ID und ein geheime Informationen 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 Microsoft Entra-Mandanten-ID (Verzeichnis-ID).
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.

Hier sehen Sie ein Beispiel für local.settings.json-Eigenschaften, die für identitätsbasierte Verbindungen mit Azure-Blobs 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 zum Hostspeicher mit einer Identität

Der Azure Functions-Host verwendet die Speicherverbindung, die in AzureWebJobsStorage festgelegt wurde, für Kernfunktionalität wie die Koordination der Singletonausführung von Timertriggern und den Standardspeicher für App-Schlüssel. Diese Verbindung kann auch für die Verwendung einer Identität konfiguriert werden.

Vorsicht

Andere Komponenten in Functions verwenden AzureWebJobsStorage für Standardverhalten. 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 ein externes Bereitstellungspaket durchführen.

Darüber hinaus kann Ihre Funktions-App AzureWebJobsStorage für andere Speicherverbindungen in ihren Triggern, ihren Bindungen und/oder ihrem Funktionscode wiederverwenden. Stellen Sie sicher, dass bei Verwendung von AzureWebJobsStorage immer das identitätsbasierte Verbindungsformat verwendet werden kann, bevor Sie diese Verbindung durch eine 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 AzureWebJobsStorage über ein Speicherkonto konfigurieren, das global das standardmäßige DNS-Suffix und den standardmäßigen Dienstnamen für Azure verwendet, können Sie stattdessen https://<accountName>.[blob|queue|file|table].core.windows.net gemäß dem AzureWebJobsStorage__accountName-Format 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 wenn es ü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. <Speicherkonto_Name>

Sie müssen eine Rollenzuweisung erstellen, die den Zugriff auf das Speicherkonto für "AzureWebJobsStorage" zur Laufzeit ermöglicht. Verwaltungsrollen wie Besitzer 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 auch andere Berechtigungen, wenn Sie "AzureWebJobsStorage" für andere Zwecke verwenden.

Durchwahl Erforderliche Rollen Erklärung
Keine Erweiterung (nur Host) Besitzer von Speicherblobdaten Funktionen verwenden BLOB-Speicher für die allgemeine Koordination und als Standardschlüsselspeicher.

Dieses Szenario stellt den minimalen Satz von Berechtigungen für den normalen Betrieb dar, enthält jedoch keine Unterstützung für Diagnoseereignisse1.
No extension (host only), with support for diagnostic events1 Keine Erweiterung (nur Host), mit Unterstützung für Diagnoseereignisse1 Besitzer von Speicherblobdaten,
Mitwirkender an Storage-Tabellendaten		 Diagnoseereignisse werden mithilfe der AzureWebJobsStorage-Verbindung im Tabellenspeicher beibehalten.
Azure-Blobs (nur Trigger) Alle der Folgenden:
Speicherkontomitwirkender,
Besitzer von Speicherblobdaten,
Mitwirkender an Storage-Warteschlangendaten		 Der Blobtrigger verwendet intern Azure-Warteschlangen und schreibt Blobbelege. Sie verwendet die AzureWebJobsStorage-Verbindung für diese Zwecke, unabhängig von der für den Trigger konfigurierten Verbindung.
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 der Folgenden:
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. Sie verwendet standardmäßig die AzureWebJobsStorage-Verbindung, aber Sie können eine andere Verbindung in der Erweiterungskonfiguration für dauerhafte Funktionen angeben.

1 Bei einigen Arten von Problemen kann Azure Functions ein Diagnoseereignis auslösen, das bei der Problembehandlung helfen kann, auch wenn das Problem verhindert, dass die Funktions-App gestartet wird. Wenn Mitwirkender für Speichertabellendaten nicht zugewiesen ist, werden möglicherweise Warnungen in Ihren Protokollen angezeigt, die darauf hinweisen, dass die Ergebnisse nicht geschrieben werden können.

Herstellen einer Verbindung mit einer Ressource in einem anderen Mandanten

Wenn Ihre Funktion eine Verbindung mit einer Ressource in einem anderen Microsoft Entra-Mandanten herstellen muss, sollte Ihre Verbindung federierte Identitätsnachweise verwenden. Dies erfordert eine vom Benutzer zugewiesene verwaltete Identität und eine mandantenfähige Entra ID-App-Registrierung. Sie können keine vom System zugewiesene verwaltete Identität für mandantenübergreifende Verbindungen verwenden.

Wichtig

Wenn Sie einen Trigger für eine mandantenübergreifende Verbindung in den Typen "Verbrauch" oder "Flex-Verbrauch" konfigurieren, skaliert die Plattform die Funktions-App nicht mehr basierend auf diesem Trigger.

Um eine mandantenübergreifende identitätsbasierte Verbindung zu konfigurieren, müssen Sie zunächst Ihre Infrastruktur mit den folgenden Schritten einrichten:

  1. Im Mandanten, in dem Ihre Function App bereitgestellt ist, erstellen Sie eine neue, vom Benutzer zugewiesene verwaltete Identität.
  2. Weisen Sie diese Identität der Funktions-App zu.
  3. Erstellen Sie im selben Mandanten eine Entra-App-Registrierung mit mehreren Mandanten , die die mandantenübergreifende Ressource darstellt, auf die Sie zugreifen möchten.
  4. Fügen Sie die verwaltete Identität als Verbundidentitätsanmeldeinformationen für die App-Registrierung hinzu.
  5. Erstellen Sie in dem Mandanten, in dem die Ressource bereitgestellt wird, eine Unternehmensanwendung für die App-Registrierung.
  6. Weisen Sie berechtigungen für die Unternehmensanwendung zu, um auf die Ressource zuzugreifen.

Eine mandantenübergreifende, identitätsbasierte Verbindung verwendet die folgenden 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 Erforderlich. Wenn Sie eine Verbindung mit einer Ressource in einem anderen Mandanten herstellen, legen Sie diese Eigenschaft auf managedidentityasfederatedidentity.
Azure Cloud <CONNECTION_NAME_PREFIX>__azureCloud Erforderlich. Diese Eigenschaft bestimmt die Azure-Cloudumgebung. Zulässige Werte sind "öffentlich" für Azure Public Cloud, "usgov" für Azure US Government Cloud und "china" für Azure, betrieben von 21Vianet.
Client-ID <CONNECTION_NAME_PREFIX>__clientId Erforderlich. Wenn credential auf managedidentityasfederatedidentity festgelegt ist, setzen Sie diese Eigenschaft auf die Client-ID (App-ID) der App-Registrierung.

Diese Eigenschaft wird in einzelmandanten-identitätsbasierten Verbindungen unterschiedlich verwendet. Weitere Informationen finden Sie im Abschnitt "Allgemeine Eigenschaften" .

Diese Eigenschaft wird in Szenarien für die lokale Entwicklung anders verwendet, in denen credential nicht festgelegt werden darf.
Mandanten-ID <CONNECTION_NAME_PREFIX>__tenantId Erforderlich. Wenn credential auf managedidentityasfederatedidentity gesetzt ist, setzen Sie diese Eigenschaft auf die Mandanten-ID des Ressourcenmandanten.

Diese Eigenschaft wird in Szenarien für die lokale Entwicklung anders verwendet, in denen credential nicht festgelegt werden darf.
Verwaltete Identitätsclient-ID <CONNECTION_NAME_PREFIX>__managedIdentityClientId Wenn credential diese Eigenschaft auf managedidentityasfederatedidentity festgelegt ist, gibt diese Eigenschaft die vom Benutzer zugewiesene Identität an, die Sie als Verbundidentitätsanmeldeinformationen konfiguriert und der Anwendung zugewiesen haben.1 Die Eigenschaft akzeptiert eine Client-ID, die dieser vom Benutzer zugewiesenen Identität entspricht.
Objekt-ID der verwalteten Identität <CONNECTION_NAME_PREFIX>__managedIdentityObjectId Wenn credential diese Eigenschaft auf managedidentityasfederatedidentity festgelegt ist, gibt diese Eigenschaft die vom Benutzer zugewiesene Identität an, die Sie als Verbundidentitätsanmeldeinformationen konfiguriert und der Anwendung zugewiesen haben.1 Die Eigenschaft akzeptiert eine Objekt-ID (Prinzipal-ID), die dieser vom Benutzer zugewiesenen Identität entspricht.
Verwaltete Identitätsressourcen-ID <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Wenn credential diese Eigenschaft auf managedidentityasfederatedidentity festgelegt ist, gibt diese Eigenschaft die vom Benutzer zugewiesene Identität an, die Sie als Verbundidentitätsanmeldeinformationen konfiguriert und der Anwendung zugewiesen haben.1 Die Eigenschaft akzeptiert einen Ressourcenbezeichner, der dieser vom Benutzer zugewiesenen Identität entspricht.

1 Wenn credential auf managedidentityasfederatedidentity eingestellt ist, muss Ihre Verbindung genau einen von managedIdentityClientId, managedIdentityObjectId oder managedIdentityResourceId spezifizieren.

Dies wird auch vom Azure SDK in einem JSON-Format dokumentiert.

Melden von Problemen

Element BESCHREIBUNG Verknüpfung
Typ Script Host, Trigger und Bindungen, Sprachunterstützung Anlegen eines Eintrags
Vorlagen Vorlage für Codeprobleme bei der Erstellung Anlegen eines Eintrags

Open Source-Repositorys

Der Code für Azure Functions ist Open Source. Wichtige Komponenten finden Sie in diesen GitHub-Repositorys:

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Ressourcen:

  • Last updated on