Referenz zu App-Einstellungen für Azure Functions

Artikel
01/13/2024

App-Einstellungen in einer Funktions-App enthalten Konfigurationsoptionen, die sich auf deren Funktionen auswirken. Auf diese Einstellungen wird in Form von Umgebungsvariablen zugegriffen. In diesem Artikel werden die in Funktionen-Apps verfügbaren App-Einstellungen aufgelistet.

Es gibt mehrere Möglichkeiten zum Hinzufügen, Aktualisieren und Löschen von Funktionen-App-Einstellungen:

Zur Durchführung von Änderungen an den Funktions-App-Einstellungen muss Ihre Funktions-App neu gestartet werden.

In diesem Artikel werden Beispielwerte für Verbindungszeichenfolgen aus Gründen der Lesbarkeit abgeschnitten.

Überlegungen zu App-Einstellungen

Wenn Sie App-Einstellungen verwenden, sollten Sie die folgenden Überlegungen beachten:

Zur Durchführung von Änderungen an den Funktions-App-Einstellungen muss Ihre Funktions-App neu gestartet werden.
In Einstellungsnamen sind der doppelte Unterstrich (__) und das Semikolon (:) reservierte Werte. Doppelte Unterstriche werden sowohl unter Windows als auch unter Linux als hierarchische Trennzeichen interpretiert, wohingegen das Semikolon nur unter Linux auf die gleiche Weise interpretiert wird. Die Einstellung „AzureFunctionsWebHost__hostid=somehost_123456“ würde beispielsweise als das folgende JSON-Objekt interpretiert:
```
"AzureFunctionsWebHost": {
    "hostid": "somehost_123456"
}
```
In diesem Artikel werden nur doppelte Unterstriche verwendet, da sie von beiden Betriebssystemen unterstützt werden. Die meisten der Einstellungen, welche Verbindungen mit verwalteter Identität unterstützen, verwenden doppelte Unterstriche.
Wenn Functions lokal ausgeführt wird, werden App-Einstellungen in der Sammlung „Values“ in local.settings.json angegeben.
Es gibt weitere Konfigurationsoptionen für Funktions-Apps in der Datei host.json und in der Datei local.settings.json.
Sie können Anwendungseinstellungen verwenden, um host.json-Einstellungswerte zu überschreiben, ohne die Datei „host.json“ ändern zu müssen. Dies ist hilfreich für Szenarien, in denen bestimmte host.json-Einstellungen für eine bestimmte Umgebung konfiguriert oder geändert werden müssen. So können Sie auch host.json-Einstellungen ändern, ohne das Projekt erneut veröffentlichen zu müssen. Weitere Informationen finden Sie im Referenzartikel zu „host.json“.
In diesem Artikel werden die Einstellungen beschrieben, die für Ihre Funktions-Apps die größte Relevanz haben. Da Azure Functions unter App Service ausgeführt wird, werden auch andere App-Einstellungen unterstützt. Weitere Informationen finden Sie unter Umgebungsvariablen und App-Einstellungen in Azure App Service.
In einigen Szenarien müssen Sie auch mit Einstellungen arbeiten, die in den App Service Websiteeinstellungen dokumentiert sind.
Eine Änderung schreibgeschützterApp Service-Anwendungseinstellungen kann dazu führen, dass Ihre Funktions-App nicht mehr reagiert.
Beachten Sie dies beim Aktualisieren von Anwendungseinstellungen mithilfe von REST-APIs, einschließlich ARM-Vorlagen. Da diese APIs die vorhandenen Anwendungseinstellungen ersetzen, müssen Sie alle vorhandenen Einstellungen einschließen, wenn Sie Einstellungen mithilfe von REST-APIs oder ARM-Vorlagen hinzufügen oder ändern. Verwenden Sie nach Möglichkeit Azure CLI oder Azure PowerShell, um programmgesteuert mit Anwendungseinstellungen zu arbeiten. Weitere Informationen finden Sie unter Verwenden von Anwendungseinstellungen.

APPINSIGHTS_INSTRUMENTATIONKEY

Der Instrumentierungsschlüssel für Application Insights. Sie sollten weder APPINSIGHTS_INSTRUMENTATIONKEY noch APPLICATIONINSIGHTS_CONNECTION_STRING verwenden. Verwenden Sie nach Möglichkeit APPLICATIONINSIGHTS_CONNECTION_STRING. Wenn Application Insights in einer Sovereign Cloud ausgeführt wird, verwenden Sie APPLICATIONINSIGHTS_CONNECTION_STRING. Weitere Informationen finden Sie unter Konfigurieren der Überwachung für Azure Functions.

Schlüssel	Beispielwert
APPINSIGHTS_INSTRUMENTATIONKEY	`55555555-af77-484b-9032-64f83bb83bb`

Sie sollten weder APPINSIGHTS_INSTRUMENTATIONKEY noch APPLICATIONINSIGHTS_CONNECTION_STRING verwenden. Die Verwendung von APPLICATIONINSIGHTS_CONNECTION_STRING wird empfohlen.

Hinweis

Am 31. März 2025 wird der Support für die auf Instrumentierungsschlüsseln basierende Erfassung eingestellt. Die Erfassung von Instrumentierungsschlüsseln funktioniert zwar weiterhin, wir stellen jedoch keine Updates und keinen Support mehr für das Feature bereit. Wechseln Sie zu Verbindungszeichenfolgen, damit Sie neue Funktionen nutzen können.

APPLICATIONINSIGHTS_CONNECTION_STRING

Die Verbindungszeichenfolge für Application Insights. Sie sollten weder APPINSIGHTS_INSTRUMENTATIONKEY noch APPLICATIONINSIGHTS_CONNECTION_STRING verwenden. Die Verwendung von APPLICATIONINSIGHTS_CONNECTION_STRING wird in allen Fällen empfohlen wird. In folgenden Fällen ist sie aber sogar zwingend:

Für Ihre Funktions-App sind die zusätzlichen Anpassungen erforderlich, die bei Verwendung der Verbindungszeichenfolge unterstützt werden.
Ihre Application Insights-Instanz wird in einer Sovereign Cloud ausgeführt, für die ein benutzerdefinierter Endpunkt erforderlich ist.

Weitere Informationen finden Sie unter Verbindungszeichenfolgen.

Schlüssel	Beispielwert
APPLICATIONINSIGHTS_CONNECTION_STRING	`InstrumentationKey=...`

AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL

Wichtig

Azure Functions-Proxys sind ein Legacyfeature für die Versionen 1.x bis 3.x der Azure Functions-Runtime. Weitere Informationen zum Legacy-Support in Version 4.x finden Sie unter Functions-Proxys.

Standardmäßig nutzen Functions-Proxys eine Verknüpfung, um API-Aufrufe von Proxys direkt an Funktionen in der gleichen Functions-App zu senden. Die Verknüpfung wird anstelle einer neuen HTTP-Anforderung verwendet. Diese Einstellung ermöglicht das Deaktivieren dieses Verknüpfungsverhaltens.

Schlüssel	Wert	Beschreibung
AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL	`true`	Aufrufe mit einer Back-End-URL, die auf eine Funktion in der lokalen Funktions-App verweist, werden nicht direkt an die Funktion gesendet. Stattdessen werden die Anforderungen wieder an das HTTP-Front-End für die Funktions-App zurückgeleitet.
AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL	`false`	Aufrufe mit einer Back-End-URL, die auf eine Funktion in der lokalen Funktions-App verweist, werden direkt an die Funktion weitergeleitet. Der Standardwert lautet `false`.

AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES

Wichtig

Azure Functions-Proxys sind ein Legacyfeature für die Versionen 1.x bis 3.x der Azure Functions-Runtime. Weitere Informationen zum Legacy-Support in Version 4.x finden Sie unter Functions-Proxys.

Diese Einstellung steuert, ob die Zeichen „%2F“ in Routenparametern als Schrägstrich decodiert werden, wenn sie in die Back-End-URL eingefügt werden.

Schlüssel	Wert	Beschreibung
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES	`true`	Routenparameter mit codierten Schrägstrichen werden decodiert.
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES	`false`	Alle Routenparameter werden unverändert weitergegeben (Standardverhalten).

Sehen Sie sich beispielsweise die Datei „proxies.json“ für eine Funktions-App in der Domäne myfunction.com an.

{
    "$schema": "http://json.schemastore.org/proxies",
    "proxies": {
        "root": {
            "matchCondition": {
                "route": "/{*all}"
            },
            "backendUri": "example.com/{all}"
        }
    }
}

