Informations de référence sur les paramètres d’application d’Azure Functions

  • Article

Les paramètres d’une application de fonction contiennent les options de configuration qui affectent l’ensemble des fonctions de cette application de fonction. Ces paramètres sont accessibles en tant que variables d’environnement. Cet article répertorie les paramètres d’application qui sont disponibles dans les applications de fonction.

Plusieurs méthodes sont possibles pour ajouter, mettre à jour et supprimer des paramètres d’une application de fonction :

Les changements apportés aux paramètres d’application de fonction nécessitent le redémarrage de votre application de fonction.

Dans cet article, les exemples de valeurs de chaîne de connexion sont tronqués pour des raisons de lisibilité.

Considérations relatives aux paramètres d’application

Lorsque vous utilisez les paramètres d’application, vous devez tenir compte des éléments suivants :

  • Les changements apportés aux paramètres d’application de fonction nécessitent le redémarrage de votre application de fonction.

  • Dans les noms des paramètres, le trait de soulignement double (__) et le point-virgule (:) sont considérés comme des valeurs réservées. Les traits de soulignement doubles sont interprétés comme des délimiteurs hiérarchiques sur Windows et Linux et les points-virgules sont interprétés de la même façon uniquement sur Linux. Par exemple, le paramètre AzureFunctionsWebHost__hostid=somehost_123456 est interprété comme l’objet JSON suivant :

    "AzureFunctionsWebHost": {
    "hostid": "somehost_123456"
}

    Dans cet article, seuls les traits de soulignement doubles sont utilisés, car ils sont pris en charge sur les deux systèmes d’exploitation. La plupart des paramètres qui prennent en charge les connexions d’identités managées utilisent des doubles tirets bas.

  • Lorsque Functions s’exécute localement, les paramètres d’application sont spécifiés dans la collection Values de local.settings.json.

  • Les fichiers host.json et local.settings.json contiennent d’autres options de configuration d’application de fonction.

  • Vous pouvez utiliser des paramètres d’application pour remplacer les valeurs de paramètres host.json sans avoir à modifier le fichier host.json proprement dit. C’est utile dans des scénarios où vous devez configurer ou modifier des paramètres host.json spécifiques pour un environnement spécifique. Cela vous permet également de modifier les paramètres host.json sans avoir à republier votre projet. Pour plus d’informations, consultez l’article de référence host.json.

  • Cet article documente les paramètres les plus pertinents pour vos applications de fonction. Étant donné qu’Azure Functions s’exécute sur App Service, d’autres paramètres d’application sont également pris en charge. Pour en savoir plus, consultez Variables d’environnement et paramètres d’application dans Azure App Service.

  • Certains scénarios vous obligent également à utiliser les paramètres documentés dans Paramètres de site App Service.

  • Il se peut que votre application cesse de répondre lorsque vous changez des paramètres d’application App Service enlecture seule.

  • Agissez avec prudence lorsque vous mettez jour des paramètres d’application à l’aide d’API REST, y compris des modèles ARM. Étant donné que ces API remplacent les paramètres d’application existants, vous devez inclure tous les paramètres existants lors de l’ajout ou de la modification de paramètres à l’aide d’API REST ou de modèles ARM. Si possible, utilisez Azure CLI ou Azure PowerShell pour utiliser les paramètres d’application de manière programmatique. Pour plus d’informations, consultez Utiliser des paramètres d’application.

APPINSIGHTS_INSTRUMENTATIONKEY

Clé d’instrumentation pour Application Insights. Ne pas utiliser APPINSIGHTS_INSTRUMENTATIONKEY et APPLICATIONINSIGHTS_CONNECTION_STRING simultanément. Si possible, utilisez APPLICATIONINSIGHTS_CONNECTION_STRING. Lorsque Application Insights s’exécute dans un cloud souverain, vous devez utiliser APPLICATIONINSIGHTS_CONNECTION_STRING. Pour plus d’informations, consultez Comment configurer la surveillance de Azure Functions.

Clé Exemple de valeur
APPINSIGHTS_INSTRUMENTATIONKEY 55555555-af77-484b-9032-64f83bb83bb

Ne pas utiliser APPINSIGHTS_INSTRUMENTATIONKEY et APPLICATIONINSIGHTS_CONNECTION_STRING simultanément. L’utilisation de APPLICATIONINSIGHTS_CONNECTION_STRING est recommandée.

Notes

Le support de l’ingestion de clé d’instrumentation prendra fin le 31 mars 2025. L’ingestion de clé d’instrumentation continuera de fonctionner, mais nous ne fournirons plus de mises à jour ni de support pour la fonctionnalité. Passez aux chaînes de connexion pour tirer parti des nouvelles fonctionnalités.

APPLICATIONINSIGHTS_CONNECTION_STRING

Chaîne de connexion pour Application Insights. Ne pas utiliser APPINSIGHTS_INSTRUMENTATIONKEY et APPLICATIONINSIGHTS_CONNECTION_STRING simultanément. Bien que l’utilisation de APPLICATIONINSIGHTS_CONNECTION_STRING soit recommandée dans tous les cas, elle est requise dans les cas suivants :

  • lorsque votre application de fonction requiert les personnalisations ajoutées prises en charge à l’aide de la chaîne de connexion.
  • Lorsque votre instance d’Application Insights s’exécute dans un cloud souverain, qui requiert un point de terminaison personnalisé.

Pour plus d’informations, consultez Chaînes de connexion.

Clé Exemple de valeur
APPLICATIONINSIGHTS_CONNECTION_STRING InstrumentationKey=...

AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL

Important

Les proxys Azure Functions sont une fonctionnalité héritée des versions 1.x à 3.x du runtime Azure Functions. Pour plus d’informations sur la prise en charge héritée dans la version 4.x, consultez Proxies Functions.

Par défaut, les proxies Functions utilisent un raccourci pour envoyer des appels d’API à partir de proxies directement vers les fonctions de la même application de fonction. Ce raccourci est utilisé au lieu de créer une nouvelle requête HTTP. Ce paramètre vous permet de désactiver le comportement de ce raccourci.

Clé Valeur Description
AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL true Les appels dont l’URL de back-end pointe vers une fonction de l’application de fonction locale ne seront pas envoyés directement vers la fonction. Au lieu de cela, les requêtes sont retournées au serveur frontal HTTP pour l’application de fonction.
AZURE_FUNCTION_PROXY_DISABLE_LOCAL_CALL false Les appels dont l’URL de back-end pointe vers une fonction de l’application de fonction locale sont transférés directement vers la fonction. false est la valeur par défaut.

AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES

Important

Les proxys Azure Functions sont une fonctionnalité héritée des versions 1.x à 3.x du runtime Azure Functions. Pour plus d’informations sur la prise en charge héritée dans la version 4.x, consultez Proxies Functions.

Ce paramètre vérifie si les caractères %2F sont décodés en tant que barres obliques dans les paramètres d’itinéraire lorsqu’ils sont réinsérés dans l’URL principale.

Clé Valeur Description
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES true Les paramètres d’itinéraire avec des barres obliques encodées sont décodés.
AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES false Tous les paramètres d’itinéraire sont transmis tels quels, ce qui correspond au comportement par défaut.

Par exemple, considérez le fichier proxies.json pour une application de fonction au niveau du domaine myfunction.com.

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

Lorsque AZURE_FUNCTION_PROXY_BACKEND_URL_DECODE_SLASHES a la valeur true, l’URL example.com/api%2ftest correspond à example.com/api/test. Par défaut, l’URL reste inchangée en tant que example.com/test%2fapi. Pour plus d’informations, consultez Proxys de fonctions.

AZURE_FUNCTIONS_ENVIRONMENT

Configure l’environnement d’hébergement du runtime de l’application de fonction lors de l’exécution dans Azure. Cette valeur est lue pendant l’initialisation, et seules ces valeurs sont respectées par le runtime :

Valeur Description
Production Représente un environnement de production, avec une journalisation réduite et des optimisations complètes des performances. Il s’agit de la valeur par défaut lorsque AZURE_FUNCTIONS_ENVIRONMENT n’est pas définie ou est définie sur une valeur non prise en charge.
Staging Représente un environnement intermédiaire, par exemple lors de l’exécution dans un emplacement de préproduction.
Development Un environnement de développement prend en charge la journalisation plus détaillée et d’autres optimisations de performances réduites. Azure Functions Core Tools définit AZURE_FUNCTIONS_ENVIRONMENT sur Development lorsqu’il est exécuté sur votre ordinateur local. Ce paramètre ne peut pas être remplacé dans le fichier local.settings.json.

Utilisez ce paramètre au lieu de ASPNETCORE_ENVIRONMENT si vous avez besoin de sélectionner un environnement de runtime dans Azure différent de Production. Pour plus d’informations, consultez Classes et méthodes de démarrage basées sur l’environnement.

Ce paramètre n’est pas disponible dans la version 1.x du runtime Functions.

AzureFunctionsJobHost__*

Dans la version 2.x et les versions ultérieures du runtime Functions, les paramètres d’application peuvent substituer les paramètres de host.json dans l’environnement actuel. Ces remplacements sont exprimés sous la forme de paramètres d’application nommés AzureFunctionsJobHost__path__to__setting. Pour plus d’informations, consultez Substituer les valeurs de host.json.

AzureFunctionsWebHost__hostid

Définit l’ID hôte d’une application de fonction donnée, qui doit être un ID unique. Ce paramètre remplace la valeur d’ID hôte générée automatiquement de votre application. Utilisez ce paramètre uniquement lorsque vous devez empêcher les collisions d’ID hôte entre les applications de fonction qui partagent le même compte de stockage.

Un ID d’hôte doit répondre aux exigences suivantes :

  • Contenir entre 1 et 32 caractères
  • Contenir uniquement des lettres minuscules, des chiffres et des tirets
  • Ne pas commencer ou se terminer par un tiret
  • Ne pas contenir de tirets consécutifs

Un moyen simple de générer un ID consiste à prendre un identificateur unique, à supprimer les tirets et à le mettre en minuscules, par exemple en convertissant le GUID 1835D7B5-5C98-4790-815D-072CC94C6F71 en valeur 1835d7b55c984790815d072cc94c6f71.

Clé Exemple de valeur
AzureFunctionsWebHost__hostid myuniquefunctionappname123456789

Pour plus d’informations, consultez Considérations relatives à l’ID d’hôte.

AzureWebJobsDashboard

Ce paramètre est déconseillé et n’est pris en charge que lors de l’exécution sur la version 1.x du runtime Azure Functions.

Chaîne de connexion du compte de stockage facultatif pour stocker des journaux d’activité et les afficher dans l’onglet Surveiller du portail. Le compte de stockage doit être à usage général. Il prend en charge les objets blob, les files d’attente et les tables. Pour plus d’informations, consultez Exigences pour le compte de stockage.

Clé Exemple de valeur
AzureWebJobsDashboard DefaultEndpointsProtocol=https;AccountName=...

AzureWebJobsDisableHomepage

Une valeur de true désigne la désactivation de la page d’arrivée par défaut qui s’affiche pour l’URL racine d’une application de fonction. La valeur par défaut est false.

Clé Exemple de valeur
AzureWebJobsDisableHomepage true

Lorsque ce paramètre d’application est omis ou défini sur false, une page semblable à celle indiquée dans l’exemple suivant s’affiche en réponse à l’URL <functionappname>.azurewebsites.net.

Page d’arrivée d’une application de fonction

AzureWebJobsDotNetReleaseCompilation

La valeur true désigne l’utilisation du mode Mise en production lors de la compilation de code .NET ; la valeur false désigne l’utilisation du mode Débogage. La valeur par défaut est true.

Clé Exemple de valeur
AzureWebJobsDotNetReleaseCompilation true

AzureWebJobsFeatureFlags

Liste délimitée par des virgules des fonctionnalités bêta à activer. Les fonctionnalités bêta activées par ces indicateurs ne sont pas prêtes pour la production, mais peuvent être activées pour une utilisation expérimentale avant leur mise en service.

Clé Exemple de valeur
AzureWebJobsFeatureFlags feature1,feature2,EnableProxies

Ajoutez EnableProxies à cette liste pour réactiver les proxys sur la version 4.x du runtime Functions pendant que vous planifiez votre migration vers Azure Gestion des API. Pour plus d’informations, consultez Réactiver les proxys dans Functions v4.x.

AzureWebJobsKubernetesSecretName

Indique la ressource Kubernetes Secrets utilisée pour le stockage des clés. Pris en charge uniquement lorsqu’il est exécuté dans Kubernetes. Ce paramètre vous oblige à définir AzureWebJobsSecretStorageType sur kubernetes. Lorsque AzureWebJobsKubernetesSecretName n’est pas défini, le référentiel est considéré comme étant en lecture seule. Dans ce cas, les valeurs doivent être générées avant le déploiement. Azure Functions Core Tools génère automatiquement les valeurs lors du déploiement sur Kubernetes.

Clé Exemple de valeur
AzureWebJobsKubernetesSecretName <SECRETS_RESOURCE>

Pour plus d’informations, consultez Dépôts de secrets.

AzureWebJobsSecretStorageKeyVaultClientId

ID client de l’identité managée affectée par l’utilisateur ou de l’inscription de l’application utilisée pour accéder au coffre où les clés sont stockées. Ce paramètre vous oblige à définir AzureWebJobsSecretStorageType sur keyvault. Pris en charge dans la version 4.x et les versions ultérieures du runtime Functions.

Clé Exemple de valeur
AzureWebJobsSecretStorageKeyVaultClientId <CLIENT_ID>

Pour plus d’informations, consultez Dépôts de secrets.

AzureWebJobsSecretStorageKeyVaultClientSecret

Secret de l’ID client de l’identité managée affectée par l’utilisateur ou de l’inscription de l’application utilisée pour accéder au coffre où les clés sont stockées. Ce paramètre vous oblige à définir AzureWebJobsSecretStorageType sur keyvault. Pris en charge dans la version 4.x et les versions ultérieures du runtime Functions.

Clé Exemple de valeur
AzureWebJobsSecretStorageKeyVaultClientSecret <CLIENT_SECRET>

Pour plus d’informations, consultez Dépôts de secrets.

AzureWebJobsSecretStorageKeyVaultName

Nom d’une instance de coffre de clés utilisée pour stocker des clés. Ce paramètre est pris en charge uniquement pour la version 3.x du runtime Functions. Pour la version 4.x, utilisez AzureWebJobsSecretStorageKeyVaultUri à la place. Ce paramètre vous oblige à définir AzureWebJobsSecretStorageType sur keyvault.

Le coffre doit avoir une stratégie d’accès correspondant à l’identité managée affectée par le système de la ressource d’hébergement. La stratégie d’accès doit accorder à l’identité les autorisations secrètes suivantes : Get, Set, List et Delete.
Lorsque vos fonctions s’exécutent localement, l’identité du développeur est utilisée et les paramètres doivent se trouver dans le fichier local.settings.json.

Clé Exemple de valeur
AzureWebJobsSecretStorageKeyVaultName <VAULT_NAME>

Pour plus d’informations, consultez Dépôts de secrets.

AzureWebJobsSecretStorageKeyVaultTenantId

ID de locataire de l’inscription d’application utilisée pour accéder au coffre où les clés sont stockées. Ce paramètre vous oblige à définir AzureWebJobsSecretStorageType sur keyvault. Pris en charge dans la version 4.x et les versions ultérieures du runtime Functions. Pour plus d’informations, consultez Dépôts de secrets.

Clé Exemple de valeur
AzureWebJobsSecretStorageKeyVaultTenantId <TENANT_ID>

AzureWebJobsSecretStorageKeyVaultUri

URI d’une instance de coffre de clés utilisée pour stocker des clés. Pris en charge dans la version 4.x et les versions ultérieures du runtime Functions. Il s’agit du paramètre recommandé pour l’utilisation d’une instance de coffre de clés destinée au stockage des clés. Ce paramètre vous oblige à définir AzureWebJobsSecretStorageType sur keyvault.

La valeur AzureWebJobsSecretStorageKeyVaultUri doit être la valeur complète de l’URI de coffre affiché sous l’onglet Vue d’ensemble de Key Vault, y compris https://.

Le coffre doit avoir une stratégie d’accès correspondant à l’identité managée affectée par le système de la ressource d’hébergement. La stratégie d’accès doit accorder à l’identité les autorisations secrètes suivantes : Get, Set, List et Delete.
Lorsque vos fonctions s’exécutent localement, l’identité du développeur est utilisée et les paramètres doivent se trouver dans le fichier local.settings.json.

Clé Exemple de valeur
AzureWebJobsSecretStorageKeyVaultUri https://<VAULT_NAME>.vault.azure.net

Pour en savoir plus, consultez Utiliser des références Key Vault pour Azure Functions.

AzureWebJobsSecretStorageSas

URL SAS du stockage d’objets blob pour un deuxième compte de stockage utilisé pour le stockage de clés. Par défaut, Functions utilise le compte défini dans AzureWebJobsStorage. Lorsque vous utilisez cette option de stockage de secrets, vérifiez que AzureWebJobsSecretStorageType n’est pas défini explicitement ou qu’il n’est pas défini sur blob. Pour plus d’informations, consultez Dépôts de secrets.

Clé Exemple de valeur
AzureWebJobsSecretStorageSas <BLOB_SAS_URL>

AzureWebJobsSecretStorageType

Spécifie le référentiel ou le fournisseur à utiliser pour le stockage de clés. Les clés sont toujours chiffrées avant d’être stockées à l’aide d’un secret unique pour votre application de fonction.

Clé Valeur Description
AzureWebJobsSecretStorageType blob Les clés sont stockées dans un conteneur de stockage Blob du compte fourni par le paramètre AzureWebJobsStorage. Le stockage d’objet blob est le comportement par défaut lorsque AzureWebJobsSecretStorageType n’est pas défini.
Pour spécifier un autre compte de stockage, utilisez le paramètre AzureWebJobsSecretStorageSas pour indiquer l’URL SAS d’un deuxième compte de stockage.
AzureWebJobsSecretStorageType files Les clés sont conservées dans le système de fichiers. Il s’agit du comportement par défaut pour Functions v1.x.
AzureWebJobsSecretStorageType keyvault Les clés sont stockées dans une instance de coffre de clés définie par AzureWebJobsSecretStorageKeyVaultName.
AzureWebJobsSecretStorageType kubernetes Pris en charge uniquement lors de l’exécution du runtime Functions dans Kubernetes. Lorsque AzureWebJobsKubernetesSecretName n’est pas défini, le référentiel est considéré comme étant en lecture seule. Dans ce cas, les valeurs doivent être générées avant le déploiement. Azure Functions Core Tools génère automatiquement les valeurs lors du déploiement sur Kubernetes.

Pour plus d’informations, consultez Dépôts de secrets.

AzureWebJobsStorage

Spécifie la chaîne de connexion d’un compte de Stockage Azure utilisé par le runtime Functions pour un fonctionnement normal. Ce compte de stockage est notamment utilisé par Functions pour la gestion des clés, la gestion des déclencheurs de minuterie et les points de contrôle Event Hubs. Le compte de stockage doit être à usage général. Il prend en charge les objets blob, les files d’attente et les tables. Pour plus d'informations, consultez Exigences relatives au compte de stockage.

Clé Exemple de valeur
AzureWebJobsStorage DefaultEndpointsProtocol=https;AccountName=...

Au lieu d’une chaîne de connexion, vous pouvez utiliser une connexion basée sur une identité pour ce compte de stockage. Pour plus d’informations, consultez Connexion à un stockage hôte avec une identité.

AzureWebJobsStorage__accountName

Lorsqu’une connexion de stockage basée sur l’identité est utilisée, définit le nom du compte de stockage au lieu d’utiliser la chaîne de connexion dans AzureWebJobsStorage. Cette syntaxe est unique à AzureWebJobsStorage et ne peut pas être utilisée pour d’autres connexions basées sur l’identité.

Clé Exemple de valeur
AzureWebJobsStorage__accountName <STORAGE_ACCOUNT_NAME>

Pour les clouds souverains ou lorsqu’un DNS personnalisé est utilisé, vous devez utiliser les paramètres AzureWebJobsStorage__*ServiceUri spécifiques au service.

AzureWebJobsStorage__blobServiceUri

Lorsqu’une connexion de stockage basée sur l’identité est utilisée, définit l’URI du plan de données du service blob du compte de stockage.

Clé Exemple de valeur
AzureWebJobsStorage__blobServiceUri https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net

Utilisez ce paramètre au lieu de AzureWebJobsStorage__accountName dans les clouds souverains ou lorsqu’un DNS personnalisé est utilisé. Pour plus d’informations, consultez Connexion à un stockage hôte avec une identité.

AzureWebJobsStorage__queueServiceUri

Lorsqu’une connexion de stockage basée sur l’identité est utilisée, définit l’URI du plan de données du service de file d’attente du compte de stockage.

Clé Exemple de valeur
AzureWebJobsStorage__queueServiceUri https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net

Utilisez ce paramètre au lieu de AzureWebJobsStorage__accountName dans les clouds souverains ou lorsqu’un DNS personnalisé est utilisé. Pour plus d’informations, consultez Connexion à un stockage hôte avec une identité.

AzureWebJobsStorage__tableServiceUri

Lorsqu’une connexion de stockage basée sur l’identité est utilisée, définit l’URI du plan de données du service de table du compte de stockage.

Clé Exemple de valeur
AzureWebJobsStorage__tableServiceUri https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net

Utilisez ce paramètre au lieu de AzureWebJobsStorage__accountName dans les clouds souverains ou lorsqu’un DNS personnalisé est utilisé. Pour plus d’informations, consultez Connexion à un stockage hôte avec une identité.

AzureWebJobs_TypeScriptPath

Chemin d’accès au compilateur utilisé pour TypeScript. Vous permet d’écraser la valeur par défaut au besoin.

Clé Exemple de valeur
AzureWebJobs_TypeScriptPath %HOME%\typescript

DOCKER_REGISTRY_SERVER_PASSWORD

Indique le mot de passe utilisé pour accéder à un registre de conteneurs privé. Ce paramètre n’est nécessaire que lors du déploiement de votre application de fonction conteneurisée à partir d’un registre de conteneurs privé. Pour en savoir plus, consultez Variables d’environnement et paramètres d’application dans Azure App Service.

DOCKER_REGISTRY_SERVER_URL

Indique l’URL d’un registre de conteneurs privé. Ce paramètre n’est nécessaire que lors du déploiement de votre application de fonction conteneurisée à partir d’un registre de conteneurs privé. Pour en savoir plus, consultez Variables d’environnement et paramètres d’application dans Azure App Service.

DOCKER_REGISTRY_SERVER_USERNAME

Indique le compte utilisé pour accéder à un registre de conteneurs privé. Ce paramètre n’est nécessaire que lors du déploiement de votre application de fonction conteneurisée à partir d’un registre de conteneurs privé. Pour en savoir plus, consultez Variables d’environnement et paramètres d’application dans Azure App Service.

DOCKER_SHM_SIZE

Définit la taille de la mémoire partagée (en octets) lorsque le Worker Python utilise la mémoire partagée. Pour plus d’informations, consultez Mémoire partagée.

Clé Exemple de valeur
DOCKER_SHM_SIZE 268435456

La valeur ci-dessus définit une taille de mémoire partagée de ~ 256 Mo.

Exige que FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED soit défini sur 1.

ENABLE_ORYX_BUILD

Indique si le Système de build Oryx est utilisé pendant le déploiement. ENABLE_ORYX_BUILD doit être défini sur true lorsque vous effectuez des déploiements de build à distance sur Linux. Pour en savoir plus, consultez Build à distance.

Clé Exemple de valeur
ENABLE_ORYX_BUILD true

FUNCTION_APP_EDIT_MODE

Indique si vous êtes en mesure de modifier votre application de fonction dans le portail Azure. Les valeurs valides sont readwrite et readonly.

Clé Exemple de valeur
FUNCTION_APP_EDIT_MODE readonly

La valeur est définie par le runtime en fonction de la pile de langages et de l’état de déploiement de votre application de fonction. Pour plus d’informations, consultez Contraintes de développement dans le portail Azure.

FUNCTIONS_EXTENSION_VERSION

Version du runtime Functions qui héberge votre application de fonction. Un tilde (~) suivi d’une version principale signifie que la version la plus récente de cette version principale est utilisée (par exemple, ~3). Lorsque de nouvelles versions sont disponibles pour une même version principale, elles sont automatiquement installées dans l’application de fonction. Pour épingler l’application à une version spécifique, utilisez le numéro de version complet (par exemple, 3.0.12345). La valeur par défaut est ~3. La valeur ~1 épingle votre application à la version 1.x du runtime. Pour plus d’informations, consultez Vue d’ensemble des versions du runtime Azure Functions. La valeur ~4 indique que votre application s’exécute sur la version 4.x du runtime.

Clé Exemple de valeur
FUNCTIONS_EXTENSION_VERSION ~4

Les valeurs des versions majeures du runtime suivantes sont prises en charge :

Valeur Cible du runtime Commentaire
~4 4.x Recommandé
~3 3.x Plus pris en charge
~2 2.x Plus pris en charge
~1 1.x Le support prend fin le 14 septembre 2026

FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR

Ce paramètre d’application est un moyen temporaire pour les applications Node.js d’activer un changement cassant qui facilite la résolution des erreurs de point d’entrée sur Node.js version 18 ou inférieure. Il est vivement recommandé d’utiliser true, en particulier pour la programmation d’applications de modèle v4, qui utilisent toujours des fichiers de point d’entrée. Le comportement sans le changement cassant (false) ignore les erreurs de point d’entrée et ne les enregistre pas dans Application Insights.

À compter de Node.js v20, le paramètre d’application n’a aucun effet et le comportement de changement cassant est toujours activé.

Pour Node.js v18 ou version inférieur, le paramètre d’application peut être utilisé et le comportement par défaut dépend du moment où l’erreur se produit, avant ou après l’inscription d’une fonction de modèle v4 :

  • Si l’erreur est levée avant (par exemple si vous utilisez un modèle v3 ou si votre fichier de point d’entrée n’existe pas), le comportement par défaut correspond à false.
  • Si l’erreur est levée après (par exemple si vous essayez d’inscrire des fonctions de modèle v4 en double), le comportement par défaut correspond à true.
Clé Valeur Description
FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR true Bloquez les erreurs de point d’entrée et journalisez-les dans Application Insights.
FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR false Ignorez les erreurs de point d’entrée et ne les journalisez pas dans Application Insights.

FUNCTIONS_V2_COMPATIBILITY_MODE

Important

Ce paramètre n’est plus pris en charge. Initialement, il a été fourni pour mettre à disposition une alternative à court terme pour que les applications qui ciblaient le runtime v2.x puissent s’exécuter sur le runtime v3.x lorsqu’il était encore pris en charge. À l’exception des applications héritées qui s’exécutent sur la version 1.x, toutes les applications de fonction doivent s’exécuter sur la version 4.x du runtime Functions : FUNCTIONS_EXTENSION_VERSION=~4. Pour plus d’informations, consultez Vue d’ensemble des versions du runtime Azure Functions.

FUNCTIONS_REQUEST_BODY_SIZE_LIMIT

Remplace la limite par défaut de la taille du corps des requêtes envoyées aux points de terminaison HTTP. La valeur est donnée en octets, avec une taille de requête maximale par défaut de 104857600 octets.

Clé Exemple de valeur
FUNCTIONS_REQUEST_BODY_SIZE_LIMIT 250000000

FUNCTIONS_WORKER_PROCESS_COUNT

Spécifie le nombre maximal de processus de traitement de langue, avec la valeur 1 par défaut. La valeur maximale autorisée est 10. Les appels de fonction sont répartis uniformément entre les processus de travail de langage. Les processus Worker de langage sont générés toutes les 10 secondes jusqu’à ce que le nombre défini par FUNCTIONS_WORKER_PROCESS_COUNT soit atteint. L’utilisation de plusieurs processus Worker de langage n’a pas le même effet qu’une mise à l’échelle. Envisagez d’utiliser ce paramètre lorsque votre charge de travail a une combinaison d’appels liés à l’UC et aux E/S. Ce paramètre s’applique à tous les runtimes de langage, à l’exception de .NET qui est exécuté pendant le processus (FUNCTIONS_WORKER_RUNTIME=dotnet).

Clé Exemple de valeur
FUNCTIONS_WORKER_PROCESS_COUNT 2

FUNCTIONS_WORKER_RUNTIME

Langage ou pile de langages du runtime Worker à charger dans l’application de fonction. Correspond au langage utilisé dans votre application (par exemple, python). Depuis la version 2.x du runtime Azure Functions, une application de fonction donnée ne peut prendre en charge qu’un seul langage.

Clé Exemple de valeur
FUNCTIONS_WORKER_RUNTIME node

Valeurs valides :

Valeur Langage/Pile de langages
dotnet C# (bibliothèque de classes)
C# (script)
dotnet-isolated C# (processus Worker isolé)
java Java
node JavaScript
TypeScript
powershell PowerShell
python Python
custom Autres

FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED

Ce paramètre permet au Worker Python d’utiliser la mémoire partagée pour améliorer le débit. Activez la mémoire partagée lorsque votre application de fonction Python atteint des goulots d’étranglement de mémoire.

Clé Exemple de valeur
FUNCTIONS_WORKER_SHARED_MEMORY_DATA_TRANSFER_ENABLED 1

Lorsque ce paramètre est activé, vous pouvez utiliser le paramètre DOCKER_SHM_SIZE pour définir la taille de la mémoire partagée. Pour plus d’informations, consultez Mémoire partagée.

JAVA_OPTS

Permet de personnaliser la machine virtuelle Java (JVM) utilisée pour exécuter vos fonctions Java lors de l’exécution sur un Plan Premium ou un Plan dédié. Lors de l’exécution sur un plan Consommation, utilisez languageWorkers__java__arguments à la place. Pour plus d’informations, consultez Personnaliser JVM.

languageWorkers__java__arguments

Permet de personnaliser la machine virtuelle Java (JVM) utilisée pour exécuter vos fonctions Java lors de l’exécution sur un Plan Consommation. Ce paramètre augmente les temps de démarrage à froid pour les fonctions Java exécutées dans un plan Consommation. Pour un plan Premium ou Dédié, utilisez JAVA_OPTS à la place. Pour plus d’informations, consultez Personnaliser JVM.

MDMaxBackgroundUpgradePeriod

Contrôle la période de mise à jour en arrière-plan des dépendances gérées pour les applications de fonction PowerShell, avec une valeur par défaut de 7.00:00:00 (hebdomadaire).

Chaque rôle de travail PowerShell lance la vérification des mises à niveau de module dans PowerShell Gallery au démarrage du processus et à chaque MDMaxBackgroundUpgradePeriod par la suite. Quand une nouvelle version de module est disponible dans PowerShell Gallery, elle est installée dans le système de fichiers et mise à la disposition des rôles de travail PowerShell. Diminuer cette valeur permet à votre application de fonction d’obtenir plus rapidement les versions de module les plus récentes, mais cela augmente aussi l’utilisation des ressources d’application (E/S réseau, processeur, stockage). Augmenter cette valeur permet de diminuer l’utilisation des ressources d’application, mais retarde aussi la remise des nouvelles versions de module à votre application.

Clé Exemple de valeur
MDMaxBackgroundUpgradePeriod 7.00:00:00

Pour plus d’informations, consultez Gestion des dépendances.

MDNewSnapshotCheckPeriod

Spécifie la fréquence à laquelle chaque rôle de travail PowerShell vérifie si les mises à niveau des dépendances gérées ont été installées. La fréquence par défaut est de 01:00:00 (toutes les heures).

Lorsque les nouvelles versions de module sont installées dans le système de fichiers, chaque rôle de travail PowerShell doit être redémarré. Le redémarrage des rôles de travail PowerShell affecte la disponibilité de votre application, car il peut interrompre l’exécution de la fonction actuelle. Tant que tous les processus Worker PowerShell n’ont pas redémarré, les appels de fonction peuvent utiliser les anciennes ou nouvelles versions du module. Le redémarrage de tous les rôles de travail PowerShell se termine pendant la période MDNewSnapshotCheckPeriod.

Au cours de chaque MDNewSnapshotCheckPeriod, le rôle de travail PowerShell vérifie si les mises à niveau des dépendances gérées ont été installées ou non. Une fois les mises à niveau installées, un redémarrage est initié. Si vous augmentez cette valeur, vous réduisez la fréquence des interruptions dues aux redémarrages. Toutefois, cette augmentation peut également accroître le temps pendant lequel les appels de fonction peuvent utiliser l’ancienne ou la nouvelle version de module, de manière non déterministe.

Clé Exemple de valeur
MDNewSnapshotCheckPeriod 01:00:00

Pour plus d’informations, consultez Gestion des dépendances.

MDMinBackgroundUpgradePeriod

Période qui doit suivre une vérification de mise à niveau des dépendances gérées avant qu’une autre vérification de mise à niveau ne soit lancée, avec 1.00:00:00 comme valeur par défaut (quotidienne).

Pour éviter des mises à niveau de module excessives lors des fréquents redémarrages des rôles de travail, la vérification des mises à niveau de module n’est pas effectuée si un rôle de travail l’a déjà lancée pendant la dernière période MDMinBackgroundUpgradePeriod.

Clé Exemple de valeur
MDMinBackgroundUpgradePeriod 1.00:00:00

Pour plus d’informations, consultez Gestion des dépendances.

PIP_INDEX_URL

Ce paramètre vous permet de remplacer l’URL de base de l’index Python Package qui est https://pypi.org/simple par défaut. Utilisez ce paramètre lorsque vous devez exécuter une build distante à l’aide de dépendances personnalisées. Ces dépendances personnalisées peuvent se trouver dans un référentiel d’index de package conforme à PEP 503 (l’API de référentiel simple) ou dans un répertoire local qui suit le même format.

Clé Exemple de valeur
PIP_INDEX_URL http://my.custom.package.repo/simple

Pour en savoir plus, consultez la documentation pip pour --index-url et reportez-vous aux Dépendances personnalisées dans les informations de référence pour les développeurs Python.

PIP_EXTRA_INDEX_URL

La valeur de ce paramètre indique une URL d’index supplémentaire pour les packages personnalisés pour les applications Python, à utiliser en plus de --index-url. Utilisez ce paramètre lorsque vous devez exécuter une build distante à l’aide de dépendances personnalisées se trouvant dans un index de packages supplémentaire. Doit suivre les mêmes règles que --index-url.

Clé Exemple de valeur
PIP_EXTRA_INDEX_URL http://my.custom.package.repo/simple

Pour en savoir plus, consultez la documentation pip pour --extra-index-url et Dépendances personnalisées dans les informations de référence pour les développeurs Python.

PROJET

Paramètre de déploiement continu qui indique au service de déploiement Kudu le dossier d’un référentiel connecté pour l’emplacement du projet déployable.

Clé Exemple de valeur
PROJET WebProject/WebProject.csproj

PYTHON_ISOLATE_WORKER_DEPENDENCIES

La configuration est spécifique aux applications de fonction Python. Elle définit la priorité de l’ordre de chargement des modules. par défaut, cette valeur est définie sur 0.

Clé Valeur Description
PYTHON_ISOLATE_WORKER_DEPENDENCIES 0 Donne la priorité au chargement des bibliothèques Python provenant des dépendances internes du Worker Python, ce qui correspond au comportement par défaut. Les bibliothèques tierces définies dans requirements.txt peuvent être mises en mémoire fantôme.
PYTHON_ISOLATE_WORKER_DEPENDENCIES 1 Donne la priorité au chargement des bibliothèques Python provenant du package d’application défini dans requirements.txt. Cela empêche vos bibliothèques d’entrer en conflit avec les bibliothèques internes du Worker Python.

PYTHON_ENABLE_DEBUG_LOGGING

Active la journalisation de niveau de débogage dans une application de fonction Python. La valeur 1 active la journalisation de niveau de débogage. Sans ce paramètre ou avec la valeur 0, seules les informations et les journaux de niveau supérieur sont envoyés du Worker Python à l’hôte Functions. Utilisez ce paramètre dans le cadre du débogage ou du traçage de vos exécutions de fonction Python.

Dans le cadre du débogage de fonctions Python, veillez à définir également un niveau de journalisation de débogage ou de traçage dans le fichier host.json, si nécessaire. Pour plus d’informations, consultez Comment configurer la surveillance de Azure Functions.

PYTHON_ENABLE_WORKER_EXTENSIONS

La configuration est spécifique aux applications de fonction Python. Définir cette valeur sur 1 permet au Worker de charger les 1 définies dans requirements.txt. Cela permet à votre application de fonction d’accéder aux nouvelles fonctionnalités fournies par des packages tiers. Cela peut également modifier le comportement de chargement et d’appel des fonctions dans votre application. Vérifiez que l’extension que vous choisissez est digne de confiance, car vous êtes responsable des risques associés à son utilisation. Azure Functions n’accorde aucune garantie expresse aux extensions. Pour plus d’informations sur l’utilisation d’une extension, consultez la page du manuel ou le document Lisez-moi de l’extension. Par défaut, cette valeur est définie sur 0.

Clé Valeur Description
PYTHON_ENABLE_WORKER_EXTENSIONS 0 Désactive toutes les extensions de Worker Python.
PYTHON_ENABLE_WORKER_EXTENSIONS 1 Autorise le Worker Python à charger des extensions à partir de requirements.txt.

PYTHON_THREADPOOL_THREAD_COUNT

Spécifie le nombre maximal de threads qu’un processus de travail du langage Python utiliserait pour exécuter des appels de fonction. La valeur par défaut est 1 pour la version 3.8 et les versions antérieures de Python. Dans la version 3.9 et les versions ultérieures de Python, elle est définie sur None. Ce paramètre ne garantit pas le nombre de threads qui seront définis pendant les exécutions. Il permet à Python d’étendre le nombre de threads jusqu’à la valeur spécifiée. Il ne s’applique qu’aux applications de fonction Python. En outre, il concerne l’appel de fonctions synchrones et non les coroutines.

Clé Exemple de valeur Valeur maximale
PYTHON_THREADPOOL_THREAD_COUNT 2 32

SCALE_CONTROLLER_LOGGING_ENABLED

Ce paramètre est actuellement en préversion.

Ce paramètre contrôle la journalisation à partir du contrôleur d’échelle Azure Functions. Pour plus d’informations, consultez Journaux du contrôleur d’échelle.

Clé Exemple de valeur
SCALE_CONTROLLER_LOGGING_ENABLED AppInsights:Verbose

La valeur de cette clé est fournie au format <DESTINATION>:<VERBOSITY>, qui est défini comme suit :

Propriété Description
<DESTINATION> Destination à laquelle les journaux sont envoyés. Les valeurs valides sont AppInsights et Blob.
Quand vous utilisez AppInsights, assurez-vous qu’Application Insights est activé dans votre application de fonction.
Quand vous affectez Blob comme destination, les journaux sont créés dans un conteneur d’objets blob nommé azure-functions-scale-controller dans le compte de stockage par défaut défini dans le paramètre d’application AzureWebJobsStorage.
<VERBOSITY> Spécifie le niveau de journalisation. Les valeurs prises en charge sont None, Warning et Verbose.
Quand il est défini sur Verbose, le contrôleur de mise à l’échelle enregistre une raison pour chaque modification du nombre de Workers, et des informations sur les déclencheurs pris en compte dans ces décisions. Les journaux détaillés incluent les avertissements de déclencheur et les hachages utilisés par les déclencheurs avant et après l’exécution du contrôleur de mise à l’échelle.

Conseil

Gardez à l’esprit que, lorsque vous laissez l’option de journalisation du contrôleur de mise à l’échelle activée, cela a un impact sur les coûts potentiels de surveillance de votre application de fonction. Envisagez d’activer la journalisation jusqu’à ce que vous ayez collecté suffisamment de données pour comprendre le comportement du contrôleur de mise à l’échelle, puis de la désactiver.

SCM_DO_BUILD_DURING_DEPLOYMENT

Contrôle le comportement de génération à distance pendant le déploiement. Lorsque SCM_DO_BUILD_DURING_DEPLOYMENT est défini sur true, le projet est généré à distance pendant le déploiement.

Clé Exemple de valeur
SCM_DO_BUILD_DURING_DEPLOYMENT true

SCM_LOGSTREAM_TIMEOUT

Contrôle le délai d’attente, en secondes, lors de la connexion aux journaux de streaming. La valeur par défaut est 7 200 (2 heures).

Clé Exemple de valeur
SCM_LOGSTREAM_TIMEOUT 1800

L’exemple de valeur 1800 ci-dessus définit un délai d’attente de 30 minutes. Pour plus d’informations, consultez Activer les journaux d’exécution de streaming dans Azure Functions.

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING

Chaîne de connexion du compte de stockage dans lequel la configuration et le code de l’application de fonction sont stockés dans les plans de mise à l’échelle pilotés par les événements. Pour plus d’informations, consultez Paramètre de connexion de compte de stockage.

Clé Exemple de valeur
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING DefaultEndpointsProtocol=https;AccountName=...

Ce paramètre est nécessaire pour les applications des plans Consommation et Elastic Premium qui s’exécutent sur Windows et Linux. Il n’est pas nécessaire pour les applications Plan dédié, qui ne sont pas mises à l’échelle dynamiquement par Functions.

La modification ou la suppression de ce paramètre peut empêcher le démarrage de votre application de fonction. Pour plus d’informations, consultez cet article de résolution des problèmes.

Azure Files ne prend pas en charge l’utilisation de l’identité managée lors de l’accès au partage de fichiers. Pour plus d’informations, consultez Scénarios d’authentification Azure Files pris en charge.

WEBSITE_CONTENTOVERVNET

La valeur 1 permet à votre application de fonction de se mettre à l’échelle lorsque votre compte de stockage est limité à un réseau virtuel. Vous devez activer ce paramètre lorsque vous limitez votre compte de stockage à un réseau virtuel. Obligatoire uniquement lorsque WEBSITE_CONTENTAZUREFILECONNECTIONSTRING est utilisé. Pour en savoir plus, consultez Restreindre votre compte de stockage à un réseau virtuel.

Clé Exemple de valeur
WEBSITE_CONTENTOVERVNET 1

Prise en charge sur les plans Premium et Dedicated (App Service) [Standard et supérieur]. Non pris en charge lors de l’exécution sur un plan Consommation.

WEBSITE_CONTENTSHARE

Nom du partage de fichiers que Functions utilise pour stocker le code et les fichiers de configuration de l’application de fonction. Ce contenu est requis par les plans de mise à l’échelle basée sur les événements. Utilisé avec WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. La valeur par défaut est une chaîne unique générée par le runtime qui commence par le nom de l’application de fonction. Pour plus d’informations, consultez Paramètre de connexion de compte de stockage.

Clé Exemple de valeur
WEBSITE_CONTENTSHARE functionapp091999e2

Ce paramètre est nécessaire pour les applications des plans Consommation et Premium sur Windows et Linux. Il n’est pas nécessaire pour les applications Plan dédié, qui ne sont pas mises à l’échelle dynamiquement par Functions.

Le partage est créé lors de la création de votre application de fonction. La modification ou la suppression de ce paramètre peut empêcher le démarrage de votre application de fonction. Pour plus d’informations, consultez cet article de résolution des problèmes.

Les considérations suivantes s’appliquent lors de l’utilisation d’un modèle Azure Resource Manager (ARM) ou d’un fichier Bicep pour créer une application de fonction pendant le déploiement :

  • Lorsque vous ne définissez pas de valeur WEBSITE_CONTENTSHARE pour l’application de fonction principale ou les applications dans les emplacements, des valeurs de partage uniques sont générées pour vous. L’absence de définition de WEBSITE_CONTENTSHAREest l’approche recommandée pour un déploiement de modèle ARM.
  • Il existe des scénarios dans lesquels vous devez sélectionner une valeur prédéfinie pour WEBSITE_CONTENTSHARE, par exemple lorsque vous utilisez un compte de stockage sécurisé dans un réseau virtuel. Dans ce cas, vous devez définir un nom de partage unique pour l’application de fonction principale et l’application pour chaque emplacement de déploiement. Dans le cas d’un compte de stockage sécurisé par un réseau virtuel, vous devez également créer le partage lui-même dans le cadre de votre déploiement automatisé. Pour plus d’informations, consultez Déploiements sécurisés.
  • Ne définissez pas WEBSITE_CONTENTSHARE comme paramètre d'emplacement.
  • Lorsque vous spécifiez WEBSITE_CONTENTSHARE, la valeur doit suivre ces instructions pour les noms de partage.

WEBSITE_DNS_SERVER

Définit le serveur DNS qu’une application utilise lors de la résolution d’adresses IP. Ce paramètre est souvent requis lors de l’utilisation de certaines fonctionnalités de mise en réseau, telles que des zones privées Azure DNS et des points de terminaison privés.

Clé Exemple de valeur
WEBSITE_DNS_SERVER 168.63.129.16

WEBSITE_ENABLE_BROTLI_ENCODING

Contrôle si l’encodage Brotli est utilisé pour la compression au lieu de la compression gzip par défaut. Lorsque WEBSITE_ENABLE_BROTLI_ENCODING est défini sur 1, l’encodage Brotli est utilisé ; sinon, c’est l’encodage gzip qui est utilisé.

WEBSITE_FUNCTIONS_ARMCACHE_ENABLED

Désactive la mise en cache lors du déploiement d’applications de fonction à l’aide de modèles Azure Resource Manager (ARM).

Clé Exemple de valeur
WEBSITE_FUNCTIONS_ARMCACHE_ENABLED 0

WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT

Nombre maximal d’instances possibles vers lesquelles l’application peut effectuer un scale-out. Par défaut, il n’y pas de limite.

Important

Ce paramètre est en préversion. Une propriété d’application pour un scale-out maximal a été ajoutée et constitue la méthode recommandée pour limiter le scale-out.

Clé Exemple de valeur
WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT 5

WEBSITE_NODE_DEFAULT_VERSION

Windows uniquement. Définit la version de Node.js à utiliser lors de l’exécution de votre application de fonction sur Windows. Vous devez utiliser un tilde (~) pour que le runtime utilise la dernière version disponible de la version principale ciblée. Par exemple, lorsqu’il est défini sur ~18, la dernière version de Node.js 18 est utilisée. Quand une version majeure est ciblée avec un tilde, vous n’avez pas besoin de mettre à jour manuellement la version mineure.

Clé Exemple de valeur
WEBSITE_NODE_DEFAULT_VERSION ~18

WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS

Lors de l’exécution d’un échange d’emplacement sur une application de fonction s’exécutant sur un plan Premium, l’échange peut échouer lorsque le compte de stockage dédié utilisé par l’application est limité en termes de réseau. Cette défaillance est due à une fonctionnalité de journalisation d’application héritée, partagée à la fois par Functions et App Service. Ce paramètre remplace cette fonctionnalité de journalisation héritée et permet l’échange.

Clé Exemple de valeur
WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS 0

Ajoutez à WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS une valeur de 0 pour tous les emplacements pour vous assurer que les paramètres de diagnostic hérités ne bloquent pas vos échanges. Vous pouvez également ajouter ce paramètre et cette valeur à l’emplacement de production en tant que paramètre d’emplacement de déploiement (sticky).

WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS

Par défaut, les paramètres de version des applications de fonction sont spécifiques à chaque emplacement. Ce paramètre est utilisé lors de la mise à niveau de fonctions à l’aide d’emplacements de déploiement. Cela permet d’éviter un comportement inattendu en raison d’un changement de versions suite à une permutation. Définissez sur 0 en production et dans l’emplacement pour vous assurer que tous les paramètres de version sont également permutés. Pour plus d’informations, consultez Mettre à niveau à l’aide d’emplacements.

Clé Exemple de valeur
WEBSITE_OVERRIDE_STICKY_EXTENSION_VERSIONS 0

WEBSITE_RUN_FROM_PACKAGE

Permet à votre application de fonction de s’exécuter à partir d’un fichier de package, qui peut être monté localement ou déployé vers une URL externe.

Clé Exemple de valeur
WEBSITE_RUN_FROM_PACKAGE 1

Les valeurs valides sont soit une URL qui renvoie à l’emplacement d’un fichier de package de déploiement externe, soit 1. Lorsque la valeur 1 est définie, le package doit se trouver dans le dossier d:\home\data\SitePackages. Lorsque vous utilisez le déploiement zip avec WEBSITE_RUN_FROM_PACKAGE activé, le package est automatiquement chargé vers cet emplacement. Dans la préversion, ce paramètre s’appelait WEBSITE_RUN_FROM_ZIP. Pour plus d’informations, consultez Exécuter des fonctions Azure à partir d’un fichier de package.

Lorsque vous déployez à partir d’une URL de package externe, vous devez également synchroniser manuellement les déclencheurs. Pour plus d’informations, consultez Synchronisation des déclencheurs.

WEBSITE_SKIP_CONTENTSHARE_VALIDATION

Les paramètres WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE ont des contrôles de validation supplémentaires pour garantir le démarrage correct de l’application. La création des paramètres d’application échoue si l’application de fonction ne peut pas appeler correctement le compte de stockage en aval ou Key Vault en raison de contraintes de mise en réseau ou d’autres facteurs de limitation. Lorsque WEBSITE_SKIP_CONTENTSHARE_VALIDATION est défini sur 1, le contrôle de validation est ignoré ; sinon, la valeur par défaut est 0 et la validation est effectuée.

Clé Exemple de valeur
WEBSITE_SKIP_CONTENTSHARE_VALIDATION 1

Si la validation est ignorée et que la chaîne de connexion ou le partage de contenu ne sont pas valides, l’application ne peut pas démarrer correctement. Dans ce cas, les fonctions retournent les erreurs HTTP 500. Pour plus d’informations, voir Résoudre l’erreur : « Le runtime d’Azure Functions est inaccessible »

WEBSITE_SLOT_NAME

Lecture seule. Nom de l’emplacement de déploiement actuel. Le nom de l’emplacement de production est Production.

Clé Exemple de valeur
WEBSITE_SLOT_NAME Production

WEBSITE_TIME_ZONE

Vous permet de définir le fuseau horaire de votre application de fonction.

Clé Système d''exploitation Exemple de valeur
WEBSITE_TIME_ZONE Windows Eastern Standard Time
WEBSITE_TIME_ZONE Linux America/New_York

Le fuseau horaire par défaut utilisé avec les expressions CRON est le Temps universel coordonné (UTC). Pour baser votre expression CRON sur un autre fuseau horaire, créez un paramètre d’application nommé WEBSITE_TIME_ZONE pour votre application de fonction.

La valeur de ce paramètre dépend du système d’exploitation et du plan sur lequel l’application de fonction s’exécute.

Système d’exploitation Plan Valeur
Windows Tous Définissez la valeur sur le nom du fuseau horaire souhaité comme indiqué par la deuxième ligne de chaque paire donnée par la commande Windows tzutil.exe /L
Linux Premium
Dédié		 Définissez la valeur sur le nom du fuseau horaire souhaité comme indiqué dans la base de données tz.

Remarque

WEBSITE_TIME_ZONE et TZ ne sont actuellement pas pris en charge lors de l’exécution sur Linux dans un plan Consommation. Dans ce cas, la définition de WEBSITE_TIME_ZONE ou de TZ peut créer des problèmes liés au protocole SSL et entraîner l’arrêt du fonctionnement des métriques pour votre application.

Par exemple, l’heure de la côte est des États-Unis (représentée par Eastern Standard Time (Windows) ou America/New_York (Linux)) utilise actuellement l’heure UTC (temps universel coordonné) 05:00 pendant l’heure standard et l’heure UTC 04:00 pendant l’heure d’été. Pour qu’un déclencheur de minuteur s’active à 10:00 (heure de la côte est) chaque jour, créez un paramètre d’application nommé WEBSITE_TIME_ZONE pour votre application de fonction, définissez la valeur sur Eastern Standard Time (Windows) ou sur America/New_York (Linux), puis utilisez l’expression NCRONTAB suivante :

"0 0 10 * * *"

Quand vous utilisez WEBSITE_TIME_ZONE, l’heure est ajustée en fonction des changements d’heure du fuseau horaire spécifique, notamment pour tenir compte de l’heure d’été et des changements de l’heure standard.

WEBSITE_USE_PLACEHOLDER

Indique s’il faut utiliser une optimisation de démarrage à froid spécifique lors de l’exécution du plan Consommation. Définissez sur 0 pour désactiver l’optimisation du démarrage à froid sur le plan Consommation.

Clé Exemple de valeur
WEBSITE_USE_PLACEHOLDER 1

WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED

Indique s’il faut utiliser une optimisation de démarrage à froid spécifique lors de l’exécution des fonctions du processus Worker isolé .NET sur le plan Consommation. Définissez sur 0 pour désactiver l’optimisation du démarrage à froid sur le plan Consommation.

Clé Exemple de valeur
WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED 1

WEBSITE_VNET_ROUTE_ALL

Important

WEBSITE_VNET_ROUTE_ALL est un paramètre d’application hérité qui a été remplacé par le paramètre de site vnetRouteAllEnabled.

Indique si tout le trafic sortant de l’application est routé via le réseau virtuel. La valeur de paramètre 1 indique que tout le trafic est acheminé via le réseau virtuel. Vous avez besoin de ce paramètre lorsque vous utilisez des fonctionnalités de l’intégration du réseau virtuel régional. Il est également utilisé quand une passerelle NAT de réseau virtuel est utilisée pour définir une adresse IP sortante statique.

Clé Exemple de valeur
WEBSITE_VNET_ROUTE_ALL 1

WEBSITES_ENABLE_APP_SERVICE_STORAGE

Indique si le répertoire /home est partagé entre les instances mises à l’échelle, avec true pour valeur par défaut. Vous devez définir cette valeur sur false lors du déploiement de votre application de fonction dans un conteneur. j

Paramètres de site App Service

Certaines configurations doivent être conservées au niveau d’App Service en tant que paramètres de site, comme les versions des langages. Ces paramètres sont gérés dans le portail, à l’aide des API REST, ou en utilisant Azure CLI ou Azure PowerShell. Voici les paramètres de site qui peuvent être nécessaires, en fonction du langage, du système d’exploitation et des versions du runtime :

alwaysOn

Sur une application de fonction s’exécutant dans un plan (App Service) Dedicated, le runtime de fonctions est inactif après quelques minutes d’inactivité. À ce moment, uniquement les requêtes vers un déclencheur HTTP réveille vos fonctions. Pour vous assurer que vos fonctions déclenchées non HTTP s’exécutent correctement, y compris le déclencheur du minuteur, activez AlwaysOn pour l’application de fonction en définissant le paramètre de site alwaysOn sur la valeur true.

linuxFxVersion

Pour les applications de fonction s’exécutant sur Linux, linuxFxVersion indique le langage et la version du processus de travail spécifique au langage. Ces informations sont utilisées avec FUNCTIONS_EXTENSION_VERSION pour déterminer quelle image conteneur Linux spécifique est installée pour exécuter votre application de fonction. Ce paramètre peut être défini sur une valeur prédéfinie ou sur un URI d’image personnalisée.

Cette valeur est définie pour vous quand vous créez votre application de fonction Linux. Il peut être nécessaire de la définir pour les déploiements de modèle ARM et de Bicep, et dans certains scénarios de mise à niveau.

Valeurs valides de linuxFxVersion

Vous pouvez utiliser la commande Azure CLI suivante pour voir un tableau des valeurs actuelles de linuxFxVersion par version du runtime Functions prise en charge :

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

La commande précédente nécessite d’effectuer une mise à niveau vers la version 2.40 d’Azure CLI.

Images personnalisées

Quand vous créez et gérez votre propre conteneur Linux personnalisé pour votre application de fonction, la valeur de linuxFxVersion est plutôt au format DOCKER|<IMAGE_URI>, comme dans l’exemple suivant :

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

Cela indique la source du Registre du conteneur déployé. Pour plus d’informations, consultez Utilisation des conteneurs et d’Azure Functions.

Important

Quand vous créez vos propres conteneurs, vous devez conserver l’image de base de votre conteneur mise à jour vers la dernière image de base prise en charge. Les images de base prises en charge pour Azure Functions sont spécifiques au langage et se trouvent dans le référentiel d’images de base Azure Functions.

L’équipe Functions s’engage à publier des mises à jour mensuelles pour ces images de base. Les mises à jour régulières incluent les dernières mises à jour de version mineure et les correctifs de sécurité pour le runtime et les langages Functions. Vous devez régulièrement mettre à jour votre conteneur à partir de la dernière image de base, puis redéployer la version mise à jour de votre conteneur.

netFrameworkVersion

Définit la version spécifique de .NET pour les fonctions C#. Pour plus d’informations, consultez Mettre à jour votre application de fonction dans Azure.

powerShellVersion

Définit la version spécifique de PowerShell sur laquelle vos fonctions s’exécutent. Pour plus d’informations, consultez Modification de la version de PowerShell.

Lors d’une exécution locale, vous utilisez à la place le paramètre FUNCTIONS_WORKER_RUNTIME_VERSION dans le fichier local.settings.json.

vnetrouteallenabled

Indique si tout le trafic sortant de l’application est routé via le réseau virtuel. La valeur de paramètre 1 indique que tout le trafic est acheminé via le réseau virtuel. Vous avez besoin de ce paramètre lorsque vous utilisez des fonctionnalités de l’intégration du réseau virtuel régional. Il est également utilisé quand une passerelle NAT de réseau virtuel est utilisée pour définir une adresse IP sortante statique. Pour plus d’informations, consultez Configurer le routage des applications.

Ce paramètre de site remplace le paramètre de WEBSITE_VNET_ROUTE_ALL hérité.

Étapes suivantes

Découvrez comment mettre à jour les paramètres d’application

Consultez les paramètres de configuration dans le fichier host.json

Consultez les autres paramètres des applications App Service