Übersicht über die Runtimeversionen von Azure Functions

Azure Functions unterstützt derzeit drei Versionen des Laufzeithosts: 3.x, 2.x und 1.x. Alle drei Versionen werden für Produktionsszenarios unterstützt.

Wichtig

Version 1.x befindet sich im Wartungsmodus und unterstützt nur die Entwicklung im Azure-Portal, um Azure Stack Hub-Portal oder lokal auf Windows-Computern. Erweiterungen werden nur in höheren Versionen bereitgestellt.

In diesem Artikel werden einige Unterschiede zwischen den verschiedenen Versionen, das Erstellen der einzelnen Versionen und das Ändern von Versionen erläutert.

Languages

Ab Version 2.x verwendet die Runtime ein Modell für die Erweiterbarkeit von Sprachen, und alle Funktionen in einer Funktions-App müssen dieselbe Sprache aufweisen. Die Sprache der Funktionen in einer Funktions-App wird beim Erstellen der App ausgewählt und in der Einstellung FUNCTIONS_WORKER_RUNTIME beibehalten.

Die folgende Tabelle zeigt, welche Programmiersprachen derzeit in den einzelnen Runtimeversionen unterstützt werden.

Sprache 1.x 2.x 3.x
C#1 Allgemeine Verfügbarkeit (.NET Framework 4.8) Allgemeine Verfügbarkeit (.NET Core 2.12) Allgemeine Verfügbarkeit (.NET Core 3.1)
Allgemeine Verfügbarkeit (.NET 5.0)
JavaScript Allgemeine Verfügbarkeit (Node 6) Allgemeine Verfügbarkeit (Node 10 und 8) Allgemeine Verfügbarkeit (Node 14, 12 und 10)
F# Allgemeine Verfügbarkeit (.NET Framework 4.8) Allgemeine Verfügbarkeit (.NET Core 2.12) Allgemeine Verfügbarkeit (.NET Core 3.1)
Java Allgemeine Verfügbarkeit (Java 8) Allgemeine Verfügbarkeit (Java 11 und 8)
PowerShell Allgemeine Verfügbarkeit (PowerShell Core 6) Allgemeine Verfügbarkeit (PowerShell 7 und Core 6)
Python Allgemeine Verfügbarkeit (Python 3.7 und 3.6) Allgemeine Verfügbarkeit (Python 3.8, 3.7 und 3.6)
Vorschau (Python 3.9)
TypeScript Allgemeine Verfügbarkeit3 Allgemeine Verfügbarkeit3

1 Es ist eine experimentelle Version von Azure Functions verfügbar, mit der Sie die Vorschauversion von .NET 6.0 verwenden können. Weitere Informationen finden Sie auf der Seite zur frühen Vorschauversion von Azure Functions v4. 2 Apps mit .NET-Klassenbibliotheken für Runtimeversion 2.x werden im .NET Core 2.x-Kompatibilitätsmodus unter .NET Core 3.1 ausgeführt. Weitere Informationen finden Sie unter Überlegungen zu Functions v2.x.
3 Unterstützt durch Transpilierung in JavaScript

Weitere Informationen zu unterstützten Sprachversionen finden Sie im sprachspezifischen Artikel im Entwicklerhandbuch.
Informationen zu geplanten Änderungen an der Sprachunterstützung finden Sie unter Azure-Roadmap.

Ausführen auf einer spezifischen Version

Im Azure-Portal und durch die Azure CLI erstellte Funktions-Apps sind standardmäßig auf Version 3.x festgelegt. Diese Version kann bei Bedarf geändert werden. Für die Runtimeversion kann nur ein Downgrade in 1.x ausgeführt werden, wenn Sie Ihre Funktions-App erstellt, aber noch keine Funktionen hinzugefügt haben. Der Wechsel zwischen 2.x und 3.x ist auch bei Apps möglich, die bereits über Funktionen verfügen. Bevor Sie eine App mit vorhandenen Funktionen von 2.x nach 3.x verschieben, achten Sie auf Breaking Changes zwischen 2.x und 3.x.

Bevor Sie eine Änderung an der Hauptversion der Laufzeit vornehmen, sollten Sie zunächst Ihren vorhandenen Code testen, indem Sie ihn für eine andere Funktions-App bereitstellen, die mit der neuesten Hauptversion ausgeführt wird. Diese Tests helfen sicherzustellen, dass er nach dem Upgrade ordnungsgemäß ausgeführt wird.

