Teilen über

Lokales Codieren und Testen von Azure Functions

  • Artikel

Obwohl Azure Functions im Azure portal entwickelt und getestet werden kann, bevorzugen viele Entwickler jedoch dafür eine lokale Entwicklungsumgebung. Mit Functions können Sie einfach Ihren bevorzugten Code-Editor und Ihre bevorzugten Entwicklungstools zum Erstellen und Testen von Funktionen auf dem lokalen Computer verwenden. Die lokalen Funktionen können mit Live-Azure-Diensten verbunden werden, und Sie können sie unter Verwendung der vollständigen Functions-Runtime auf dem lokalen Computer debuggen.

Dieser Artikel enthält Links zu bestimmten Entwicklungsumgebungen für Ihre bevorzugte Sprache. Er bietet auch einige Anleitungen für lokale Entwicklung, z. B. für das Arbeiten mit der Datei local.settings.json.

Lokale Entwicklungsumgebungen

Die Art und Weise, wie Sie Funktionen auf dem lokalen Computer entwickeln, hängt von der verwendeten Sprache und den Tooleinstellungen ab. Die lokale Entwicklung wird in den in der folgenden Tabelle aufgeführten Umgebungen unterstützt:

Environment Languages BESCHREIBUNG
Visual Studio Code C# (In-Process)
C# (isolierter Workerprozess)
JavaScript
PowerShell
Python		 Die Azure Functions-Erweiterung für VS Code erweitert die Functions-Unterstützung um VS Code. Erfordert Core Tools. Unterstützt die Entwicklung unter Linux, macOS und Windows bei Verwendung von Version 2.x der Core Tools. Weitere Informationen finden Sie unter Erstellen Ihrer ersten Funktion mit Visual Studio Code.
Eingabeaufforderung oder Terminal C# (In-Process)
C# (isolierter Workerprozess)
JavaScript
PowerShell
Python		 Azure Functions Core Tools umfasst die Core-Runtime und Vorlagen zum Erstellen von Funktionen, die die lokale Entwicklung ermöglichen. In Version 2.x wird die Entwicklung unter Linux, macOS und Windows unterstützt. Für die lokale Functions-Runtime basieren alle Umgebungen auf Core Tools.
Visual Studio C# (In-Process)
C# (isolierter Workerprozess)		 Die Azure Functions-Tools sind ab Visual Studio 2019 im Workload für Azure-Entwicklung von Visual Studio enthalten. Hiermit können Sie Funktionen in einer Klassenbibliothek kompilieren und die DLL-Datei in Azure veröffentlichen. Enthält die Core Tools für lokale Tests. Weitere Informationen finden Sie unter Entwickeln von Azure Functions mithilfe von Visual Studio.
Maven (verschiedene) Java Der Maven-Archetyp unterstützt die Core Tools, um die Entwicklung von Java-Funktionen zu ermöglichen. In Version 2.x wird die Entwicklung unter Linux, macOS und Windows unterstützt. Weitere Informationen finden Sie unter Erstellen der ersten Funktion mit Java und Maven. Unterstützt auch die Entwicklung mit Eclipse und IntelliJ IDEA.

Hinweis

Aufgrund von Einschränkungen beim Bearbeiten von Funktionscode im Azure-Portal sollten Sie Ihre Funktionen lokal entwickeln und Ihr Codeprojekt in einer Funktions-App in Azure veröffentlichen. Weitere Informationen finden Sie unter Entwicklungseinschränkungen im Azure-Portal

In jeder dieser lokalen Entwicklungsumgebungen können Sie Funktions-App-Projekte erstellen und vordefinierte Funktionsvorlagen zum Erstellen neuer Funktionen verwenden. In jeder wird Core Tools verwendet, sodass Sie Ihre Funktionen in der echten Functions-Runtime auf Ihrem eigenen Computer testen und debuggen können, so wie Sie dies für alle anderen Apps auch tun. Außerdem können Sie Ihr Funktions-App-Projekt in jeder dieser Umgebungen in Azure veröffentlichen.

Lokale Projektdateien

Ein Functions-Projektverzeichnis enthält die folgenden Dateien im Projektstammordner, unabhängig von der Programmiersprache:

Dateiname BESCHREIBUNG
host.json Weitere Informationen finden Sie in der Referenz zu „host.json“.
local.settings.json Einstellungen, die bei lokaler Ausführung von Core Tools verwendet werden, einschließlich App-Einstellungen. Weitere Informationen finden Sie in der lokalen Einstellungsdatei.
.gitignore Verhindert, dass die Datei „local.settings.json“ versehentlich in einem Git-Repository veröffentlicht wird. Weitere Informationen finden Sie in der lokalen Einstellungsdatei.
.vscode\extensions.json Datei mit Einstellungen, die beim Öffnen des Projektordners in Visual Studio Code verwendet wird.

