Teilen über

Referenz zu App-Einstellungen für Azure Functions

  • Artikel

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.

Da Azure Functions die Azure App Service-Plattform für das Hosting nutzt, finden Sie möglicherweise einige Einstellungen, die für Ihre Funktions-App relevant sind, die in Umgebungsvariablen und App-Einstellungen in Azure App Service dokumentiert ist.

Ü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 der Doppelpunkt (:) reservierte Werte. Doppelte Unterstriche werden sowohl unter Windows als auch unter Linux als hierarchische Trennzeichen interpretiert, wohingegen das Semikolon nur unter Windows 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ützter App 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.

APPLICATIONINSIGHTS_AUTHENTICATION_STRING

Ermöglicht den Zugriff auf Application Insights mithilfe der Microsoft Entra-Authentifizierung. Verwenden Sie diese Einstellung, wenn Sie eine Verbindung zu Ihrem Application Insights-Arbeitsbereich über die Microsoft Entra-Authentifizierung herstellen müssen. Weitere Informationen finden Sie unter Microsoft Entra-Authentifizierung für Application Insights.

Bei Verwendung von APPLICATIONINSIGHTS_AUTHENTICATION_STRING hängt der von Ihnen festgelegte spezifische Wert vom Typ der verwalteten Identität ab:

Verwaltete Identität Einstellungswert
Systemseitig zugewiesen Authorization=AAD
Benutzerseitig zugewiesen Authorization=AAD;ClientId=<USER_ASSIGNED_CLIENT_ID>

Diese Authentifizierungsanforderung wird auf Verbindungen vom Functions-Host, Momentaufnahmedebugger, Profiler und allen sprachspezifischen Agents angewendet. Um diese Einstellung zu verwenden, muss die verwaltete Identität bereits für die Funktions-App verfügbar sein, wobei eine zugewiesene Rolle dem Publisher für Überwachungsmetriken entspricht.

Hinweis

Wenn Sie APPLICATIONINSIGHTS_AUTHENTICATION_STRING zum Herstellen einer Verbindung mit Application Insights mithilfe der Microsoft Entra-Authentifizierung verwenden, sollten Sie auch Lokale Authentifizierung für Application Insights deaktivieren. Diese Konfiguration erfordert die Microsoft Entra-Authentifizierung, damit Telemetrie in Ihren Arbeitsbereich aufgenommen werden kann.

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

Um eine Verbindung zu Application Insights mit Microsoft Entra-Authentifizierung herzustellen, sollten Sie APPLICATIONINSIGHTS_AUTHENTICATION_STRING verwenden.

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 Verwalten des Schlüsselspeichers.

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 Verwalten des Schlüsselspeichers.

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 Verwalten des Schlüsselspeichers.

AzureWebJobsSecretStorageKeyVaultName

Diese Einstellung ist veraltet und wurde nur verwendet, als sie auf Version 3.x der Azure Functions-Runtime ausgeführt wurde.

Der Name einer Schlüsseltresorinstanz, die zum Speichern von Schlüsseln verwendet wird. Diese Einstellung wurde nur in Version 3.x der Funktionslaufzeit verwendet, die nicht mehr unterstützt wird. 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 Verwalten des Schlüsselspeichers.

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 Verwalten des Schlüsselspeichers.

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

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
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 Verwalten des Schlüsselspeichers.

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 Verwalten des Schlüsselspeichers.

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

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

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.

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. „~4“). Wenn neue kleinere Versionen für dieselbe Hauptversion verfügbar sind, werden sie automatisch in der Funktions-App installiert.

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
~1 1.x Support endet am 14. September 2026

Der Wert ~4 bedeutet, dass Ihre App mit Version 4.x der Runtime ausgeführt wird. Der Wert ~1 heftet Ihre App an Version 1.x der Runtime an. Laufzeitversionen 2.x und 3.x werden nicht mehr unterstützt. Weitere Informationen finden Sie unter Einstellen von Runtimeversionen von Azure Functions als Ziel. Wenn Sie von der Unterstützung aufgefordert werden, Ihre App an eine bestimmte Nebenversion anzuheften, verwenden Sie die Vollständige Versionsnummer (z. B. 4.0.12345). Weitere Informationen finden Sie unter Einstellen von Runtimeversionen von Azure Functions als Ziel.

FUNCTIONS_INPROC_NET8_ENABLED

Gibt an, ob eine App .NET 8 im In-Process-Modell verwenden kann. Um .NET 8 für das In-Process-Modell zu verwenden, muss dieser Wert auf 1 festgelegt werden. Umfassende Anweisungen, u. a. zu weiteren erforderlichen Konfigurationswerten, finden Sie unter Aktualisieren, um .NET 8 zu verwenden.

Schlüssel Beispielwert
FUNCTIONS_INPROC_NET8_ENABLED 1