Downgrades von v3.x auf v2.x werden nicht unterstützt. Wenn möglich, sollten Sie Ihre Apps immer mit der neuesten unterstützten Version der Functions-Laufzeit ausführen.

Ändern der Version von Apps in Azure

Welche Version der Functions-Runtime von veröffentlichten Apps in Azure verwendet wird, wird durch die FUNCTIONS_EXTENSION_VERSION-Anwendungseinstellung bestimmt. Für die Hauptversion der Runtime werden folgende Werte unterstützt:

Wert Runtimeziel
~3 3.x
~2 2.x
~1 1.x

Wichtig

Ändern Sie diese Einstellung mit Bedacht, da hierdurch unter Umständen weitere Änderungen an App-Einstellungen und Ihrem Funktionscode nötig werden.

Weitere Informationen finden Sie unter How to target Azure Functions runtime versions (Einstellung auf bestimmte Laufzeitversionen von Azure Functions).

Anheften an eine bestimmte Nebenversion

Zum Beheben von Problemen mit ihrer Funktions-App, die mit der neuesten Hauptversion ausgeführt wird, müssen Sie Ihre App an eine bestimmte Nebenversion anheften. Dies gibt Ihnen Zeit, Ihre App mit der neuesten Hauptversion ordnungsgemäß auszuführen. Die Art und Weise, wie Sie die App an eine Nebenversion anheften, unterscheidet sich zwischen Windows und Linux. Weitere Informationen finden Sie unter How to target Azure Functions runtime versions (Einstellung auf bestimmte Laufzeitversionen von Azure Functions).

Ältere Nebenversionen werden regelmäßig aus Functions entfernt. Aktuelle Informationen zu Azure Functions Releases (einschließlich der Entfernung bestimmter älterer Nebenversionen) finden Sie unter Azure App Service-Ankündigungen.

Anheften an Version ~2.0

.NET-Funktions-Apps, die mit Version 2.x (~2) ausgeführt werden, werden automatisch auf .NET Core 3.1 aktualisiert, eine langfristige Supportversion von .NET Core 3. Wenn Sie Ihre .NET-Funktionen mit .NET Core 3.1 ausführen, können Sie die neuesten Sicherheitsupdates und Produktverbesserungen nutzen.

Jede Funktions-App, die an ~2.0 angeheftet wird, kann weiterhin unter .NET Core 2.2 ausgeführt werden. Diese Version erhält keine Sicherheitsupdates und andere Updates mehr. Weitere Informationen finden Sie unter Überlegungen zu Functions v2.x.

Migrieren von 2.x zu 3.x

Die Azure Functions-Version 3.x bietet eine hohe Abwärtskompatibilität mit der Version 2.x. Bei vielen Apps sollte problemlos ein Upgrade auf die Version 3.x möglich sein, ohne Codeänderungen vornehmen zu müssen. Die Migration zur Version 3.x wird zwar empfohlen, trotzdem sollten ausführliche Tests durchgeführt werden, bevor die Hauptversion in Produktions-Apps geändert wird.

Breaking Changes zwischen 2.x und 3.x

In diesem Abschnitt werden die Änderungen erläutert, die vor einem App-Upgrade von 2.x auf 3.x beachtet werden müssen.

JavaScript

  • Über context.done oder Rückgabewerte zugewiesene Ausgabebindungen weisen nun das gleiche Verhalten auf wie die Einstellung in context.bindings.

  • Das Zeitgebertrigger-Objekt wird im camelCase-Format angegeben (nicht im PascalCase-Format).

  • Funktionen, die von Event Hub mit binärem Datentyp (dataType) ausgelöst werden, erhalten ein Array vom Typ binary (anstelle von string).

  • Auf die Nutzlast von HTTP-Anforderungen kann nicht mehr über context.bindingData.req zugegriffen werden. Der Zugriff darauf ist aber weiterhin als Eingabeparameter (context.req) und in context.bindings möglich.

  • Node.js 8 wird nicht mehr unterstützt und in Funktionen der Version 3.x nicht ausgeführt.

.NET Core