Wenn AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES auf true festgelegt ist, wird die URL example.com/api%2ftest in example.com/api/test aufgelöst. Standardmäßig bleibt die URL unverändert (example.com/test%2fapi). Weitere Informationen finden Sie unter Verwenden von Azure-Funktionsproxys.

AZURE_FUNCTIONS_ENVIRONMENT

Konfiguriert die Runtime-Hostingumgebung der Funktions-App, wenn sie in Azure ausgeführt wird. Dieser Wert wird während der Initialisierung gelesen, und nur diese Werte werden von der Runtime berücksichtigt:

Wert	Beschreibung
`Production`	Stellt eine Produktionsumgebung mit reduzierter Protokollierung und vollständigen Leistungsoptimierungen dar. Dies ist der Standardwert, wenn `AZURE_FUNCTIONS_ENVIRONMENT` entweder nicht oder auf einen nicht unterstützten Wert festgelegt ist.
`Staging`	Stellt eine Stagingumgebung dar, z. B. wenn sie in einem Stagingslot ausgeführt wird.
`Development`	Eine Entwicklungsumgebung unterstützt ausführlichere Protokollierung und andere reduzierte Leistungsoptimierungen. Die Azure Functions Core Tools legen `AZURE_FUNCTIONS_ENVIRONMENT` auf `Development` fest, wenn sie auf Ihrem lokalen Computer ausgeführt werden. Diese Einstellung kann in der Datei local.settings.json nicht überschrieben werden.

Verwenden Sie diese Einstellung anstelle von ASPNETCORE_ENVIRONMENT, wenn Sie die Runtimeumgebung in Azure in einen anderen Wert als Production ändern müssen. Weitere Informationen finden Sie unter Umgebungsbasierte Startklasse und -methoden.

Diese Einstellung ist in Version 1.x der Functions-Runtime nicht verfügbar.

AzureFunctionsJobHost__*

In Version 2.x und höheren Versionen der Functions-Runtime können Anwendungseinstellungen Einstellungen in host.json in der aktuellen Umgebung außer Kraft setzen. Diese Außerkraftsetzungen werden als Anwendungseinstellungen namens AzureFunctionsJobHost__path__to__setting ausgedrückt. Weitere Informationen finden Sie unter Außerkraftsetzung der Werte in der Datei „host.json“.

AzureFunctionsWebHost__hostid

Legt die Host-ID für eine bestimmte Funktions-App fest, die eine eindeutige ID sein sollte. Diese Einstellung überschreibt den automatisch generierten Host-ID-Wert für Ihre App. Verwenden Sie diese Einstellung nur, wenn Sie Host-ID-Konflikte zwischen Funktions-Apps verhindern müssen, die das gleiche Speicherkonto gemeinsam verwenden.

Eine Host-ID muss die folgenden Anforderungen erfüllen:

Sie muss zwischen 1 und 32 Zeichen lang sein.
Es sind nur Kleinbuchstaben, Zahlen und Bindestriche zulässig.
Sie darf nicht mit einem Bindestrich beginnen oder enden.
Sie darf keine aufeinander folgenden Bindestriche enthalten.

Eine einfache Möglichkeit, eine ID zu generieren, besteht darin, eine GUID zu verwenden, die Bindestriche zu entfernen und sie in Kleinbuchstaben umzuwandeln, z. B. indem die GUID 1835D7B5-5C98-4790-815D-072CC94C6F71 in den Wert 1835d7b55c984790815d072cc94c6f71 konvertiert wird.

Schlüssel	Beispielwert
AzureFunctionsWebHost__hostid	`myuniquefunctionappname123456789`

Weitere Informationen finden Sie unter Überlegungen zur Host-ID.

AzureWebJobsDashboard

Diese Einstellung ist veraltet und wird nur unterstützt, wenn sie auf Version 1.x der Azure Functions-Runtime ausgeführt wird.

Optionale Verbindungszeichenfolge für das Speicherkonto zum Speichern von Protokollen und zu deren Anzeige auf der Registerkarte Überwachen im Portal. Das Speicherkonto muss ein allgemeines Konto sein, das BLOBs, Warteschlangen und Tabellen unterstützt. Weitere Informationen finden Sie unter Speicherkontoanforderungen.

Schlüssel	Beispielwert
AzureWebJobsDashboard	`DefaultEndpointsProtocol=https;AccountName=...`

AzureWebJobsDisableHomepage

Ein Wert von „true“ bedeutet, dass die standardmäßige Landing Page deaktiviert wird, die für die Stamm-URL einer Funktions-App angezeigt wird. Der Standardwert ist false.

Schlüssel	Beispielwert
AzureWebJobsDisableHomepage	`true`

Wenn diese App-Einstellung ausgelassen oder auf false gesetzt wird, erfolgt als Reaktion auf die URL <functionappname>.azurewebsites.net die Anzeige einer Seite, die dem folgenden Beispiel ähnelt.

Landing Page der Funktionen-App

AzureWebJobsDotNetReleaseCompilation

true bedeutet, dass beim Kompilieren von .NET-Code der Releasemodus verwendet wird, während false bedeutet, dass der Debugmodus verwendet wird. Der Standardwert ist true.

Schlüssel	Beispielwert
AzureWebJobsDotNetReleaseCompilation	`true`

AzureWebJobsFeatureFlags

Eine durch Trennzeichen getrennte Liste der zu aktivierenden Features der Betaversion. Durch diese Flags aktivierte Features der Betaversion sind nicht bereit für die Produktion, können aber zur experimentellen Verwendung aktiviert werden, bevor sie live geschaltet werden.

Schlüssel	Beispielwert
AzureWebJobsFeatureFlags	`feature1,feature2,EnableProxies`

Fügen Sie EnableProxies dieser Liste hinzu, um Proxys in der Functions-Runtime-Version 4.x erneut zu aktivieren, während Sie Ihre Migration zu Azure API Management planen. Weitere Informationen finden Sie unter Erneutes Aktivieren von Proxys in Functions v4.x.

AzureWebJobsKubernetesSecretName

Gibt die Kubernetes-Geheimnisressource an, die zum Speichern von Schlüsseln verwendet wird. Wird nur bei Ausführung in Kubernetes unterstützt. Diese Einstellung erfordert, dass Sie „AzureWebJobsSecretStorageType“ auf festlegen „kubernetes“. Wenn AzureWebJobsKubernetesSecretName nicht festgelegt ist, wird das Repository als schreibgeschützt betrachtet. In diesem Fall müssen die Werte vor der Bereitstellung generiert werden. Die Azure Functions Core Tools generieren die Werte automatisch bei Bereitstellung in Kubernetes.

Schlüssel	Beispielwert
AzureWebJobsKubernetesSecretName	`<SECRETS_RESOURCE>`

Weitere Informationen finden Sie unter Geheimnisrepositorys.

AzureWebJobsSecretStorageKeyVaultClientId

Die Client-ID der vom Benutzer zugewiesenen verwalteten Identität oder die App-Registrierung, die für den Zugriff auf den Tresor verwendet wird, in dem Schlüssel gespeichert werden. Diese Einstellung erfordert, dass Sie „AzureWebJobsSecretStorageType“ auf festlegen „keyvault“. Wird in Version 4.x und höher der Functions-Runtime unterstützt.

Schlüssel	Beispielwert
AzureWebJobsSecretStorageKeyVaultClientId	`<CLIENT_ID>`

Weitere Informationen finden Sie unter Geheimnisrepositorys.

AzureWebJobsSecretStorageKeyVaultClientSecret

Das Geheimnis für die Client-ID der vom Benutzer zugewiesenen verwalteten Identität oder die App-Registrierung, die für den Zugriff auf den Tresor verwendet wird, in dem Schlüssel gespeichert werden. Diese Einstellung erfordert, dass Sie „AzureWebJobsSecretStorageType“ auf festlegen „keyvault“. Wird in Version 4.x und höher der Functions-Runtime unterstützt.

Schlüssel	Beispielwert
AzureWebJobsSecretStorageKeyVaultClientSecret	`<CLIENT_SECRET>`

Weitere Informationen finden Sie unter Geheimnisrepositorys.

AzureWebJobsSecretStorageKeyVaultName

Der Name einer Schlüsseltresorinstanz, die zum Speichern von Schlüsseln verwendet wird. Diese Einstellung wird nur für Version 3.x der Functions-Runtime unterstützt. Verwenden Sie für Version 4.x stattdessen AzureWebJobsSecretStorageKeyVaultUri. Diese Einstellung erfordert, dass Sie „AzureWebJobsSecretStorageType“ auf festlegen „keyvault“.