Andere Dateien im Projekt hängen von Ihrer Programmiersprache und bestimmten Funktionen ab. Weitere Informationen finden Sie im Entwicklerhandbuch für Ihre Programmiersprache.

Datei für lokale Einstellungen

Die Datei „local.settings.json“ speichert App-Einstellungen und Einstellungen, die von lokalen Entwicklungstools verwendet werden. Einstellungen in der Datei „local.settings.json“ werden nur bei der lokalen Ausführung Ihrer Projekte verwendet. Wenn Sie Ihr Projekt in Azure veröffentlichen, müssen Sie auch alle erforderlichen Einstellungen zu den App-Einstellungen für die Funktions-App hinzufügen.

Wichtig

Da die Datei „local.settings.json“ möglicherweise Geheimnisse wie Verbindungszeichenfolgen enthält, sollten Sie sie niemals in einem Remoterepository speichern. Tools, die Functions unterstützen, bieten Möglichkeiten zum Synchronisieren von Einstellungen in der Datei „local.settings.json“ mit den App-Einstellungen in der Funktions-App, in der Ihr Projekt bereitgestellt wird.

Die Datei mit den lokalen Einstellungen hat folgende Struktur:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "<language worker>",
    "AzureWebJobsStorage": "<connection-string>",
    "MyBindingConnection": "<binding-connection-string>",
    "AzureWebJobs.HttpExample.Disabled": "true"
  },
  "Host": {
    "LocalHttpPort": 7071,
    "CORS": "*",
    "CORSCredentials": false
  },
  "ConnectionStrings": {
    "SQLConnectionString": "<sqlclient-connection-string>"
  }
}

Diese Einstellungen werden bei der lokalen Ausführung von Projekten unterstützt:

Einstellung BESCHREIBUNG
IsEncrypted Wenn diese Einstellung auf true festgelegt wird, werden alle Werte mithilfe eines Schlüssels des lokalen Computers verschlüsselt. Wird mit func settings-Befehlen verwendet. Der Standardwert ist false. Es empfiehlt sich ggf., die Datei „local.settings.json“ auf dem lokalen Computer zu verschlüsseln, wenn sie Geheimnisse (etwa Dienstverbindungszeichenfolgen) enthält. Der Host entschlüsselt die Einstellungen bei der Ausführung automatisch. Verwenden Sie den Befehl func settings decrypt, bevor Sie versuchen, lokal verschlüsselte Einstellungen zu lesen.
Values Eine Sammlung von Anwendungseinstellungen, die bei der lokalen Ausführung eines Projekts verwendet wird. Diese Schlüssel-Wert-Paare (Zeichenfolge-Zeichenfolge) entsprechen den Anwendungseinstellungen in Ihrer Funktions-App in Azure, etwa AzureWebJobsStorage. Viele Trigger und Bindungen verfügen über eine Eigenschaft, die auf eine App-Einstellung für die Verbindungszeichenfolge verweist, z. B. Connection für den Connection. Für diese Eigenschaften muss eine Anwendungseinstellung im Array Values definiert sein. Eine Liste der häufig verwendeten Einstellungen finden Sie in der nachfolgenden Tabelle.
Werte müssen Zeichenfolgen und dürfen nicht JSON-Objekte oder Arrays sein. Einstellungsnamen dürfen weder einen Doppelpunkt (__) noch einen doppelten Unterstrich (:) enthalten. Doppelte Unterstriche sind von der Runtime reserviert, und der Doppelpunkt ist für die Unterstützung der Abhängigkeitsinjektion reserviert.
Host Die Einstellungen in diesem Abschnitt passen den Hostprozess von Functions bei der lokalen Ausführung von Projekten an. Diese Einstellungen sind getrennt von den host.json-Einstellungen, die auch bei der Ausführung von Projekten in Azure angewendet werden.
LocalHttpPort Legt den Standardport fest, der bei der Ausführung des lokalen Functions-Host verwendet wird (func host start und func run). Die Befehlszeilenoption --port hat Vorrang vor dieser Einstellung. Beispiel: Bei der Ausführung in der Visual Studio-IDE können Sie die Portnummer ändern, indem Sie zum Fenster „Projekteigenschaften“ > „Debuggen“ navigieren und die Portnummer im Befehl host start --port <your-port-number> angeben, der im Feld „Anwendungsargumente“ eingegeben werden kann.
CORS Definiert die für die Ressourcenfreigabe zwischen verschiedenen Ursprüngen (CORS) zulässigen Ursprünge. Ursprünge werden als durch Trennzeichen getrennte Liste ohne Leerzeichen bereitgestellt. Den Platzhalterwert (*) wird unterstützt, wodurch Anforderungen von einem beliebigen Ursprung zulässig sind.
CORSCredentials Wird true festgelegt, sind Anforderungen vom Typ withCredentials zulässig.
ConnectionStrings Eine Auflistung. Verwenden Sie diese Sammlung nicht für die Verbindungszeichenfolgen, die von Ihren Funktionsbindungen verwendet werden. Diese Sammlung wird nur von Frameworks verwendet, die Verbindungszeichenfolgen üblicherweise aus dem Abschnitt ConnectionStrings einer Konfigurationsdatei abrufen, z. B. ConnectionStrings. Verbindungszeichenfolgen in diesem Objekt werden der Umgebung mit dem Anbietertyp System.Data.SqlClient hinzugefügt. Elemente in dieser Sammlung werden nicht mit anderen App-Einstellungen in Azure veröffentlicht. Sie müssen diese Werte explizit zur Sammlung Connection strings in den Einstellungen Ihrer Funktions-App hinzufügen. Bei der Erstellung einer SqlConnection-Klasse in Ihrem Funktionscode sollten Sie den Verbindungszeichenfolgenwert zusammen mit den anderen Verbindungen in den SqlConnection im Portal speichern.

