Einstellen von Runtimeversionen von Azure Functions als Ziel

Eine Funktionen-App wird für eine bestimmte Version der Azure Functions-Runtime ausgeführt. Standardmäßig erstellen Sie Funktions-Apps in der neuesten 4.x-Version der Funktionslaufzeit. Ihre Funktions-Apps werden nur unterstützt, wenn sie in einer unterstützten Hauptversion ausgeführt werden. In diesem Artikel wird beschrieben, wie Sie eine Funktions-App in Azure so konfigurieren, dass sie auf eine bestimmte Version der Functions-Laufzeit ausgerichtet oder festgelegt wird, wenn erforderlich.

Überlegungen

Beachten Sie diese Überlegungen bei der Ausrichtung auf eine bestimmte Laufzeitversion:

Der Flex-Verbrauchsplan wird nur auf Version 4.x der Laufzeit ausgeführt. Da der Flex-Verbrauchsplan die FUNCTIONS_EXTENSION_VERSION App-Einstellung nicht unterstützt, kann Ihre App nicht auf eine bestimmte Laufzeitversion abzielen, wenn sie in diesem Plan ausgeführt wird.
Das Durchführen der Konfiguration für eine bestimmte Version hängt davon ab, ob Windows oder Linux ausgeführt wird.
Dieser Artikel ist spezifisch für Windows oder Linux. Wählen Sie am Anfang des Artikels Ihr Betriebssystem aus.
Wenn möglich, führen Sie Ihre App immer auf der neuesten unterstützten Laufzeitversion aus. Legen Sie Ihre App nur auf eine bestimmte Version fest, wenn Sie aufgrund eines Problems mit der neuesten Version dazu aufgefordert werden. Sie sollten immer zur neuesten Runtimeversion wechseln, sobald Ihre Funktionen ordnungsgemäß ausgeführt werden können.
Während der lokalen Entwicklung muss Ihre installierte Version von Azure Functions Core Tools mit der Hauptversion der Runtime übereinstimmen, die von der Funktions-App in Azure verwendet wird. Weitere Informationen finden Sie in der Core Tools-Versionen.

Aktualisieren der Runtimeversion

Wenn möglich, führen Sie Ihre Funktions-Apps immer auf der neuesten unterstützten Version der Azure Functions-Laufzeit aus. Wenn Ihre Funktions-App derzeit in einer älteren Version der Laufzeit ausgeführt wird, migrieren Sie Ihre App zu Version 4.x.

Wenn Ihre App über vorhandene Funktionen verfügt, müssen Sie Vorkehrungen treffen, bevor Sie zu einer höheren Runtime-Hauptversion wechseln. In den folgenden Artikeln werden Breaking Changes zwischen Hauptversionen ausführlich beschrieben, einschließlich sprachspezifischer Breaking Changes. Darüber hinaus erhalten Sie schrittweise Anleitungen für eine erfolgreiche Migration Ihrer vorhandenen Funktions-App.

Informationen zum Ermitteln der aktuellen Runtimeversion finden Sie unter Anzeigen der aktuellen Runtimeversion.

Anzeigen der aktuellen Runtimeversion

Sie können die aktuelle Runtimeversion Ihrer Funktions-App auf eine der folgenden Arten anzeigen:

Führen Sie die folgenden Schritte aus, um die derzeit von einer Funktions-App verwendete Runtimeversion anzuzeigen und zu aktualisieren:

Navigieren Sie im Azure-Portal zu Ihrer Funktions-App.
Erweitern Sie Einstellungen, und wählen Sie dann Konfiguration aus.
Notieren Sie sich auf der Registerkarte Functions-Laufzeiteinstellungen die Runtimeversion. In diesem Beispiel ist die Version auf ~4 festgelegt.

Sie können die FUNCTIONS_EXTENSION_VERSION-App-Einstellung über die Azure-Befehlszeilenschnittstelle anzeigen.

Sie zeigen die aktuelle Runtimeversion in der Azure-Befehlszeilenschnittstelle mit dem Befehl az functionapp config appsettings list an:

az functionapp config appsettings list --name <function_app> \
--resource-group <my_resource_group>