Der Tresor muss über eine Zugriffsrichtlinie verfügen, die der systemseitig zugewiesenen verwalteten Identität der Hostingressource entspricht. Die Zugriffsrichtlinie sollte der Identität die folgenden Geheimnisberechtigungen gewähren: Get, Set, List und Delete.
Bei lokaler Ausführung Ihrer Funktionen wird die Entwickleridentität verwendet, und Einstellungen müssen sich in der local.settings.json-Datei befinden.

Schlüssel	Beispielwert
AzureWebJobsSecretStorageKeyVaultName	`<VAULT_NAME>`

Weitere Informationen finden Sie unter Geheimnisrepositorys.

AzureWebJobsSecretStorageKeyVaultTenantId

Die Mandanten-ID der App-Registrierung, die für den Zugriff auf den Tresor verwendet wird, in dem Schlüssel gespeichert werden. Diese Einstellung erfordert, dass Sie „AzureWebJobsSecretStorageType“ auf festlegen „keyvault“. Wird in Version 4.x und höher der Functions-Runtime unterstützt. Weitere Informationen finden Sie unter Geheimnisrepositorys.

Schlüssel	Beispielwert
AzureWebJobsSecretStorageKeyVaultTenantId	`<TENANT_ID>`

AzureWebJobsSecretStorageKeyVaultUri

Der Name einer Schlüsseltresorinstanz, die zum Speichern von Schlüsseln verwendet wird. Wird in Version 4.x und höher der Functions-Runtime unterstützt. Dies ist die empfohlene Einstellung für die Verwendung einer Schlüsseltresorinstanz für die Schlüsselspeicherung. Diese Einstellung erfordert, dass Sie „AzureWebJobsSecretStorageType“ auf festlegen „keyvault“.

Der AzureWebJobsSecretStorageKeyVaultUri-Wert sollte der vollständige Wert des Tresor-URI sein, der auf der Registerkarte Key Vault-Übersicht angezeigt wird, einschließlich https://.

Schlüssel	Beispielwert
AzureWebJobsSecretStorageKeyVaultUri	`https://<VAULT_NAME>.vault.azure.net`

Weitere Informationen finden Sie unter Verwenden von Key Vault-Verweisen für Azure Functions.

AzureWebJobsSecretStorageSas

Ein Blob Storage SAS-URL für ein zweites Speicherkonto, das für die Schlüsselspeicherung verwendet wird. Standardmäßig verwendet Functions das in AzureWebJobsStorage festgelegte Konto. Wenn Sie diese Geheimnisspeicheroption verwenden, stellen Sie sicher, dass AzureWebJobsSecretStorageType nicht explizit oder auf blob festgelegt ist. Weitere Informationen finden Sie unter Geheimnisrepositorys.

Schlüssel	Beispielwert
AzureWebJobsSecretStorageSas	`<BLOB_SAS_URL>`

AzureWebJobsSecretStorageType

Gibt das Repository oder den Anbieter an, das bzw. der zum Speichern von Schlüsseln verwendet wird. Schlüssel werden vor der Speicherung immer mit einem Geheimnis verschlüsselt, das für Ihre Funktions-App eindeutig ist.

Schlüssel	Wert	BESCHREIBUNG
AzureWebJobsSecretStorageType	`blob`	Schlüssel werden in einem Blob Storage-Container in dem Konto gespeichert, das von der `AzureWebJobsStorage`-Einstellung bereitgestellt wird. Blob Storage ist das Standardverhalten, wenn „`AzureWebJobsSecretStorageType`“ nicht festgelegt ist. Um ein anderes Speicherkonto anzugeben, verwenden Sie die `AzureWebJobsSecretStorageSas`-Einstellung, um die SAS-URL eines zweiten Speicherkontos anzugeben.
AzureWebJobsSecretStorageType	`files`	Schlüssel werden im Dateisystem persistent gespeichert. Dies ist das Standardverhalten für Functions v1.x.
AzureWebJobsSecretStorageType	`keyvault`	Schlüssel werden in einer Schlüsseltresorinstanz gespeichert, die von `AzureWebJobsSecretStorageKeyVaultName` festgelegt wird.
AzureWebJobsSecretStorageType	`kubernetes`	Nur unterstützt, wenn die Functions-Laufzeit in Kubernetes ausgeführt wird. Wenn `AzureWebJobsKubernetesSecretName` nicht festgelegt ist, wird das Repository als schreibgeschützt betrachtet. In diesem Fall müssen die Werte vor der Bereitstellung generiert werden. Die Azure Functions Core Tools generieren die Werte automatisch bei Bereitstellung in Kubernetes.

Weitere Informationen finden Sie unter Geheimnisrepositorys.

AzureWebJobsStorage

Gibt die Verbindungszeichenfolge für ein Azure Storage-Konto an, das von der Functions-Runtime für normale Vorgänge verwendet wird. Einige Verwendungsmöglichkeiten für dieses Speicherkonto durch Functions umfassen Schlüsselverwaltung, Verwaltung der Selbstauslösertrigger und Event Hubs-Prüfpunkte. Das Speicherkonto muss ein allgemeines Konto sein, das BLOBs, Warteschlangen und Tabellen unterstützt. Weitere Informationen finden Sie unter Anforderungen an das Speicherkonto.

Schlüssel	Beispielwert
AzureWebJobsStorage	`DefaultEndpointsProtocol=https;AccountName=...`

Anstelle einer Verbindungszeichenfolge können Sie eine identitätsbasierte Verbindung für dieses Speicherkonto verwenden. Weitere Informationen finden Sie unter Verbinden mit dem Hostspeicher mit einer Identität.

AzureWebJobsStorage__accountName

Wenn Sie eine identitätsbasierte Speicherverbindung verwenden, wird der Kontoname des Speicherkontos festgelegt, anstatt die Verbindungszeichenfolge in AzureWebJobsStorage zu verwenden. Diese Syntax ist für AzureWebJobsStorage eindeutig und kann nicht für andere identitätsbasierte Verbindungen verwendet werden.

Schlüssel	Beispielwert
AzureWebJobsStorage__accountName	`<STORAGE_ACCOUNT_NAME>`

Für Sovereign Clouds oder bei Verwendung eines benutzerdefinierten DNS müssen Sie stattdessen die dienstspezifischen AzureWebJobsStorage__*ServiceUri-Einstellungen verwenden.

AzureWebJobsStorage__blobServiceUri

Wenn Sie eine identitätsbasierte Speicherverbindung verwenden, wird der Datenebene-URI des BLOB-Diensts des Speicherkontos festgelegt.

Schlüssel	Beispielwert
AzureWebJobsStorage__blobServiceUri	`https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net`

Verwenden Sie diese Einstellung anstelle von AzureWebJobsStorage__accountName in Sovereign Clouds oder bei Verwendung eines benutzerdefinierten DNS. Weitere Informationen finden Sie unter Verbinden mit dem Hostspeicher mit einer Identität.

AzureWebJobsStorage__queueServiceUri

Bei Verwendung einer identitätsbasierten Speicherverbindung wird der Datenebene-URI des Warteschlangendiensts des Speicherkontos festgelegt.

Schlüssel	Beispielwert
AzureWebJobsStorage__queueServiceUri	`https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net`

AzureWebJobsStorage__tableServiceUri

Bei Verwendung einer identitätsbasierten Speicherverbindung wird der Datenebene-URI eines Tabellendiensts des Speicherkontos festgelegt.

Schlüssel	Beispielwert
AzureWebJobsStorage__tableServiceUri	`https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net`

AzureWebJobs_TypeScriptPath

Der Pfad zum Compiler, der für TypeScript verwendet wird. Bei Bedarf können Sie den Standardwert außer Kraft setzen.

Schlüssel	Beispielwert
AzureWebJobs_TypeScriptPath	`%HOME%\typescript`

DOCKER_REGISTRY_SERVER_PASSWORD

Gibt das Kennwort an, das für den Zugriff auf eine private Containerregistrierung verwendet wird. Diese Einstellung ist nur erforderlich, wenn Sie Ihre containerisierte Funktions-App aus einer privaten Containerregistrierung bereitstellen. Weitere Informationen finden Sie unter Umgebungsvariablen und App-Einstellungen in Azure App Service.

DOCKER_REGISTRY_SERVER_URL

Gibt die URL einer privaten Containerregistrierung an. Diese Einstellung ist nur erforderlich, wenn Sie Ihre containerisierte Funktions-App aus einer privaten Containerregistrierung bereitstellen. Weitere Informationen finden Sie unter Umgebungsvariablen und App-Einstellungen in Azure App Service.

DOCKER_REGISTRY_SERVER_USERNAME