Bei lokaler Ausführung können die folgenden Anwendungseinstellungen in das Array Values aufgenommen werden:

Einstellung Werte BESCHREIBUNG
AzureWebJobsStorage Verbindungszeichenfolge für das Speicherkonto oder
UseDevelopmentStorage=true		 Enthält die Verbindungszeichenfolge für ein Azure-Speicherkonto. Erforderlich, wenn andere Trigger als HTTP verwendet werden. Weitere Informationen finden Sie in der Referenz zu AzureWebJobsStorage.
Wenn der Azurite-Emulator lokal installiert ist und Sie AzureWebJobsStorage auf UseDevelopmentStorage=true festlegen, verwendet Core Tools den Emulator. Weitere Informationen finden Sie unter Emulator für lokalen Speicher.
AzureWebJobs.<FUNCTION_NAME>.Disabled true|false Wenn Sie bei lokaler Ausführung eine Funktion deaktivieren möchten, fügen Sie der Sammlung "AzureWebJobs.<FUNCTION_NAME>.Disabled": "true" hinzu, wobei <FUNCTION_NAME> der Name der Funktion ist. Weitere Informationen zum Deaktivieren von Funktionen in Azure Functions finden Sie hier.
FUNCTIONS_WORKER_RUNTIME dotnet
dotnet-isolated
node
java
powershell
python		 Gibt die Zielsprache der Functions-Runtime an. Erforderlich für Version 2.x und höher der Functions-Runtime. Diese Einstellung wird von Core Tools für Ihr Projekt generiert. Weitere Informationen finden Sie in der Referenz zu FUNCTIONS_WORKER_RUNTIME.
FUNCTIONS_WORKER_RUNTIME_VERSION ~7 Legt fest, dass PowerShell 7 beim lokalen Ausführen verwendet werden soll. Wird kein Wert festgelegt, wird PowerShell Core 6 verwendet. Diese Einstellung wird nur bei lokaler Ausführung verwendet. Bei der Ausführung in Azure wird die PowerShell-Runtimeversion durch die Einstellung der powerShellVersion-Sitekonfiguration bestimmt, die im Portal festgelegt werden kann.

Synchronisieren der Einstellungen

Wenn Sie Ihre Funktionen lokal entwickeln, müssen von Ihrer App benötigte lokale Einstellungen auch in App-Einstellungen der Funktions-App vorhanden sein, für die Ihr Code bereitgestellt wird. Möglicherweise müssen Sie auch aktuelle Einstellungen aus der Funktions-App in Ihr lokales Projekt herunterladen. Während Sie App-Einstellungen im Azure-Portal manuell konfigurieren können, können Sie mit den folgenden Tools auch App-Einstellungen mit lokalen Einstellungen in Ihrem Projekt synchronisieren:

Trigger und Bindungen

