Referenz zu App-Einstellungen für Azure Functions
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:
- Wenn Ihre Funktions-App die zusätzlichen Anpassungen erfordert, die bei Verwendung der Verbindungszeichenfolge unterstützt werden
- Wenn Ihre Application Insights-Instanz in einer Sovereign Cloud ausgeführt wird, 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.
AzureWebJobsDotNetReleaseCompilation
true
bedeutet, dass beim Kompilieren von .NET-Code der Release
-Modus 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 104.857.600 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:
AcrUseManagedIdentityCreds
Gibt an, ob das Image von einer Azure Container Registry-Instanz mithilfe der verwalteten Identitätsauthentifizierung abgerufen wird. Ein Wert von true
erfordert, dass die verwaltete Identität verwendet wird, die über gespeicherte Authentifizierungsanmeldeinformationen als bewährte Methode für die Sicherheit empfohlen wird.
AcrUserManagedIdentityID
Gibt die verwaltete Identität an, die beim Abrufen des Images aus einer Azure Container Registry-Instanz verwendet werden soll. Erfordert, dass AcrUseManagedIdentityCreds
auf true
festgelegt wird. Dies sind die gültigen Werte:
Wert | Beschreibung |
---|---|
system |
Die vom System zugewiesene verwaltete Identität der Funktions-App wird verwendet. |
<USER_IDENTITY_RESOURCE_ID> |
Die vollqualifizierte Ressourcen-ID einer benutzerseitig zugewiesenen verwalteten Identität. |
Die angegebene Identität muss der ACRPull
-Rolle in der Containerregistrierung hinzugefügt werden. Weitere Informationen finden Sie unter Erstellen und Konfigurieren einer Funktions-App in Azure mit dem Image.
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 virtuellen Netzwerk in Flex geerbt. |
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT |
Ersetzt durch maximumInstanceCount in properties.functionAppConfig.scaleAndConcurrency |
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