Gibt das Konto an, das für den Zugriff auf eine private Containerregistrierung verwendet wird. Diese Einstellung ist nur erforderlich, wenn Sie Ihre containerisierte Funktions-App aus einer privaten Containerregistrierung bereitstellen. Weitere Informationen finden Sie unter Umgebungsvariablen und App-Einstellungen in Azure App Service.

DOCKER_SHM_SIZE

Legt die Größe des gemeinsam genutzten Speichers (in Bytes) fest, wenn der Python-Worker gemeinsam genutzten Speicher verwendet. Weitere Informationen finden Sie unter Gemeinsam genutzter Speicher.

Schlüssel	Beispielwert
DOCKER_SHM_SIZE	`268435456`

Der obige Wert legt eine gemeinsam genutzte Speichergröße von ~256 MB fest.

Erfordert, dass FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED auf 1 festgelegt ist.

ENABLE_ORYX_BUILD

Gibt an, ob das Oryx-Buildsystem während der Bereitstellung verwendet wird. „ENABLE_ORYX_BUILD“ muss auf „true“ festgelegt werden, wenn Remotebuildbereitstellungen unter Linux ausgeführt werden. Weitere Informationen finden Sie unter Remotebuild.

Schlüssel	Beispielwert
ENABLE_ORYX_BUILD	`true`

FUNCTION_APP_EDIT_MODE

Gibt an, ob Sie Ihre Funktions-App im Azure-Portal bearbeiten können. Gültige Werte sind readwrite und readonly.

Schlüssel	Beispielwert
FUNCTION_APP_EDIT_MODE	`readonly`

Der Wert wird von der Runtime basierend auf dem Sprachstapel und dem Bereitstellungsstatus Ihrer Funktions-App festgelegt. Weitere Informationen finden Sie unter Entwicklungseinschränkungen im Azure-Portal.

FUNCTIONS_EXTENSION_VERSION

Die Version der Functions-Runtime, die ihre Funktions-App hostet. Eine Tilde (~) mit Hauptversion bedeutet, dass die neueste Version dieser Hauptversion verwendet werden soll (z. B. „~3“). Wenn neue Versionen für dieselbe Hauptversion verfügbar sind, werden sie automatisch in der Funktions-App installiert. Verwenden Sie die vollständige Versionsnummer (z. B. „3.0.12345“), um die App an eine bestimmte Version anzuheften. Der Standardwert ist ~3. Der Wert ~1 heftet Ihre App an Version 1.x der Runtime an. Weitere Informationen finden Sie unter Einstellen von Runtimeversionen von Azure Functions als Ziel. Der Wert ~4 bedeutet, dass Ihre App mit Version 4.x der Runtime ausgeführt wird.

Schlüssel	Beispielwert
FUNCTIONS_EXTENSION_VERSION	`~4`

Für die Hauptversion der Runtime werden folgende Werte unterstützt:

Wert	Runtimeziel	Kommentar
`~4`	4.x	Empfohlen
`~3`	3.x	Nicht mehr unterstützt
`~2`	2.x	Nicht mehr unterstützt
`~1`	1.x	Support endet am 14. September 2026

FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR

Diese App-Einstellung ist eine temporäre Möglichkeit für Node.js Apps, einen Breaking Change zu ermöglichen, der die Problembehandlung von Einstiegspunktfehlern auf Node.js v18 oder tiefer erleichtert. Es wird dringend empfohlen, true zu verwenden, insbesondere für Apps des Programmiermodells v4, die immer Einstiegspunktdateien verwenden. Das Verhalten ohne den Breaking Change (false) ignoriert Einstiegspunktfehler und protokolliert sie nicht in Application Insights.

Ab Node.js v20 hat die App-Einstellung keine Auswirkung, und das Verhalten für den Breaking Change ist immer aktiviert.

Für Node.js v18 oder tiefer kann die App-Einstellung verwendet werden, und das Standardverhalten hängt davon ab, ob der Fehler vor oder nach der Registrierung einer Modell v4-Funktion auftritt:

Wenn der Fehler vorher ausgelöst wird (z. B. wenn Sie Modell v3 verwenden oder ihre Einstiegspunktdatei nicht vorhanden ist), entspricht das Standardverhalten false.
Wenn der Fehler nachher ausgelöst wird (z. B. wenn Sie versuchen, doppelte Modell v4-Funktionen zu registrieren), entspricht das Standardverhalten true.

Schlüssel	Wert	Beschreibung
FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR	`true`	Blockieren Sie bei Einstiegspunktfehlern, und protokollieren Sie diese in Application Insights.
FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR	`false`	Ignorieren Sie Einstiegspunktfehler, und protokollieren Sie diese nicht in Application Insights.

FUNCTIONS_V2_COMPATIBILITY_MODE

Wichtig

Diese Einstellung wird nicht mehr unterstützt. Sie wurde ursprünglich bereitgestellt, um eine kurzfristige Problemumgehung für Apps zu ermöglichen, die auf die v2.x-Runtime ausgerichtet waren, damit sie stattdessen auf der v3.x-Runtime ausgeführt werden konnten, während diese noch unterstützt wurde. Mit Ausnahme von Legacy-Apps, die auf Version 1.x ausgeführt werden, müssen alle Funktions-Apps auf Version 4.x der Functions-Runtime ausgeführt werden: FUNCTIONS_EXTENSION_VERSION=~4. Weitere Informationen finden Sie unter Einstellen von Runtimeversionen von Azure Functions als Ziel.

FUNCTIONS_REQUEST_BODY_SIZE_LIMIT

Überschreibt den Standardgrenzwert für die Textgröße von Anforderungen, die an HTTP-Endpunkte gesendet werden. Der Wert wird in Bytes angegeben, wobei die maximale Anforderungsgröße standardmäßig 104857600 Bytes beträgt.

Schlüssel	Beispielwert
FUNCTIONS_REQUEST_BODY_SIZE_LIMIT	`250000000`

FUNCTIONS_WORKER_PROCESS_COUNT

Gibt die maximale Anzahl von Sprachworkerprozessen mit einem Standardwert von 1 an. Der zulässige Höchstwert ist 10. Funktionsaufrufe werden gleichmäßig zwischen Sprachworkerprozessen verteilt. Workerprozesse für Sprache werden alle 10 Sekunden bis zum Erreichen der von FUNCTIONS_WORKER_PROCESS_COUNT festgelegten Anzahl erzeugt. Die Verwendung mehrerer Sprachworkerprozesse ist nicht dasselbe wie Skalierung. Erwägen Sie die Verwendung dieser Einstellung, wenn Ihr Workload aus einer Mischung von CPU-gebundenen und E/A-gebundenen Aufrufen besteht. Diese Einstellung gilt für alle Sprachlaufzeiten, mit Ausnahme von .NET bei Ausführung im Prozess (FUNCTIONS_WORKER_RUNTIME=dotnet).

Schlüssel	Beispielwert
FUNCTIONS_WORKER_PROCESS_COUNT	`2`

FUNCTIONS_WORKER_RUNTIME

Die Sprache oder der Sprachstapel der Workerruntime, die in der Funktions-App geladen werden soll. Dies entspricht der Sprache, die in der Anwendung verwendet wird (z. B. python). Ab Version 2.x der Azure Functions-Runtime kann eine bestimmte Funktions-App nur eine einzige Sprache unterstützen.

Schlüssel	Beispielwert
FUNCTIONS_WORKER_RUNTIME	`node`

Gültige Werte:

Wert	Sprache/Sprachstapel
`dotnet`	C# (Klassenbibliothek) C# (Skript)
`dotnet-isolated`	C# (isolierter Workerprozess)
`java`	Java
`node`	JavaScript TypeScript
`powershell`	PowerShell
`python`	Python
`custom`	Andere

FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED

Diese Einstellung ermöglicht es dem Python-Worker, gemeinsam genutzten Speicher zu verwenden, um den Durchsatz zu verbessern. Aktivieren Sie gemeinsam genutzten Speicher, wenn Ihre Python-Funktions-App auf Speicherengpässe trifft.

Schlüssel	Beispielwert
FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED	`1`

Wenn diese Einstellung aktiviert ist, können Sie die Einstellung DOCKER_SHM_SIZE verwenden, um die Größe des gemeinsam genutzten Speichers festzulegen. Weitere Informationen finden Sie unter Gemeinsam genutzter Speicher.

JAVA_OPTS

Wird verwendet, um den virtuellen Java-Computer (Java Virtual Machine, JVM) anzupassen, mit dem Ihre Java-Funktionen ausgeführt werden, wenn sie mithilfe eines Premium- oder Dedicated-Plans ausgeführt werden. Wenn Sie mithilfe eines Verbrauchsplan ausgeführt werden, verwenden Sie stattdessen „languageWorkers__java__arguments“. Weitere Informationen finden Sie unter Anpassen der JVM.