Ersetzen Sie in diesem Code <function_app> durch den Namen der Funktions-App. Ersetzen Sie außerdem <my_resource_group> durch den Namen der Ressourcengruppe für Ihre Funktions-App.

Die FUNCTIONS_EXTENSION_VERSION wird in der folgende Teilausgabe angezeigt:

[
  {
    "name": "FUNCTIONS_EXTENSION_VERSION",
    "slotSetting": false,
    "value": "~4"
  },
  {
    "name": "FUNCTIONS_WORKER_RUNTIME",
    "slotSetting": false,
    "value": "dotnet"
  },
  
  ...
]

Wählen Sie im vorherigen Codebeispiel "Cloud Shell öffnen " aus, um den Befehl in Azure Cloud Shell auszuführen. Sie können auch die Azure CLI lokal zum Ausführen dieses Befehls ausführen. Bei lokaler Ausführung müssen Sie zuerst az login ausführen, um sich anzumelden.

Verwenden Sie das folgende Cmdlet, um die Azure Functions-Runtime zu überprüfen:

Get-AzFunctionAppSetting -Name "<FUNCTION_APP>" -ResourceGroupName "<RESOURCE_GROUP>"

Ersetzen Sie <FUNCTION_APP> durch den Namen der Funktions-App und <RESOURCE_GROUP>. Der aktuelle Wert der Einstellung FUNCTIONS_EXTENSION_VERSION wird in der Hashtabelle zurückgegeben.

Anheften an eine bestimmte Version

Mit Azure Functions können Sie die FUNCTIONS_EXTENSION_VERSION-App-Einstellung verwenden, um eine bestimmte Runtimeversion als Ziel für eine bestimmte Funktions-App festzulegen. Wenn Sie nur die Hauptversion (~4) angeben, wird die Funktions-App automatisch auf neue Nebenversionen der Laufzeit aktualisiert, sobald sie verfügbar sind. Nebenversionsupdates sind automatisch, da neue Nebenversionen wahrscheinlich keine Änderungen einführen, die Ihre Funktionen unterbrechen.

Linux-Verwenden die Siteeinstellung linuxFxVersion zusammen mit FUNCTIONS_EXTENSION_VERSION, um das korrekte Linux-Basisimage zu bestimmen, in dem Ihre Funktionen ausgeführt werden sollen. Wenn Sie eine neue Funktions-App unter Linux erstellen, wählt die Runtime automatisch das richtige Basisimage basierend auf der Runtimeversion Ihres Sprachstapels aus.

Durch die Festlegung auf eine bestimmte Laufzeitversion wird die Funktions-App neu gestartet.

Wenn Sie eine bestimmte Nebenversion (z. B. 4.0.12345) in FUNCTIONS_EXTENSION_VERSION angeben, heften Sie die Funktions-App an diese bestimmte Version der Laufzeit, bis Sie sich ausdrücklich entscheiden, zu automatischen Versionsupdates zurückzukehren. Führen Sie die Festlegung auf eine bestimmte Nebenversion nur so lange durch, bis alle Probleme mit Ihrer Funktions-App behoben sind, die Sie daran hindern, auf die Hauptversion umzusteigen. Ältere Nebenversionen werden regelmäßig aus der Produktionsumgebung entfernt. Wenn Ihre Funktions-App auf eine Nebenversion festgelegt wird, die später entfernt wird, läuft Ihre Funktions-App auf der nächstgelegenen vorhandenen Version anstelle der in FUNCTIONS_EXTENSION_VERSION festgelegten Version. Ankündigungen des App-Diensts geben Nebenversionsentfernungen an.

Hinweis

Wenn Sie die Veröffentlichung über Visual Studio in einer App ausprobieren, die an eine bestimmte Nebenversion der Runtime angeheftet ist, werden Sie in einem Dialogfeld aufgefordert, auf die neueste Version zu aktualisieren oder die Veröffentlichung abzubrechen. Um diese Überprüfung zu vermeiden, wenn Sie eine bestimmte Nebenversion verwenden müssen, fügen Sie die Eigenschaft <DisableFunctionExtensionVersionUpdate>true</DisableFunctionExtensionVersionUpdate> in der Datei .csproj hinzu.

Verwenden Sie eine dieser Methoden, um Ihre App vorübergehend an eine bestimmte Version der Runtime anzuheften:

Führen Sie die folgenden Schritte aus, um die derzeit von einer Funktions-App verwendete Runtimeversion anzuzeigen und zu aktualisieren:

Navigieren Sie im Azure-Portal zu Ihrer Funktions-App.
Erweitern Sie Einstellungen, und wählen Sie dann Konfiguration aus.
Notieren Sie sich auf der Registerkarte Functions-Laufzeiteinstellungen die Runtimeversion. In diesem Beispiel ist die Version auf ~4 festgelegt.

Wenn Sie Ihre App an eine bestimmte Nebenversion anheften möchten, erweitern Sie im linken Bereich Einstellungen, und wählen Sie dann Umgebungsvariablen aus.
Wählen Sie auf der Registerkarte App-Einstellungen die Option FUNCTIONS_EXTENSION_VERSION aus, ändern Sie den Wert in Ihre gewünschte Nebenversion, und wählen Sie dann Übernehmen aus.
Wählen Sie Übernehmen und dann Bestätigen aus, um die Änderungen anzuwenden und die App neu zu starten.

Aktualisieren Sie die FUNCTIONS_EXTENSION_VERSION-App-Einstellung in der Funktions-App mit dem Befehl az functionapp config appsettings set.

az functionapp config appsettings set --name <FUNCTION_APP> \
--resource-group <RESOURCE_GROUP> \
--settings FUNCTIONS_EXTENSION_VERSION=<VERSION>

Verwenden Sie dieses Skript, um die Functions-Runtime anzuheften:

Update-AzFunctionAppSetting -Name "<FUNCTION_APP>" -ResourceGroupName "<RESOURCE_GROUP>" -AppSetting @{"FUNCTIONS_EXTENSION_VERSION" = "<VERSION>"} -Force

Ersetzen Sie <FUNCTION_APP> durch den Namen Ihrer Funktions-App und <RESOURCE_GROUP> durch den Namen der Ressourcengruppe für Ihre Funktions-App. Ersetzen Sie außerdem <VERSION> durch die spezifische Nebenversion, die Sie vorübergehend als Ziel festlegen müssen. Sie können den aktualisierten Wert der FUNCTIONS_EXTENSION_VERSION-Einstellung in der zurückgegebenen Hashtabelle überprüfen.

Die Funktions-App startet neu, nachdem die Änderung an der Anwendungseinstellung vorgenommen wurde.

Um Ihre Funktions-App an eine bestimmte Laufzeitversion unter Linux anzuheften, legen Sie eine versionsspezifische Basisimage-URL in der linuxFxVersion Websiteeinstellung im Format DOCKER|<PINNED_VERSION_IMAGE_URI>fest.

Wichtig

Angeheftete Funktions-Apps unter Linux erhalten keine regelmäßigen Updates für Sicherheits- und Hostfunktionalität. Sofern Sie keine anderweitigen Empfehlungen durch den Support erhalten haben, verwenden Sie die Einstellung FUNCTIONS_EXTENSION_VERSION und einen standardmäßigen linuxFxVersion-Wert für Sprache und Version, z. B. Python|3.12. Gültige Werte finden Sie im linuxFxVersion Referenzartikel.

Das Anheften an eine bestimmte Runtime für Linux-Funktions-Apps, die in einem Verbrauchsplan ausgeführt werden, derzeit nicht unterstützt.

Das folgende Beispiel zeigt den mit linuxFxVersion angegebenen Wert, der erforderlich ist, um eine Node.js 22-Function-App auf die spezifische Laufzeitversion 4.14.0.3 festzulegen:

DOCKER|mcr.microsoft.com/azure-functions/node:4.14.0.3-node22

Bei Bedarf kann eine Supportfachkraft Ihnen einen gültigen Basisimage-URI für Ihre Anwendung nennen.

Verwenden Sie die folgenden Azure CLI-Befehle, um die linuxFxVersion anzuzeigen und festzulegen. Sie können linuxFxVersion derzeit nicht im Portal oder mithilfe von Azure PowerShell festlegen:

Um die aktuelle Version der Runtime anzuzeigen, verwenden Sie den Befehl az functionapp config show:
```
az functionapp config show --name <function_app> \
--resource-group <my_resource_group> --query 'linuxFxVersion' -o tsv
```
Ersetzen Sie in diesem Code <function_app> durch den Namen der Funktions-App. Ersetzen Sie außerdem <my_resource_group> durch den Namen der Ressourcengruppe für Ihre Funktions-App. Der aktuelle Wert von linuxFxVersion wird zurückgegeben.
Um die Einstellung linuxFxVersion in der Funktions-App zu aktualisieren, verwenden Sie den Befehl az functionapp config set:
```
az functionapp config set --name <FUNCTION_APP> \
--resource-group <RESOURCE_GROUP> \
--linux-fx-version <LINUX_FX_VERSION>
```
Ersetzen Sie <FUNCTION_APP> durch den Namen der Funktions-App. Ersetzen Sie außerdem <RESOURCE_GROUP> durch den Namen der Ressourcengruppe für Ihre Funktions-App. Ersetzen Sie zum Schluss <LINUX_FX_VERSION> durch den Wert des Images, das Ihnen von einer Supportfachkraft genannt wurde.

Sie können diese Befehle über Azure Cloud Shell ausführen, indem Sie in den vorangehenden Codebeispielen Cloud Shell öffnen auswählen. Sie können auch die Azure-Befehlszeilenschnittstelle lokal zum Ausführen dieses Befehls verwenden, nachdem Sie sich mit az login angemeldet haben.

Die Funktions-App wird neu gestartet, nachdem die Änderung der Sitekonfiguration vorgenommen wurde.

Aktualisieren Sie das verwaltete Linux-Image

Dieser Abschnitt gilt nur für bestehende Python 3.11- und Java 8-, 11- oder 17-Apps auf Linux Elastic Premium oder dedizierten (App Service)-Plänen, die ein Debian Bullseye verwaltetes Image verwenden. Wenn Ihre App nicht alle diese Bedingungen erfüllt, müssen Sie dieses Verfahren nicht befolgen.

Das neuere verwaltete Image bietet einen temporären Pfad, damit eine betroffene App auf ihrer aktuellen Sprachversion bleibt, während sie auf eine unterstützte Linux-Distribution wechselt. Dieses Verfahren gilt nicht für Flex Consumption oder benutzerdefinierte Container-Apps. Für eine App im Linux-Consumption-Plan zum Flex Consumption-Plan migrieren.

Dieses Update wählt die Linux-Distribution für die bestehende Sprachversion aus, indem ein dreiteiliger linuxFxVersion Wert verwendet wird. Es heftet den Funktionshost nicht an ein bestimmtes DOCKER|<IMAGE_URI> Bild.

Wähle einen Wert für Bookworm oder Noble `linuxFxVersion`

Bestimmen Sie zunächst, ob Sie die Sprachversion aktualisieren können oder ob Sie die aktuelle Sprachversion behalten und eine neuere Linux-Distribution auswählen müssen.

Überlege, die App auf eine neuere unterstützte Sprachversion zu aktualisieren. Nach einem Sprachupdate verwendet die App das aktuelle Standard-Managed Image für diese Sprachversion.

Wenn die App auf ihrer aktuellen Sprachversion bleiben muss, wählen Sie den entsprechenden neueren Bildwert:

Sprachversion	Debian Bullseye-Wert	Neuere Distribution	Neuerer Bildwert
Python 3.11	`Python\\|3.11\\|2.0`	Debian Bookworm	`Python\\|3.11\\|3.0`
Java 8	`Java\\|8\\|2.0`	Ubuntu Noble	`Java\\|8\\|4.0`
Java 11	`Java\\|11\\|2.0`	Ubuntu Noble	`Java\\|11\\|4.0`
Java 17	`Java\\|17\\|2.0`	Ubuntu Noble	`Java\\|17\\|4.0`

Diese dreiteiligen Werte wählen explizit das verwaltete Linux-Image für diese Images aus der Bullseye-Ära aus. Sie werden nicht vom Befehl az functionapp list-runtimes zurückgegeben.

Teste das neuere verwaltete Linux-Image

Teste deine App und ihre Abhängigkeiten vom neueren Image, bevor du die Produktions-App aktualisierst.