Der Hauptunterschied zwischen den Versionen bei der Ausführung von Funktionen der .NET-Klassenbibliothek ist die .NET Core-Laufzeit. Functions Version 2.x ist für die Ausführung unter .NET Core 2.2 vorgesehen, Version 3.x ist für die Ausführung mit .NET Core 3.1 konzipiert.

Hinweis

Aufgrund von Supportproblemen mit .NET Core 2.2 werden Funktions-Apps, die an Version 2 (~2) angeheftet sind, im Wesentlichen mit .NET Core 3.1 ausgeführt. Weitere Informationen finden Sie unter Functions v2.x-Kompatibilitätsmodus.

Migrieren von 1.x zu neueren Versionen

Eine vorhandene App, die für die Runtimeversion 1.x geschrieben wurde, kann zu einer neueren Version migriert werden. Die meisten erforderlichen Änderungen hängen mit der Sprachruntime zusammen – also beispielsweise C#-API-Änderungen zwischen .NET Framework 4.8 und .NET Core. Sie müssen auch sicherstellen, dass Ihr Code und Ihre Bibliotheken mit den ausgewählten Sprachruntimes kompatibel sind. Beachten Sie nicht zuletzt auch die unten genannten Änderungen an Triggern, Bindungen und Funktionen. Um ein optimales Migrationsergebnis zu erzielen, sollten Sie eine neue Funktions-App in einer neuen Version erstellen und Ihren vorhandenen Funktionscode der Version 1.x zur neuen App portieren.

Es besteht zwar die Möglichkeit eines direkten Upgrades durch manuelles Aktualisieren der App-Konfiguration, die Umstellung von 1.x auf eine höhere Version beinhaltet jedoch einige Breaking Changes. In C# ändert sich beispielsweise das Debuggingobjekt von TraceWriter in ILogger. Durch die Erstellung eines neuen Projekts mit der Version 3.x stehen die aktualisierten Funktionen auf der Grundlage der neuesten Vorlagen der Version 3.x zur Verfügung.

Änderungen bei Triggern und Bindungen nach der Version 1.x

Ab der Version 2.x müssen die Erweiterungen für bestimmte Trigger und Bindungen installiert werden, die von den Funktionen in Ihrer App verwendet werden. Die einzigen Ausnahmen sind HTTP- und Timertrigger, für die keine Erweiterung erforderlich ist. Weitere Informationen finden Sie unter Registrieren und Installieren von Bindungserweiterungen.

Zwischen den Versionen gibt es auch einige Änderungen an der Datei function.json sowie an Attributen der Funktion. Die Event Hub-Eigenschaft path beispielsweise lautet jetzt eventHubName. Links zur Dokumentation für die einzelnen Bindungen finden Sie in der Tabelle der vorhandenen Bindungen.

Änderungen bei Features und Funktionen nach der Version 1.x

Einige Features wurden nach der Version 1.x entfernt, aktualisiert oder ersetzt. In diesem Abschnitt werden die Änderungen nach der Version 1.x erläutert.

In Version 2.x wurden die folgenden Änderungen vorgenommen:

  • Schlüssel für aufrufende HTTP-Endpunkte werden immer verschlüsselt in Azure Blob Storage gespeichert. In Version 1.x wurden die Schlüssel standardmäßig in Azure File Storage gespeichert. Beim Durchführen eines Upgrades für eine App von Version 1.x auf Version 2.x werden vorhandene Geheimnisse, die sich in File Storage befinden, zurückgesetzt.

  • Version 2.x der Runtime umfasst keine integrierte Unterstützung für Webhookanbieter. Diese Änderung wurde vorgenommen, um die Leistung zu verbessern. Sie können weiterhin HTTP-Trigger als Endpunkte für Webhooks verwenden.

  • Die Hostkonfigurationsdatei (host.json) muss leer sein oder die Zeichenfolge "version": "2.0" enthalten.

  • Zur Verbesserung der Überwachung wurde das WebJobs-Dashboard im Portal, das die Einstellung AzureWebJobsDashboard verwendete, durch Azure Application Insights ersetzt – hierbei wird die Einstellung APPINSIGHTS_INSTRUMENTATIONKEY verwendet. Weitere Informationen finden Sie unter Überwachen von Azure Functions.

  • Alle Funktionen in einer Funktions-App müssen die gleiche Sprache verwenden. Wenn Sie eine Funktions-App erstellen, müssen Sie einen Runtimestapel für die App auswählen. Der Runtimestapel wird durch den FUNCTIONS_WORKER_RUNTIME-Wert in den Anwendungseinstellungen angegeben. Diese Anforderung wurde hinzugefügt, um den Speicherbedarf und die Startzeit zu verbessern. Bei der lokalen Entwicklung müssen Sie diese Einstellung auch in die Datei „local.settings.json“ einschließen.

  • Das Standardzeitlimit für Funktionen in einem App Service-Plan wurde zu 30 Minuten geändert. Sie können das Zeitlimit mit der functionTimeout-Einstellung in der host.json-Datei manuell wieder zu „unbegrenzt“ ändern.

  • HTTP-Parallelitätsdrosselungen sind standardmäßig für Verbrauchsplanfunktionen implementiert. Der Standardwert beträgt 100 gleichzeitige Anforderungen pro Instanz. Sie können diesen Wert in der maxConcurrentRequests-Einstellung in der host.json-Datei ändern.

  • Aufgrund der Einschränkungen von .NET Core wurde die Unterstützung für F#-Skriptfunktionen (FSX) entfernt. Kompilierte F#-Funktionen (FS) werden weiterhin unterstützt.

  • Das URL-Format von Event Grid-Triggerwebhooks wurde zu https://{app}/runtime/webhooks/{triggerName} geändert.