languageWorkersjavaarguments

Wird verwendet, um den virtuellen Java-Computer (Java Virtual Machine, JVM) anzupassen, mit dem Ihre Java-Funktionen ausgeführt werden, wenn sie mithilfe eines Verbrauchsplan ausgeführt werden. Diese Einstellung erhöht die Kaltstartzeiten für Java-Funktionen, die in einem Verbrauchsplan ausgeführt werden. Verwenden Sie für einen Premium- oder Dedicated-Plan stattdessen „JAVA_OPTS“. Weitere Informationen finden Sie unter Anpassen der JVM.

MDMaxBackgroundUpgradePeriod

Steuert den Zeitraum für Hintergrundupdates von verwalteten Abhängigkeiten für PowerShell-Funktions-Apps. Der Standardwert ist 7.00:00:00 (wöchentlich).

Jeder PowerShell-Workerprozess löst die Überprüfung auf Modulupgrades im PowerShell-Katalog beim Start des Prozesses und alle MDMaxBackgroundUpgradePeriod danach aus. Wenn im PowerShell-Katalog eine neue Modulversion verfügbar ist, wird sie im Dateisystem installiert und PowerShell-Workern zur Verfügung gestellt. Wenn Sie diesen Wert verringern, erhält Ihre Funktions-App schneller eine neuere Modulversion. Dies steigert aber auch den App-Ressourceneinsatz (Netzwerk-E/A, CPU, Speicher). Wenn Sie diesen Wert erhöhen, wird der App-Ressourceneinsatz verringert, aber möglicherweise auch die Bereitstellung neuer Modulversionen für Ihre App verzögert.

Schlüssel	Beispielwert
MDMaxBackgroundUpgradePeriod	`7.00:00:00`

Weitere Informationen finden Sie unter Abhängigkeitsverwaltung.

MDNewSnapshotCheckPeriod

Gibt an, wie oft jeder PowerShell-Worker überprüft, ob Upgrades verwalteter Abhängigkeiten installiert wurden. Die Standardhäufigkeit ist 01:00:00 (stündlich).

Nach der Installation neuer Modulversionen im Dateisystem müssen alle PowerShell-Workerprozesse neu gestartet werden. Das Neustarten von PowerShell-Workern wirkt sich auf die Verfügbarkeit der App aus, da dadurch die Ausführung der aktuellen Funktion unterbrochen werden kann. Bis zum Abschluss des Neustarts aller PowerShell-Workerprozesse können Funktionsaufrufe entweder die alte oder neue Modulversion verwenden. Alle PowerShell-Worker werden innerhalb von MDNewSnapshotCheckPeriod neu gestartet.

In jeder MDNewSnapshotCheckPeriod überprüft der PowerShell-Worker, ob Upgrades verwalteter Abhängigkeiten installiert wurden. Falls Upgrades installiert wurden, wird ein Neustart initiiert. Das Erhöhen dieses Wert verringert die Häufigkeit von Unterbrechungen durch Neustarts. Die Erhöhung kann jedoch auch die Zeit verlängern, in der Funktionsaufrufe nicht deterministisch entweder die alte oder die neue Modulversion verwenden können.

Schlüssel	Beispielwert
MDNewSnapshotCheckPeriod	`01:00:00`

Weitere Informationen finden Sie unter Abhängigkeitsverwaltung.

MDMinBackgroundUpgradePeriod

Zeitraum nach einer vorherigen Upgradeüberprüfung verwalteter Abhängigkeiten, bevor eine weitere Upgradeüberprüfung gestartet wird. Der Standardwert ist 1.00:00:00 (täglich).

Um übermäßige Modulupgrades bei häufigen Workerneustarts zu vermeiden, wird die Überprüfung auf Modulupgrades nicht durchgeführt, wenn ein Worker diese Prüfung bereits innerhalb der letzten MDMinBackgroundUpgradePeriod ausgelöst hat.

Schlüssel	Beispielwert
MDMinBackgroundUpgradePeriod	`1.00:00:00`

Weitere Informationen finden Sie unter Abhängigkeitsverwaltung.

PIP_INDEX_URL

Mit dieser Einstellung können Sie die Basis-URL des Python-Paketindex außer Kraft setzen, die standardmäßig https://pypi.org/simple lautet. Verwenden Sie diese Einstellung, wenn Sie einen Remotebuild mit benutzerdefinierten Abhängigkeiten ausführen müssen. Diese benutzerdefinierten Abhängigkeiten können sich in einem Paketindexrepository befinden, das PEP 503-konform (der einfachen Repository-API) ist, oder in einem lokalen Verzeichnis, das dasselbe Format einhält.

Schlüssel	Beispielwert
PIP_INDEX_URL	`http://my.custom.package.repo/simple`

Weitere Informationen finden Sie in der pip-Dokumentation für --index-url und unter Benutzerdefinierte Abhängigkeiten in der Python-Entwicklerreferenz.

PIP_EXTRA_INDEX_URL

Der Wert für diese Einstellung zeigt eine zusätzliche Index-URL für benutzerdefinierte Pakete für Python-Apps an, die zusätzlich zu --index-url verwendet werden soll. Verwenden Sie diese Einstellung, wenn Sie einen Remotebuild mit benutzerdefinierten Abhängigkeiten ausführen müssen, die sich in einem zusätzlichen Paketindex befinden. Es sollte dieselben Regeln wie „--index-url“ einhalten.

Schlüssel	Beispielwert
PIP_EXTRA_INDEX_URL	`http://my.custom.package.repo/simple`

Weitere Informationen finden Sie in der pip-Dokumentation für --extra-index-url und in der Python-Entwicklerreferenz unter Benutzerdefinierte Abhängigkeiten.

PROJEKT

Eine Einstellung für die kontinuierliche Bereitstellung, die dem Kudu-Bereitstellungsdienst den Ordner in einem verbundenen Repository angibt, um das bereitstellungsfähige Projekt zu speichern.

Schlüssel	Beispielwert
PROJEKT	`WebProject/WebProject.csproj`

PYTHON_ISOLATE_WORKER_DEPENDENCIES

Die Konfiguration ist spezifisch für Python-Funktions-Apps. Sie definiert die Priorisierung der Modulladereihenfolge. Standardmäßig ist dieser Wert auf 0 festgelegt.

Key	Wert	Beschreibung
PYTHON_ISOLATE_WORKER_DEPENDENCIES	`0`	Priorisiert das Laden der Python-Bibliotheken aus den Abhängigkeiten interner Python-Worker. Dies ist das Standardverhalten. Für Bibliotheken von Drittanbietern, die in „requirements.txt“ definiert sind, kann ggf. Shadowing durchgeführt werden.
PYTHON_ISOLATE_WORKER_DEPENDENCIES	`1`	Priorisiert das Laden der Python-Bibliotheken aus dem in „requirements.txt“ definierten Paket der Anwendung. Dadurch wird verhindert, dass Ihre Bibliotheken mit den Bibliotheken des internen Python-Workers kollidieren.

PYTHON_ENABLE_DEBUG_LOGGING

Aktiviert Protokollierung auf Debugebene in einer Python-Funktions-App. Der Wert 1 aktiviert Protokollierung auf Debugebene. Ohne diese Einstellung oder bei einem Wert von 0 werden nur Informationen und Protokolle auf höherer Ebene vom Python-Worker an den Functions-Host gesendet. Verwenden Sie diese Einstellung, wenn Sie Ihre Python-Funktionsausführungen debuggen oder deren Ablauf verfolgen.

Stellen Sie beim Debuggen von Python-Funktionen sicher, dass Sie bei Bedarf auch einen Protokolliergrad für Debuggen oder Ablaufverfolgung in der Datei „host.json“ festlegen. Weitere Informationen finden Sie unter Konfigurieren der Überwachung für Azure Functions.

PYTHON_ENABLE_WORKER_EXTENSIONS

Die Konfiguration ist spezifisch für Python-Funktions-Apps. Wenn diese Einstellung auf 1 festgelegt wird, kann der Worker 1 laden, die in „requirements.txt“ definiert sind. Sie ermöglicht Ihrer Funktions-App den Zugriff auf neue Features, die von Paketen von Drittanbietern bereitgestellt werden. Sie kann auch das Verhalten des Ladens und Aufrufs von Funktionen in Ihrer App ändern. Stellen Sie sicher, dass die von Ihnen ausgewählte Erweiterung vertrauenswürdig ist, da Sie das Risiko für die Verwendung tragen. Azure Functions gewährt keine ausdrücklichen Gewährleistungen für Erweiterungen. Informationen zur Verwendung einer Erweiterung finden Sie auf der jeweiligen Manpage oder in der Infodatei zur Erweiterung. Standardmäßig wird dieser Wert auf „0“ festgelegt.