Wenn Sie Ihre Funktionen lokal entwickeln, müssen Sie das Trigger- und Bindungsverhalten berücksichtigen. Bei HTTP-Triggern können Sie einfach den HTTP-Endpunkt auf dem lokalen Computer aufrufen mittels http://localhost/. Für nicht HTTP ausgelöste Funktionen gibt es mehrere Optionen, die lokal ausgeführt werden können:

  • Die einfachste Möglichkeit zum Testen von Bindungen während der lokalen Entwicklung besteht darin, Verbindungszeichenfolgen zu verwenden, die auf Azure-Livedienste abzielen. Sie können Livedienste als Ziel verwenden, indem Sie die entsprechenden Verbindungszeichenfolgeneinstellungen im Values-Array in der Datei „local.settings.json“ hinzufügen. Wenn Sie so vorgehen, wirken sich lokale Ausführungen während des Tests auf Livedienstdaten aus. Erwägen Sie daher das Einrichten separater Dienste, die während der Entwicklung und für Tests verwendet werden sollen, und steigen Sie dann während der Produktion auf andere Dienste um.
  • Für speicherbasierte Trigger können Sie einen lokalen Speicheremulator verwenden.
  • Sie können Nicht-HTTP-Triggerfunktionen manuell ausführen, indem Sie spezielle Administratorendpunkte verwenden. Weitere Informationen finden Sie unter Manuelles Ausführen einer nicht HTTP ausgelösten Funktion.

Während der lokalen Tests müssen Sie den Host ausführen, der von Core Tools (func.exe) lokal bereitgestellt wird. Weitere Informationen finden Sie unter Azure Functions Core Tools.

Test Tools für HTTP

Während der Entwicklung ist es einfach, alle Funktionsendpunkte aus einem Webbrowser aufzurufen, wenn sie die HTTP GET-Methode unterstützen. Für andere HTTP-Methoden, die Nutzdaten wie POST oder PUT unterstützen, müssen Sie jedoch ein HTTP-Testtool verwenden, um diese HTTP-Anforderungen an Ihre Funktionsendpunkte zu erstellen und zu senden.

Achtung

Stellen Sie für Szenarien, in denen Ihre Anforderungen vertrauliche Daten enthalten müssen, sicher, dass Sie ein Tool verwenden, das Ihre Daten schützt. Das verringert das Risiko, vertrauliche Daten der Öffentlichkeit offenzulegen. Vertrauliche Daten, die Sie schützen sollten, können umfassen: Anmeldeinformationen, geheime Schlüssel, Zugriffstoken, API-Schlüssel, Geolocation-Daten, sogar personenbezogene Informationen (PII).

Sie können Ihre Daten schützen, indem Sie ein HTTP-Testtool auswählen, das offline oder lokal funktioniert, Ihre Daten nicht mit der Cloud synchronisiert und nicht erfordert, dass Sie sich bei einem Onlinekonto anmelden. Einige Tools können Ihre Daten auch vor versehentlicher Gefährdung schützen, indem bestimmte Sicherheitsfeatures implementiert werden.

Vermeiden Sie die Verwendung von Tools, die Ihren HTTP-Anforderungsverlauf (einschließlich vertraulicher Informationen) zentral speichern, keine bewährten Sicherheitsmethoden befolgen, oder nicht auf Datenschutzbedenken achten.

Erwägen Sie die Verwendung eines dieser Tools zum sicheren Senden von HTTP-Anforderungen an Ihre Funktionsendpunkte:

Lokaler Speicheremulator

Während der lokalen Entwicklung können Sie den lokalen Azurite-Emulator verwenden, um Funktionen mit Azure Storage-Bindungen (Queue Storage, Blob Storage und Table Storage) zu testen, ohne eine Verbindung mit Remotespeicherdiensten herstellen zu müssen. Azurite kann in Visual Studio Code und Visual Studio integriert und auch über die Eingabeaufforderung mithilfe von npm ausgeführt werden. Weitere Informationen finden Sie unter Verwenden des Azurite-Emulators für lokale Azure Storage-Entwicklung.

Die folgende Einstellung in der Values-Sammlung der Datei „local.settings.json“ weist den lokalen Functions-Host an, Azurite für die AzureWebJobsStorage-Standardverbindung zu verwenden:

"AzureWebJobsStorage": "UseDevelopmentStorage=true"

Wenn dieser Wert eingestellt ist, stellt jeder Azure Storage-Trigger oder jede Azure Storage-Bindung, der bzw. die AzureWebJobsStorage als Verbindung verwendet, bei lokaler Ausführung eine Verbindung mit Azurite her. Beachten Sie diese Überlegungen bei der Verwendung der Speicheremulation während der lokalen Ausführung:

  • Sie müssen Azurite installiert haben und ausführen.
  • Sie sollten vor der Veröffentlichung in Azure eine tatsächliche Speicherverbindung mit Azure-Diensten testen.
  • Wenn Sie Ihr Projekt veröffentlichen, veröffentlichen Sie die AzureWebJobsStorage-Einstellung nicht als UseDevelopmentStorage=true. In Azure muss die AzureWebJobsStorage-Einstellung immer die Verbindungszeichenfolge des von Ihrer Funktions-App verwendeten Speicherkontos sein. Weitere Informationen finden Sie unter AzureWebJobsStorage.

Nächste Schritte