Legen Sie die Option auf 0 fest, um die Unterstützung für .NET 8 im In-Process-Modell zu deaktivieren.

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 niedriger wird die App-Einstellung verwendet, 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_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_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_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.

languageWorkers__java__arguments

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.

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

Wichtig

WEBSITE_CONTENTOVERVNET ist eine Legacy-App-Einstellung, die durch die Siteeigenschaft vnetContentShareEnabled ersetzt wurde.

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. Sie ist nur erforderlich, wenn WEBSITE_CONTENTSHARE und WEBSITE_CONTENTAZUREFILECONNECTIONSTRING verwendet werden. Weitere Informationen finden Sie unter Einschränken Ihres Speicherkontos auf ein virtuelles Netzwerk.

Schlüssel Beispielwert
WEBSITE_CONTENTOVERVNET 1

Diese App-Einstellung ist für die App Service-Pläne Elastic Premium und Dedicated (Standard und höher) erforderlich. Wird nicht unterstützt, wenn es auf einem Verbrauchsplan ausgeführt wird.

Hinweis

Sie müssen beim Weiterleiten an die Inhaltsfreigabe in einem Speicherkonto, das von mehreren Funktions-Apps unter demselben Plan gemeinsam genutzt wird, besondere Sorgfalt anwenden. Weitere Informationen finden Sie im Artikel zu Speicherüberlegungen unter Konsistentes Routing über virtuelle Netzwerke.

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 Anwendungsdatenverkehr über das virtuelle Netzwerk weitergeleitet wird. Sie benötigen diese Einstellung beim Konfigurieren der regionalen VNet-Integration in den Hostingplänen „Elastic Premium“ und „Dedicated“. 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.

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 unter dem App Service-Plan „Dedicated“ ausgeführt wird, geht die Functions-Runtime 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 Websiteeinstellung alwaysOn auf einen Wert von true festlegen.

functionsRuntimeAdminIsolationEnabled

Bestimmt, ob auf die in Ihrer Funktions-App integrierten Administratorendpunkte (/admin) zugegriffen werden kann. Bei Festlegung auf false (Standardeinstellung) erlaubt die App Anforderungen an Endpunkte unter /admin, wenn diese Anforderungen einen Masterschlüssel in der Anforderung darstellen. Wenn auf true-, /admin-Endpunkte nicht zugegriffen werden können, selbst mit einem Masterschlüssel.

Diese Eigenschaft kann nicht für Apps festgelegt werden, die mit der SKU „Linux-Verbrauch“ ausgeführt werden, und sie kann nicht für Apps festgelegt werden, die mit Version 1.x von Azure Functions ausgeführt werden. Wenn Sie Version 1.x verwenden, müssen Sie zunächst zu Version 4.x migrieren.

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

vnetContentShareEnabled

Apps, die in einem Premium-Plan ausgeführt werden, verwenden eine Dateifreigabe zum Speichern von Inhalten. Der Name dieser Inhaltsfreigabe wird in der App-Einstellung WEBSITE_CONTENTSHARE gespeichert, und die Verbindungszeichenfolge wird in WEBSITE_CONTENTAZUREFILECONNECTIONSTRING gespeichert. Um den Datenverkehr zwischen Ihrer Funktions-App und der Inhaltsfreigabe über ein virtuelles Netzwerk weiterzuleiten, müssen Sie vnetContentShareEnabled zudem auf true festlegen. Das Aktivieren dieser Siteeigenschaft ist notwendig, wenn Sie Ihr Speicherkonto auf ein virtuelles Netzwerk in den Hostingplänen „Elastic Premium“ und „Dedicated“ beschränken.

Hinweis

Sie müssen beim Weiterleiten an die Inhaltsfreigabe in einem Speicherkonto, das von mehreren Funktions-Apps unter demselben Plan gemeinsam genutzt wird, besondere Sorgfalt anwenden. Weitere Informationen finden Sie im Artikel zu Speicherüberlegungen unter Konsistentes Routing über virtuelle Netzwerke.

Diese Siteeigenschaft ersetzt die Legacyeinstellung WEBSITE_CONTENTOVERVNET.

vnetImagePullEnabled

Funktionen unterstützen Funktions-Apps, die in Linux-Containern ausgeführt werden. Um eine Verbindung mit einer Containerregistrierung in einem virtuellen Netzwerk herzustellen und Inhalte aus dieser abzurufen, müssen Sie vnetImagePullEnabled auf true festlegen. Diese Siteeigenschaft wird in den Hostingplänen „Elastic Premium“ und „Dedicated“ unterstützt. Der Plan „Flex Consumption“ benötigt keine Siteeigenschaften oder App-Einstellungen zum Konfigurieren des Netzwerks. Weitere Informationen finden Sie unter Veraltete Funktionen beim Flex-Verbrauchstarif.

vnetRouteAllEnabled

Gibt an, ob der gesamte ausgehende Datenverkehr von der App über das virtuelle Netzwerk weitergeleitet wird. Der Einstellungswert true gibt an, dass der gesamte Anwendungsdatenverkehr über das virtuelle Netzwerk weitergeleitet wird. Verwenden Sie diese Einstellung beim Konfigurieren der regionalen VNet-Integration in den Plänen „Elastic Premium“ und „Dedicated“. Sie wird auch verwendet, wenn ein Virtual Network NAT Gateway verwendet wird, um eine statische ausgehende IP-Adresse zu definieren. Weitere Informationen finden Sie unter Konfigurieren des Anwendungsroutings.

Diese Websiteeinstellung ersetzt die Legacy-Einstellung WEBSITE_VNET_ROUTE_ALL.

Veraltete Funktionen beim Flex-Verbrauchstarif

Im Flex-Verbrauchstarif sind diese Websiteeigenschaften und Anwendungseinstellungen veraltet und sollten beim Erstellen von Ressourcen für Funktions-Apps nicht verwendet werden:

Einstellung/Eigenschaft `Reason`
ENABLE_ORYX_BUILD Ersetzt durch den Parameter remoteBuild bei der Bereitstellung für den Flex-Verbrauch
FUNCTIONS_EXTENSION_VERSION App-Einstellung wird vom Back-End festgelegt. Der Wert ~1 kann ignoriert werden.
FUNCTIONS_WORKER_RUNTIME Ersetzt durch name in properties.functionAppConfig.runtime
FUNCTIONS_WORKER_RUNTIME_VERSION Ersetzt durch version in properties.functionAppConfig.runtime
FUNCTIONS_MAX_HTTP_CONCURRENCY Ersetzt durch Triggerabschnitt für Skalierung und Parallelität
FUNCTIONS_WORKER_PROCESS_COUNT Einstellung ungültig
FUNCTIONS_WORKER_DYNAMIC_CONCURRENCY_ENABLED Einstellung ungültig
SCM_DO_BUILD_DURING_DEPLOYMENT Ersetzt durch den Parameter remoteBuild bei der Bereitstellung für den Flex-Verbrauch
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING Ersetzt durch den Abschnitt für die functionAppConfig-Bereitstellung
WEBSITE_CONTENTOVERVNET Wird für Netzwerke beim Flex-Verbrauch nicht verwendet
WEBSITE_CONTENTSHARE Ersetzt durch den Abschnitt für die functionAppConfig-Bereitstellung
WEBSITE_DNS_SERVER DNS wird vom integrierten VNet in Flex geerbt
WEBSITE_NODE_DEFAULT_VERSION Ersetzt durch version in properties.functionAppConfig.runtime
WEBSITE_RUN_FROM_PACKAGE Wird für Bereitstellungen beim Flex-Verbrauch nicht verwendet
WEBSITE_SKIP_CONTENTSHARE_VALIDATION Die Inhaltsfreigabe wird beim Flex-Verbrauch nicht verwendet
WEBSITE_VNET_ROUTE_ALL Wird für Netzwerke beim Flex-Verbrauch nicht verwendet
properties.alwaysOn Nicht gültig
properties.containerSize Umbenannt als instanceMemoryMB
properties.ftpsState FTPS nicht unterstützt
properties.isReserved Nicht gültig
properties.IsXenon Nicht gültig
properties.javaVersion Ersetzt durch version in properties.functionAppConfig.runtime
properties.LinuxFxVersion Ersetzt durch properties.functionAppConfig.runtime
properties.netFrameworkVersion Ersetzt durch version in properties.functionAppConfig.runtime
properties.powerShellVersion Ersetzt durch version in properties.functionAppConfig.runtime
properties.siteConfig.functionAppScaleLimit Umbenannt als maximumInstanceCount
properties.siteConfig.preWarmedInstanceCount Umbenannt als alwaysReadyInstances
properties.use32BitWorkerProcess 32-Bit nicht unterstützt
properties.vnetBackupRestoreEnabled Wird für Netzwerke beim Flex-Verbrauch nicht verwendet
properties.vnetContentShareEnabled Wird für Netzwerke beim Flex-Verbrauch nicht verwendet
properties.vnetImagePullEnabled Wird für Netzwerke beim Flex-Verbrauch nicht verwendet
properties.vnetRouteAllEnabled Wird für Netzwerke beim Flex-Verbrauch nicht verwendet
properties.windowsFxVersion Nicht gültig

Nächste Schritte

Informationen zum Aktualisieren von App-Einstellungen

Konfigurationseinstellungen in der Datei „host.json“

Weitere App-Einstellungen für App Service-Apps