Schlüssel	Wert	Beschreibung
PYTHON_ENABLE_WORKER_EXTENSIONS	`0`	Deaktiviert alle Python-Workererweiterungen.
PYTHON_ENABLE_WORKER_EXTENSIONS	`1`	Erlaubt dem Python-Worker das Laden von Erweiterungen aus „requirements.txt“.

PYTHON_THREADPOOL_THREAD_COUNT

Gibt die maximale Anzahl von Threads an, die von einem Python-Sprachworker zum Ausführen von Funktionsaufrufen verwendet werden. Der Standardwert lautet 1 für die Python-Version 3.8 und niedriger. Für die Python-Version 3.9 und höher ist der Wert auf None festgelegt. Diese Einstellung garantiert nicht die Anzahl von Threads, die bei Ausführungen festgelegt werden würden. Diese Einstellung ermöglicht es Python, die Anzahl von Threads auf den angegebenen Wert zu erhöhen. Die Einstellung gilt nur für Python-Funktions-Apps. Darüber hinaus gilt die Einstellung für synchrone Funktionsaufrufe und nicht für Coroutinen.

Schlüssel	Beispielwert	Maximalwert
PYTHON_THREADPOOL_THREAD_COUNT	2	32

SCALE_CONTROLLER_LOGGING_ENABLED

Diese Einstellung befindet sich derzeit in der Vorschauphase.

Diese Einstellung dient zum Steuern der Protokollierung über den Azure Functions-Skalierungscontroller. Weitere Informationen finden Sie unter Skalierungscontrollerprotokolle (Vorschau).

Schlüssel	Beispielwert
SCALE_CONTROLLER_LOGGING_ENABLED	`AppInsights:Verbose`

Der Wert für diesen Schlüssel wird im Format <DESTINATION>:<VERBOSITY> bereitgestellt, das wie folgt definiert ist:

Eigenschaft Beschreibung

<DESTINATION> Das Ziel, an das Protokolle gesendet werden. Gültige Werte sind AppInsights und Blob.
Wenn Sie AppInsights verwenden, vergewissern Sie sich, dass Application Insights in der Funktions-App aktiviert ist.
Wenn Sie das Ziel auf Blob festgelegt haben, werden Protokolle in einem Blobcontainer mit dem Namen azure-functions-scale-controller in dem Standardspeicherkonto erstellt, das in der Anwendungseinstellung AzureWebJobsStorage festgelegt ist.

<VERBOSITY> Gibt die Protokollierungsstufe an. Unterstützte Werte sind None, Warning und Verbose.
Wenn diese Einstellung auf Verbose festgelegt ist, protokolliert der Skalierungscontroller einen Grund für jede Änderung an der Workeranzahl sowie Informationen zu den Triggern, die diese Entscheidungen beeinflussen. Ausführliche Protokolle enthalten Triggerwarnungen und die Hashes, die von den Triggern vor und nach dem Ausführen des Skalierungscontrollers verwendet werden.

Eigenschaft	Beschreibung
`<DESTINATION>`	Das Ziel, an das Protokolle gesendet werden. Gültige Werte sind `AppInsights` und `Blob`. Wenn Sie `AppInsights` verwenden, vergewissern Sie sich, dass Application Insights in der Funktions-App aktiviert ist. Wenn Sie das Ziel auf `Blob` festgelegt haben, werden Protokolle in einem Blobcontainer mit dem Namen `azure-functions-scale-controller` in dem Standardspeicherkonto erstellt, das in der Anwendungseinstellung `AzureWebJobsStorage` festgelegt ist.
`<VERBOSITY>`	Gibt die Protokollierungsstufe an. Unterstützte Werte sind `None`, `Warning` und `Verbose`. Wenn diese Einstellung auf `Verbose` festgelegt ist, protokolliert der Skalierungscontroller einen Grund für jede Änderung an der Workeranzahl sowie Informationen zu den Triggern, die diese Entscheidungen beeinflussen. Ausführliche Protokolle enthalten Triggerwarnungen und die Hashes, die von den Triggern vor und nach dem Ausführen des Skalierungscontrollers verwendet werden.

Tipp

Beachten Sie, dass es Auswirkungen auf die potenziellen Kosten für die Überwachung Ihrer Funktions-App haben kann, wenn die Protokollierung des Skalierungscontrollers weiterhin aktiviert ist. Erwägen Sie, die Protokollierung zu aktivieren, bis Sie genügend Daten gesammelt haben, um das Verhalten des Skalierungscontrollers nachzuvollziehen, und deaktivieren Sie sie dann.

SCM_DO_BUILD_DURING_DEPLOYMENT

Steuert das Remotebuildverhalten während der Bereitstellung. Wenn „SCM_DO_BUILD_DURING_DEPLOYMENT“ auf „true“ festgelegt ist, wird das Projekt während der Bereitstellung remote erstellt.

Schlüssel	Beispielwert
SCM_DO_BUILD_DURING_DEPLOYMENT	`true`

SCM_LOGSTREAM_TIMEOUT

Steuert das Timeout in Sekunden, wenn eine Verbindung mit Streamingprotokollen vorhanden ist. Der Standardwert beträgt 7.200 Sekunden (2 Stunden).

Schlüssel	Beispielwert
SCM_LOGSTREAM_TIMEOUT	`1800`

Der Beispielwert von 1800 oben legt ein Timeout von 30 Minuten fest. Weitere Informationen finden Sie unter Aktivieren des Streamings von Ausführungsprotokollen in Azure Functions.

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

Die Verbindungszeichenfolge für das Speicherkonto, in dem der Code der Funktions-App und die Konfiguration in ereignisgesteuerten Skalierungsplänen gespeichert werden. Weitere Informationen finden Sie unter Speicherkonto-Verbindungseinstellung.

Schlüssel	Beispielwert
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING	`DefaultEndpointsProtocol=https;AccountName=...`

Diese Einstellung ist für Apps im Verbrauchs- und Elastic Premium-Plan erforderlich, die sowohl unter Windows als auch unter Linux ausgeführt werden. Sie ist nicht für Apps des dedizierten Plans erforderlich, die von Functions nicht dynamisch skaliert werden.

Das Ändern oder Entfernen dieser Einstellung kann dazu führen, dass Ihre Funktions-App nicht gestartet wird. Weitere Informationen finden Sie in diesem Artikel zur Problembehandlung.

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.

WEBSITE_CONTENTOVERVNET

Der Wert 1 ermöglicht die Skalierung Ihrer Funktions-App, wenn Sie Ihr Speicherkonto auf ein virtuelles Netzwerk beschränken. Sie sollten diese Einstellung aktivieren, wenn Sie Ihr Speicherkonto auf ein virtuelles Netzwerk einschränken. Nur erforderlich, wenn WEBSITE_CONTENTAZUREFILECONNECTIONSTRING verwendet wird. Weitere Informationen finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.

Schlüssel	Beispielwert
WEBSITE_CONTENTOVERVNET	`1`

Wird mit den Plänen Premium und Dediziert (App Service) (Standard oder höher) unterstützt. Wird nicht unterstützt, wenn es auf einem Verbrauchsplan ausgeführt wird.

WEBSITE_CONTENTSHARE

Der Name der Dateifreigabe, die Functions zum Speichern von Funktions-App-Code und Konfigurationsdateien verwendet. Dieser Inhalt wird von ereignisgesteuerten Skalierungsplänen benötigt. Wird mit WEBSITE_CONTENTAZUREFILECONNECTIONSTRING verwendet. Der Standard ist eine eindeutige, von der Runtime generierte Zeichenfolge, die mit dem Namen der Funktions-App beginnt. Weitere Informationen finden Sie unter Speicherkonto-Verbindungseinstellung.

Schlüssel	Beispielwert
WEBSITE_CONTENTSHARE	`functionapp091999e2`

Diese Einstellung ist für Apps des Verbrauchs- und Premium-Plans sowohl unter Windows als auch unter Linux erforderlich. Sie ist nicht für Apps des dedizierten Plans erforderlich, die von Functions nicht dynamisch skaliert werden.

Die Freigabe wird erstellt, wenn Ihre Funktions-App erstellt wird. Das Ändern oder Entfernen dieser Einstellung kann dazu führen, dass Ihre Funktions-App nicht gestartet wird. Weitere Informationen finden Sie in diesem Artikel zur Problembehandlung.