Lokal entwickelte Anwendungsversionen

Sie können folgende Aktualisierungen für Funktions-Apps vornehmen, um die Zielversionen lokal zu ändern.

Visual Studio-Runtimeversionen

In Visual Studio wählen Sie die Runtimeversion beim Erstellen eines Projekts aus. Azure Functions-Tools für Visual Studio unterstützen die drei Hauptversionen der Runtime. Beim Debuggen und Veröffentlichen wird die richtige Version verwendet, basierend auf den Projekteinstellungen. Die Versionseinstellungen sind in der .csproj-Datei in den folgenden Einstellungen definiert:

Version 3.x
<TargetFramework>netcoreapp3.1</TargetFramework>
<AzureFunctionsVersion>v3</AzureFunctionsVersion>

Hinweis

Für Azure Functions 3.x und .NET muss die Microsoft.NET.Sdk.Functions Erweiterung mindestens die Version 3.0.0 haben.

Version 2.x
<TargetFramework>netcoreapp2.1</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
Version 1.x
<TargetFramework>net472</TargetFramework>
<AzureFunctionsVersion>v1</AzureFunctionsVersion>
Aktualisieren von Apps der Version 2.x auf die Version 3.x in Visual Studio

Sie können eine bereits vorhandene, für die Version 2.x konzipierte Funktion öffnen und zu 3.x migrieren, indem Sie die Datei .csproj bearbeiten und die obigen Werte aktualisieren. Visual Studio verwaltet Runtimeversionen automatisch auf der Grundlage der Projektmetadaten. Sollten Sie allerdings bislang noch keine App der Version 3.x erstellt haben, kann es sein, dass Visual Studio auf Ihrem Computer noch nicht über die Vorlagen und die Runtime für die Version 3.x verfügt. In diesem Fall tritt ggf. ein Fehler wie der folgende auf: „Es ist keine Functions-Laufzeit verfügbar, die der im Projekt angegebenen Version entspricht.“ Führen Sie die Schritte zum Erstellen eines neuen Funktionsprojekts aus, um die neuesten Vorlagen und die Runtime abzurufen. Wenn Sie zum Auswahlbildschirm für die Version und die Vorlage gelangen, warten Sie, bis Visual Studio die neuesten Vorlagen abgerufen hat. Wenn die neuesten .NET Core 3-Vorlagen verfügbar sind und angezeigt werden, können Sie jedes beliebige Projekt ausführen und debuggen, das für Version 3.x konfiguriert wurde.

Wichtig

Funktionen der Version 3.x können nur in Visual Studio entwickelt werden, wenn Sie mindestens die Visual Studio Version 16.4 verwenden.

Visual Studio Code und Azure Functions Core Tools

Azure Functions Core Tools werden für die Entwicklung über die Befehlszeile und auch von der Azure Functions-Erweiterung für Visual Studio Code verwendet. Wenn Sie für die Version 3.x entwickeln möchten, müssen Sie die Core Tools-Version 3.x installieren. Bei der Entwicklung für die Version 2.x benötigen Sie die Core Tools-Version 2.x. Und so weiter. Weitere Informationen finden Sie unter Installieren der Azure Functions Core Tools.