Erstellen Sie eine separate Test-App oder erstellen Sie einen Deployment-Slot.
Stellen Sie denselben Code und dieselbe Konfiguration, die Ihre Produktions-App verwendet, für die Test-App oder den Slot bereit.
Setzen Sie den neueren Bildwert, indem Sie den Schritten in Aktualisieren des Bildwerts folgen. Wenn Sie einen Slot verwenden, fügen Sie --slot <SLOT_NAME> in jeden Azure CLI-Befehl ein.
Rufen Sie jede Funktion auf und überprüfen Sie, ob die App erfolgreich startet, die Triggers wie erwartet ausgeführt werden und native oder Betriebssystemabhängigkeiten korrekt geladen werden.

Aktualisieren Sie den Bildwert

Das Ändern des Bildwerts startet die Funktions-App neu. Aktualisieren Sie die Produktion während eines Wartungsfensters oder nutzen Sie einen Deployment-Slot.

Sehen Sie sich den aktuellen linuxFxVersion Wert an:
```
az functionapp config show --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query linuxFxVersion --output tsv
```
Dieser Befehl gibt den in der Site-Konfiguration gespeicherten Wert zurück. Der zurückgegebene Wert könnte nur die Sprache und die Sprachversion enthalten, zum Beispiel Python|3.11, anstatt den dreiteiligen Wert, der die Linux-Distribution identifiziert. Wenn der Wert die Image-Version nicht enthält, befolge die Schritte in Verify the Linux distribution , um zu bestätigen, dass die App derzeit Debian Bullseye verwendet.
Setzen Sie linuxFxVersion auf den neueren Image-Wert:
```
az functionapp config set --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --linux-fx-version "<LANGUAGE|VERSION|IMAGE_VERSION>"
```
Für Python 3.11 auf Debian Bookworm verwenden Sie Python|3.11|3.0. Für Java auf Ubuntu Noble verwenden Sie Java|8|4.0, Java|11|4.0 oder Java|17|4.0.
Warte, bis die App neu startet.

Verifizieren Sie die Linux-Distribution

Überprüfe sowohl den konfigurierten Wert als auch die Linux-Distribution, die deine App ausführt.

Bestätigen Sie den aktualisierten linuxFxVersion Wert:
```
az functionapp config show --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query linuxFxVersion --output tsv
```
Da du explizit einen dreiteiligen Wert gesetzt hast, gibt dieser Befehl genau den von dir gewählten Bookworm- oder Noble-Wert zurück.
Öffnen Sie die Kudu-Seite der App unter https://<APP_NAME>.scm.azurewebsites.net.
Wählen Sie Environment aus und überprüfen Sie KUDU_ENV, oder öffnen Sie eine SSH-Sitzung und führen Sie Folgendes aus:
```
cat /etc/os-release
```
Bestätigen Sie, dass die Ausgabe Debian Bookworm für Python 3.11 oder Ubuntu Noble für Java 8, 11 oder 17 identifiziert.
Rufen Sie jede Funktion auf und bestätigen Sie, dass Trigger und Abhängigkeiten weiterhin wie erwartet funktionieren.

Rollt das Managed Linux Image Update zurück

Wenn das aktualisierte Image ein Kompatibilitätsproblem verursacht, stelle den vorherigen linuxFxVersion Wert vorübergehend wieder her, während du das Problem behebest.

Warning

Debian Bullseye wird nach seinem End-of-Life-Datum nicht mehr unterstützt und erhält keine Sicherheitsupdates mehr. Verwenden Sie Rollback nur als temporäre Minderung und kehren Sie so schnell wie möglich zu einem unterstützten Image zurück.

Suchen Sie in der Tabelle unter Choose a Bookworm or Noble linuxFxVersion value den Wert für Debian Bullseye für Ihre Sprachversion.

Setzen Sie linuxFxVersion auf diesen Bullseye-Wert:

az functionapp config set --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --linux-fx-version "<BULLSEYE_LINUX_FX_VERSION>"

Warte, bis die App neu startet, und wiederhole dann die Kontrollen in Verify the Linux Distribution.

Nächste Schritte

Versionshinweise zu Laufzeitversionen

Feedback

War diese Seite hilfreich?

Last updated on 2026-09-17