Die folgenden Überlegungen gelten für die Verwendung einer Azure Resource Manager (ARM)-Vorlage oder einer Bicep-Datei zum Erstellen einer Funktions-App während der Bereitstellung:

Wenn Sie keinen WEBSITE_CONTENTSHARE-Wert für die Hauptfunktions-App oder Apps in Slots festlegen, werden eindeutige Freigabewerte für Sie generiert. WEBSITE_CONTENTSHARE nicht festzulegen ist der empfohlene Ansatz für eine ARM-Vorlagenbereitstellung.
Es gibt Szenarien, in denen Sie den WEBSITE_CONTENTSHARE-Wert auf einen vordefinierten Wert festlegen müssen, z. B. wenn Sie ein gesichertes Speicherkonto in einem virtuellen Netzwerk verwenden. In diesem Fall müssen Sie einen eindeutigen Freigabenamen für die Hauptfunktions-App und die App für jeden Bereitstellungsslot festlegen. Im Falle eines speicherbasierten Kontos, das durch ein virtuelles Netzwerk gesichert ist, müssen Sie auch die Freigabe selbst als Teil Ihrer automatisierten Bereitstellung erstellen. Weitere Informationen finden Sie unter Gesicherte Bereitstellungen.
WEBSITE_CONTENTSHARE darf keine Sloteinstellung sein.
Wenn Sie WEBSITE_CONTENTSHARE angeben, muss der Wert diese Anleitung für Freigabenamen befolgen.

WEBSITE_DNS_SERVER

Legt den von einer App verwendeten DNS-Server beim Auflösen von IP-Adressen fest. Diese Einstellung ist häufig erforderlich, wenn bestimmte Netzwerkfunktionen wie private Zonen von Azure DNS und private Endpunkte verwendet werden.

Schlüssel	Beispielwert
WEBSITE_DNS_SERVER	`168.63.129.16`

WEBSITE_ENABLE_BROTLI_ENCODING

Steuert, ob Brotli-Codierung für die Komprimierung anstelle der GZIP-Standardkomprimierung verwendet wird. Wenn WEBSITE_ENABLE_BROTLI_ENCODING auf 1 festgelegt ist, wird Brotli-Codierung verwendet, andernfalls wird GZIP-Codierung verwendet.

WEBSITE_FUNCTIONS_ARMCACHE_ENABLED

Deaktiviert das Zwischenspeichern bei der Bereitstellung von Funktions-Apps mithilfe von Azure Resource Manager (ARM)-Vorlagen.

Schlüssel	Beispielwert
WEBSITE_FUNCTIONS_ARMCACHE_ENABLED	0

WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT

Die maximale Anzahl der Instanzen, auf denen die App aufskaliert werden kann. Dieser Wert ist standardmäßig unbegrenzt.

Wichtig

Diese Einstellung befindet sich in der Vorschauphase. Eine App-Eigenschaft für das maximale Aufskalieren einer Funktion wurde hinzugefügt und ist die empfohlene Methode zum Begrenzen des Aufskalierens.

Schlüssel	Beispielwert
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT	`5`

WEBSITE_NODE_DEFAULT_VERSION

Nur Windows Legt die Version von Node.js fest, die beim Ausführen Ihrer Funktions-App unter Windows verwendet werden soll. Verwenden Sie eine Tilde (~), damit die Laufzeit die neueste verfügbare Version der Zielhauptversion verwendet. Wird dieser Wert beispielsweise auf „~18“ festtgelegt, wird die neueste Version von Node.js 18 verwendet. Wenn eine Hauptversion mittels Tilde vorgegeben wird, müssen Sie die Nebenversion nicht manuell aktualisieren.

Schlüssel	Beispielwert
WEBSITE_NODE_DEFAULT_VERSION	`~18`

WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS

Beim Austauschen von Slots in einer Funktions-App, die in einem Premium-Plan ausgeführt wird, kann es passieren, dass der Austausch nicht erfolgreich ist, wenn das dedizierte Speicherkonto, das von der App verwendet wird, Netzwerkeinschränkungen unterliegt. Dieser Fehler wird durch ein älteres Anwendungsprotokollierungsfeature verursacht, das sowohl von Functions als auch von App Service genutzt wird. Diese Einstellung überschreibt das Protokollierungsfeature der Vorgängerversion und ermöglicht den Austausch.

Schlüssel	Beispielwert
WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS	`0`

Fügen Sie allen Slots WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS mit dem Wert 0 hinzu, um sicherzustellen, dass Ihre Austauschvorgänge nicht durch Legacydiagnoseeinstellungen blockiert werden. Sie haben auch die Möglichkeit, diese Einstellung und diesen Wert nur dem Produktionsslot als (dauerhafte) Bereitstellungsslot-Einstellung hinzufügen.

WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS

Standardmäßig sind die Versionseinstellungen für Funktions-Apps für jeden Slot spezifisch festgelegt. Diese Einstellung wird verwendet, wenn Sie Funktionen mithilfe von Bereitstellungsslots aktualisieren. Dies verhindert unerwartetes Verhalten aufgrund von Änderungen von Versionen nach einem Austausch. Wählen Sie für die Produktion und den Slot den Wert 0, um sicherzustellen, dass alle Versionseinstellungen ebenfalls ausgetauscht werden. Weitere Informationen finden Sie unter Aktualisieren mit Slots.

Schlüssel	Beispielwert
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS	`0`

WEBSITE_RUN_FROM_PACKAGE

Ermöglicht es Ihrer Funktions-App, aus einer Paketdatei auszuführen, die lokal oder in einer externen URL bereitgestellt werden kann.

Schlüssel	Beispielwert
WEBSITE_RUN_FROM_PACKAGE	`1`

Gültige Werte sind entweder eine URL, die in den Speicherort einer externen Bereitstellungspaketdatei aufgelöst werden kann, oder 1. Bei einer Festlegung auf 1 muss sich das Paket im Ordner d:\home\data\SitePackages befinden. Wenn Sie die Zip-Bereitstellung mit der Einstellung „WEBSITE_RUN_FROM_PACKAGE“ verwenden, wird das Paket automatisch an diesen Speicherort hochgeladen. In der Vorschau wurde diese Einstellung als WEBSITE_RUN_FROM_ZIP bezeichnet. Weitere Informationen finden Sie unter Ausführen Ihrer Azure Functions aus einem Paket.

Wenn Sie aus einer externen Paket-URL bereitstellen, müssen Sie auch Auslöser manuell synchronisieren. Weitere Informationen finden Sie unter Synchronisieren von Triggern.

WEBSITE_SKIP_CONTENTSHARE_VALIDATION

Die Einstellungen WEBSITE_CONTENTAZUREFILECONNECTIONSTRING und WEBSITE_CONTENTSHARE verfügen über zusätzliche Validierungsprüfungen, um sicherzustellen, dass die App ordnungsgemäß gestartet werden kann. Die Erstellung von Anwendungseinstellungen schlägt fehl, wenn die Funktions-App das Downstreamspeicherkonto oder Key Vault aufgrund von Netzwerkeinschränkungen oder anderen begrenzenden Faktoren nicht ordnungsgemäß aufrufen kann. Wenn WEBSITE_SKIP_CONTENTSHARE_VALIDATION auf 1 festgelegt ist, wird die Validierungsprüfung übersprungen. Andernfalls wird der Wert standardmäßig auf 0 festgelegt, und die Validierung findet statt.

Schlüssel	Beispielwert
WEBSITE_SKIP_CONTENTSHARE_VALIDATION	`1`

Wenn die Überprüfung übersprungen wird und entweder die Verbindungszeichenfolge oder die Inhaltsfreigabe ungültig ist, kann die App nicht ordnungsgemäß gestartet werden. In diesem Fall gibt Functions „HTTP 500“-Fehler zurück. Weitere Informationen finden Sie unter Problembehandlung: „Azure Functions-Runtime ist nicht erreichbar“.

WEBSITE_SLOT_NAME

Schreibgeschützt. Name des aktuellen Bereitstellungsslots. Der Name des Produktionsslots ist Production.

Schlüssel	Beispielwert
WEBSITE_SLOT_NAME	`Production`

WEBSITE_TIME_ZONE

Ermöglicht das Festlegen der Zeitzone für Ihre Funktions-App.

Schlüssel	OS	Beispielwert
WEBSITE_TIME_ZONE	Windows	`Eastern Standard Time`
WEBSITE_TIME_ZONE	Linux	`America/New_York`

Als Standardzeitzone wird in Verbindung mit den CRON-Ausdrücken die Coordinated Universal Time (UTC) verwendet. Wenn Sie möchten, dass Ihr CRON-Ausdruck auf einer anderen Zeitzone basiert, erstellen Sie eine App-Einstellung für die Funktionen-App mit dem Namen WEBSITE_TIME_ZONE.

Der Wert dieser Einstellung hängt davon ab, unter welchem Betriebssystem und Plan Ihre Funktions-App ausgeführt wird.

Betriebssystem	Plan	Wert
Windows	All	Legen Sie den Wert auf den Namen der gewünschten Zeitzone fest, wie in der zweiten Zeile des vom Windows-Befehl `tzutil.exe /L` ausgegebenen Wertepaars angegeben.
Linux	Premium Dediziert	Legen Sie den Wert auf den Namen der gewünschten Zeitzone fest (gemäß tz-Datenbank).

Hinweis

WEBSITE_TIME_ZONE und TZ werden derzeit nicht unterstützt, wenn sie unter Linux in einem Verbrauchsplan ausgeführt werden. In diesem Fall kann das Festlegen von WEBSITE_TIME_ZONE oder TZ SSL-bezogene Probleme verursachen und dazu führen, dass Metriken für Ihre App nicht mehr funktionieren.

Ein Beispiel: Für die Zeitzone „Eastern Time“ in den USA (dargestellt durch Eastern Standard Time unter Windows oder America/New_York unter Linux) wird derzeit UTC-05:00 in der Standardzeit und UTC-04:00 in der Sommerzeit verwendet. Damit ein Timertrigger jeden Tag um 10:00 vormittags in der Zeitzone „Eastern Time“ ausgelöst wird, erstellen Sie eine App-Einstellung für Ihre Funktions-App mit dem Namen WEBSITE_TIME_ZONE, legen den Wert auf Eastern Standard Time (Windows) bzw. America/New_York (Linux) fest, und verwenden dann den folgenden NCRONTAB-Ausdruck:

"0 0 10 * * *"

Wenn Sie WEBSITE_TIME_ZONE verwenden, wird die Uhrzeit an Abweichungen in der jeweiligen Zeitzone angepasst, einschließlich Sommerzeit und Änderungen an der Standardzeit.

WEBSITE_USE_PLACEHOLDER

Gibt an, ob beim Ausführen des Verbrauchsplans eine bestimmte Optimierung des Kaltstarts verwendet werden soll. Legen Sie diese Einstellung auf „0“ fest, um die Optimierung des Kaltstarts für den Verbrauchsplan zu deaktivieren.

Schlüssel	Beispielwert
WEBSITE_USE_PLACEHOLDER	`1`

WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED

Gibt an, ob beim Ausführen von .NET-Funktionen für isolierte Workerprozesse im Verbrauchsplan eine bestimmte Kaltstart-Optimierung verwendet werden soll. Legen Sie diese Einstellung auf „0“ fest, um die Optimierung des Kaltstarts für den Verbrauchsplan zu deaktivieren.

Schlüssel	Beispielwert
WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED	`1`

WEBSITE_VNET_ROUTE_ALL

Wichtig

WEBSITE_VNET_ROUTE_ALL ist eine Legacy-App-Einstellung, die durch die Site-Einstellung vnetRouteAllEnabled ersetzt wurde.

Gibt an, ob der gesamte ausgehende Datenverkehr von der App über das virtuelle Netzwerk weitergeleitet wird. Der Einstellungswert 1 gibt an, dass der gesamte Datenverkehr über das virtuelle Netzwerk weitergeleitet wird. Sie müssen diese Einstellung verwenden, wenn Sie die Features der regionalen Integration des virtuellen Netzwerks verwenden. Sie wird auch verwendet, wenn ein Virtual Network NAT Gateway verwendet wird, um eine statische ausgehende IP-Adresse zu definieren.

Schlüssel	Beispielwert
WEBSITE_VNET_ROUTE_ALL	`1`

WEBSITES_ENABLE_APP_SERVICE_STORAGE

Gibt an, ob das /home-Verzeichnis über skalierte Instanzen hinweg freigegeben wird, mit einem Standardwert von true. Sie sollten dies auf false festlegen, wenn Sie Ihre Funktions-App in einem Container bereitstellen. d

App Service-Siteeinstellungen

Einige Konfigurationen, wie etwa Sprachversionen, müssen auf App Service-Ebene als Siteeinstellungen verwaltet werden. Diese Einstellungen werden in der Regel im Portal mithilfe von REST-APIs, Azure CLI oder Azure PowerShell verwaltet. Die folgenden Siteeinstellungen können je nach Runtimesprache, Betriebssystem und Versionen erforderlich sein:

alwaysOn

Bei einer Funktions-App, die in einem Dedicated (App Service)-Plan ausgeführt wird, geht die Funktions-Laufzeit nach einigen Minuten der Inaktivität in den Leerlauf, wobei nur Anfragen an einen HTTP-Trigger Ihre Funktionen aufwecken. Um sicherzustellen, dass Ihre nicht durch HTTP ausgelösten Funktionen ordnungsgemäß ausgeführt werden, einschließlich Timertrigger, aktivieren Sie Always On für die Funktions-App, indem Sie die alwaysOn-Websiteeinstellung auf einen Wert von true festlegen.

linuxFxVersion

Für Funktions-Apps, die unter Linux ausgeführt werden, gibt linuxFxVersion die Sprache und Version für den sprachspezifischen Workerprozess an. Diese Informationen werden zusammen mit FUNCTIONS_EXTENSION_VERSION verwendet, um zu bestimmen, welches bestimmte Linux-Containerimage installiert ist, um Ihre Funktions-App auszuführen. Diese Einstellung kann auf einen vordefinierten Wert oder einen benutzerdefinierten Bild-URI festgelegt werden.

Dieser Wert wird für Sie festgelegt, wenn Sie Ihre Linux-Funktions-App erstellen. Möglicherweise müssen Sie ihn für ARM-Vorlagen und Bicep-Bereitstellungen und in bestimmten Upgradeszenarien festlegen.

Gültige linuxFxVersion-Werte

Sie können den folgenden Azure CLI-Befehl verwenden, um eine Tabelle der aktuellen linuxFxVersion-Werte nach unterstützter Functions-Runtimeversion anzuzeigen:

az functionapp list-runtimes --os linux --query "[].{stack:join(' ', [runtime, version]), LinuxFxVersion:linux_fx_version, SupportedFunctionsVersions:to_string(supported_functions_versions[])}" --output table

Der vorherige Befehl erfordert ein Upgrade auf Version 2.40 der Azure CLI.

Benutzerdefinierte Images

Wenn Sie Ihren eigenen benutzerdefinierten Linux-Container für Ihre Funktions-App erstellen und verwalten, liegt der linuxFxVersion-Wert wie im folgenden Beispiel stattdessen im Format DOCKER|<IMAGE_URI> vor:

linuxFxVersion = "DOCKER|contoso.com/azurefunctionsimage:v1.0.0"

Damit wird die Registrierungsquelle des bereitgestellten Containers angegeben. Weitere Informationen finden Sie unter Arbeiten mit Containern und Azure Functions.

Wichtig

Wenn Sie eigene Container erstellen, müssen Sie das Basisimage Ihres Containers auf das neueste unterstützte Basisimage aktualisieren. Unterstützte Basisimages für Azure Functions sind sprachspezifisch und sind unter Repositorys für Azure Functions-Basisimages verfügbar.

Das Functions-Team ist bestrebt, monatliche Updates für diese Basisimages zu veröffentlichen. Regelmäßige Updates umfassen die neuesten Updates der Nebenversion und Sicherheitskorrekturen für Functions-Runtime und -Sprachen. Sie sollten Ihren Container regelmäßig aus dem neuesten Basisimage aktualisieren und die aktualisierte Version Ihres Containers erneut bereitstellen.

netFrameworkVersion

Legt die spezifische Version von .NET für C#-Funktionen fest. Weitere Informationen finden Sie unter Aktualisieren Ihrer Funktions-App in Azure.

powerShellVersion

Legt die spezifische Version von PowerShell fest, auf der Ihre Funktionen ausgeführt werden. Weitere Informationen finden Sie unter Ändern der PowerShell-Version.

Bei lokaler Ausführung verwenden Sie stattdessen die FUNCTIONS_WORKER_RUNTIME_VERSION-Einstellung in der Datei „local.settings.json“.

vnetrouteallenabled

Diese Websiteeinstellung ersetzt die Legacy-Einstellung WEBSITE_VNET_ROUTE_ALL.

Nächste Schritte

Informationen zum Aktualisieren von App-Einstellungen

Konfigurationseinstellungen in der Datei „host.json“

Weitere App-Einstellungen für App Service-Apps