Für die Visual Studio Code-Entwicklung müssen Sie möglicherweise auch die Benutzereinstellung für die azureFunctions.projectRuntime entsprechend der installierten Version der Tools aktualisieren. Diese Einstellung aktualisiert auch die Vorlagen und Sprachen, die während der Erstellung von Funktions-Apps verwendet werden. Wenn Sie Apps in ~3 erstellen möchten, müssen Sie die Benutzereinstellung azureFunctions.projectRuntime auf ~3aktualisieren.

Runtimeeinstellung der Azure Functions-Erweiterung

Maven- und Java-Apps

Sie können Java-Apps der Version 2.x zur Version 3.x migrieren, indem Sie die Version 3.x von Core Tools installieren, die für die lokale Ausführung benötigt wird. Nachdem Sie sich vergewissert haben, dass Ihre lokal ausgeführte App unter der Version 3.x ordnungsgemäß funktioniert, können Sie die Datei POM.xml der App aktualisieren, um die Einstellung FUNCTIONS_EXTENSION_VERSION in ~3 zu ändern, wie im folgenden Beispiel zu sehen:

<configuration>
    <resourceGroup>${functionResourceGroup}</resourceGroup>
    <appName>${functionAppName}</appName>
    <region>${functionAppRegion}</region>
    <appSettings>
        <property>
            <name>WEBSITE_RUN_FROM_PACKAGE</name>
            <value>1</value>
        </property>
        <property>
            <name>FUNCTIONS_EXTENSION_VERSION</name>
            <value>~3</value>
        </property>
    </appSettings>
</configuration>

Bindungen

Ab Version 2.x verwendet die Runtime ein neues Modell für die Erweiterbarkeit von Bindungen, das folgende Vorteile bietet:

  • Unterstützung für Bindungserweiterungen von Drittanbietern.

  • Entkoppeln von Runtime und Bindungen. Mit dieser Änderung können Bindungserweiterungen versioniert und unabhängig freigegeben werden. Sie können z.B. ein Upgrade auf eine Version einer Erweiterung durchführen, das auf einer neueren Version des zugrunde liegenden SDKs basiert.

  • Eine schlankere Ausführungsumgebung, in der nur die tatsächlich verwendeten Bindungen bekannt sind und von der Runtime geladen werden.

Mit Ausnahme von HTTP- und Timertriggern müssen alle Bindungen explizit zum Funktions-App-Projekt hinzugefügt oder im Portal registriert werden. Weitere Informationen finden Sie unter Registrieren von Bindungserweiterungen.

Die folgende Tabelle zeigt, welche Bindungen in den einzelnen Runtimeversionen unterstützt werden.

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
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.

Funktions-App-Timeoutdauer

Die Timeoutdauer einer Funktions-App wird durch die functionTimeout-Eigenschaft in der host.json-Projektdatei definiert. Die folgende Tabelle listet die Standard- und Maximalwerte in Minuten für beide Pläne und die unterschiedlichen Laufzeitversionen auf:

Planen Laufzeitversion Standard Maximum
Nutzung 1.x 5 10
Nutzung 2.x 5 10
Nutzung 3.x 5 10
Premium 1.x Unbegrenzt Unbegrenzt
Premium 2.x 30 Unbegrenzt
Premium 3.x 30 Unbegrenzt
App Service 1.x Unbegrenzt Unbegrenzt
App Service 2.x 30 Unbegrenzt
App Service 3.x 30 Unbegrenzt

Hinweis

Unabhängig von der Timeouteinstellung der Funktions-App stellen 230 Sekunden die längste Zeit dar, die einer über HTTP ausgelösten Funktion bis zur Reaktion auf eine Anfrage bleibt. Dies hat seinen Grund im Standard-Leerlauftimeout von Azure Load Balancer. Erwägen Sie für längere Verarbeitungszeiten die Verwendung des asynchronen Durable Functions-Musters oder stellen Sie die eigentliche Arbeit zurück, und geben Sie unmittelbar eine Antwort zurück.

Nächste Schritte

Weitere Informationen finden Sie in den folgenden Ressourcen: