Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsque vous créez une instance d’application de fonction dans Azure, vous devez fournir l’accès à un compte stockage Azure par défaut. Le diagramme et le tableau suivants détaillent la façon dont Azure Functions utilise des services dans le compte de stockage par défaut :
Sélectionnez votre plan d’hébergement en haut de cet article pour consulter les conseils de stockage applicables à votre application de fonctions.
| Service de stockage | Utilisation de Functions |
|---|---|
| Stockage Blob Azure | Conservez l’état des liaisons et les touches de fonction1. Source de déploiement pour les applications qui s’exécutent dans un Plan Consommation flexible. Utilisé par défaut pour les hubs de tâches dans Durable Functions. Peut être utilisé pour stocker du code de l’application de fonction pour la build distante de Consommation Linux ou dans le cadre de déploiements d’URL de package externes. |
| Azure Files2 | Partage de fichiers utilisé pour stocker et exécuter le code de votre application de fonction dans un plan de consommation et un plan Premium. Gérer les offres groupées d’extensions. Stocker les journaux de déploiement. Prend en charge les dépendances managées dans PowerShell. |
| Stockage File d’attente Azure | Utilisé par défaut pour les hubs de tâches dans Durable Functions. Utilisé pour la gestion des échecs et des nouvelles tentatives dans déclencheurs de Azure Functions spécifiques. Utilisé pour le suivi d’objets par le déclencheur Stockage Blob. |
| Azure Stockage de tables | Utilisé par défaut pour les hubs de tâches dans Durable Functions. Utilisé pour le suivi des événements de diagnostic. |
- Le Stockage Blob est le magasin par défaut des clés de fonction, mais vous pouvez configurer un autre magasin.
- Azure Files est configuré par défaut, mais vous pouvez créer une application sans Azure Files dans certaines conditions.
Points importants à prendre en compte
Considérez les faits suivants concernant les comptes de stockage utilisés par vos applications de fonction :
Lorsque vous hébergez votre application de fonction sur le forfait Consommation (Windows) ou Premium, vous stockez votre code de fonction et vos fichiers de configuration dans Azure Files dans le compte de stockage lié. Si vous supprimez ce compte de stockage, vous supprimez définitivement le contenu. Pour plus d’informations, consultez Le compte de stockage a été supprimé.
Le compte de stockage conserve des données importantes, telles que le code de fonction, les clés d’accès et d’autres données importantes liées au service. Vous devez gérer soigneusement l’accès aux comptes de stockage utilisés par les applications de fonction des manières suivantes :
Auditez et limitez l’accès des applications et des utilisateurs au compte de stockage en fonction d’un modèle de privilège minimum. Les autorisations relatives au compte de stockage peuvent provenir d'actions sur les données dans le rôle attribué ou de l'autorisation d'effectuer l'opération listKeys.
Surveillez à la fois l’activité du plan de contrôle (comme la récupération des clés) et les opérations de plan de données (telles que l’écriture dans un objet blob) dans votre compte de stockage. Envisagez de conserver les journaux de stockage dans un emplacement autre que stockage Azure. Pour plus d’informations, consultez journal du stockage.
Si vous utilisez Durable Functions, le stockage du hub de tâches respecte particulièrement la sécurité, car l’accès en écriture à celui-ci peut être utilisé pour modifier le comportement de l’application, notamment déclencher l’exécution arbitraire du code. Pour plus d’informations, consultez Sécuriser le stockage de votre hub de tâches.
Conditions requises pour le compte de stockage
Les comptes de stockage que vous créez pendant le processus de création de l’application de fonction dans le portail Azure fonctionnent avec la nouvelle application de fonction. Lorsque vous choisissez d’utiliser un compte de stockage existant, la liste fournie n’inclut pas certains comptes de stockage non pris en charge. Les restrictions suivantes s’appliquent aux comptes de stockage utilisés par votre application de fonction. Assurez-vous qu’un compte de stockage existant respecte les conditions suivantes :
- Vous ne pouvez pas utiliser un compte de stockage sécurisé par le réseau quand votre application de fonction est hébergée dans le plan Consommation.
Le type de compte doit prendre en charge le stockage dans Blob, les files d'attente et les tables. Certains comptes de stockage ne prennent pas en charge les files d’attente ni les tables. Ces comptes incluent des comptes de stockage blob uniquement et des Azure Stockage Premium. Pour plus d’informations sur les types de comptes de stockage, consultez Vue d’ensemble des comptes de stockage.
Lorsque vous créez votre application de fonction dans le portail Azure, vous ne pouvez choisir qu’un compte de stockage existant dans la même région que l’application de fonction que vous créez. Cette exigence est une optimisation des performances et non une limitation stricte. Pour plus d’informations, consultez Emplacement du compte de stockage.
Lorsque vous créez votre application de fonction sur un plan avec prise en charge de zones de disponibilité activée, seuls les comptes de stockage redondant interzone sont pris en charge.
Lorsque vous utilisez l’automatisation du déploiement pour créer votre application de fonction avec un compte de stockage sécurisé par le réseau, vous devez inclure des configurations réseau spécifiques dans votre modèle ARM ou fichier Bicep. Si vous n’incluez pas ces paramètres et ressources, votre déploiement automatisé risque d’échouer dans la validation. Pour obtenir des conseils sur les modèles ARM et Bicep, consultez Déploiements sécurisés. Pour obtenir une vue d’ensemble de la configuration des comptes de stockage avec mise en réseau, consultez Comment utiliser un compte de stockage sécurisé avec Azure Functions.
Guide du compte de stockage
Chaque application de fonction nécessite un compte de stockage afin de fonctionner. Lorsque vous supprimez ce compte, votre application de fonction cesse de s’exécuter. Pour détecter un problème lié au stockage, consultez Comment résoudre les problèmes liés au stockage. Les considérations suivantes s’appliquent au compte de stockage utilisé par les applications de fonction.
Emplacement du compte de stockage
Pour des performances optimales, votre application de fonction doit utiliser un compte de stockage dans la même région, ce qui réduit la latence. Le portail Azure applique cette bonne pratique. Si vous devez utiliser un compte de stockage dans une région différente de celle de votre application de fonction, vous devez créer votre application de fonction en dehors du portail Azure.
Le compte de stockage doit être accessible à l’application de fonction. Si vous devez utiliser un compte de stockage sécurisé, envisagez de restreindre votre compte de stockage à un réseau virtuel.
Paramètre de connexion au compte de stockage
Par défaut, les applications de fonction configurent la connexion AzureWebJobsStorage en tant que chaîne de connexion stockée dans le paramètre d’application AzureWebJobsStorage. Vous pouvez également configurer AzureWebJobsStorage pour utiliser une connexion basée sur une identité sans secret.
Les applications de fonction s’exécutant dans un plan Consommation (Windows uniquement) ou un plan Elastic Premium (Windows ou Linux) peuvent utiliser Azure Files pour stocker les images requises pour activer la mise à l’échelle dynamique. Pour ces plans, définissez le chaîne de connexion du compte de stockage dans le paramètre WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et le nom du partage de fichiers dans le paramètre WEBSITE_CONTENTSHARE. Cette valeur est généralement le même compte utilisé pour AzureWebJobsStorage. Vous pouvez également créer une application de fonction qui n'utilise pas Azure Files, mais la mise à l'échelle peut être limitée.
Remarque
Vous devez mettre à jour la chaîne de connexion d'un compte de stockage lorsque vous régénérez des clés de stockage. Pour plus d’informations, consultez Créer un compte de stockage Azure.
Comptes de stockage partagés
Plusieurs applications de fonction peuvent partager le même compte de stockage sans aucun problème. Par exemple, dans Visual Studio, vous pouvez développer plusieurs applications à l’aide de l’émulateur de stockage Azurite. Dans ce cas, l’émulateur agit comme un compte de stockage unique. Le même compte de stockage que votre application de fonction utilise peut également stocker vos données d’application. Toutefois, cette approche n’est pas toujours recommandée dans un environnement de production.
Vous devez peut-être utiliser des comptes de stockage distincts pour éviter les collisions d’ID d’hôte.
Considérations relatives à la stratégie de gestion du cycle de vie
N'appliquez pas de stratégies de gestion lifecycle à votre compte de Stockage Blob utilisé par votre application de fonction. Functions utilise le stockage Blob pour conserver des informations importantes, telles que des clés d’accès aux fonctions. Les stratégies peuvent supprimer des blobs, tels que des clés, nécessaires par l’hôte Functions. Si vous devez utiliser des politiques, excluez les conteneurs utilisés par les fonctions, dont le préfixe est azure-webjobs ou scm.
Journaux d’activité de stockage
Étant donné que le code et les clés de fonction peuvent être conservés dans le compte de stockage, la journalisation de l’activité sur le compte de stockage est un bon moyen de surveiller l’accès non autorisé. Les journaux de ressources d'Azure Monitor peuvent être utilisés pour suivre les événements contre le plan de données de stockage. Consultez Monitoring stockage Azure pour plus d’informations sur la configuration et l’examen de ces journaux.
Le journal d’activité Azure Monitor affiche les événements du plan de contrôle, y compris l’opération listKeys. Cependant, vous devez également configurer des journaux de ressources pour le compte de stockage afin de suivre l'utilisation ultérieure des clés ou d'autres opérations du plan de données basées sur l'identité. Vous devez au moins activer la catégorie de journal StorageWrite pour pouvoir identifier les modifications apportées aux données en dehors des opérations normales des fonctions.
Pour limiter l’impact potentiel des autorisations de stockage étendues, envisagez d’utiliser une destination de non-stockage pour ces journaux, comme Log Analytics. Pour plus d’informations, consultez Monitoring Stockage Blob Azure.
Optimiser les performances de stockage
Pour optimiser les performances, utilisez un compte de stockage différent pour chaque application de fonction. Cette approche est particulièrement importante lorsque vous avez des fonctions déclenchées par Durable Functions ou Event Hubs, qui génèrent tous deux un volume élevé de transactions de stockage. Lorsque votre logique d’application interagit avec stockage Azure, soit directement (à l’aide du Kit de développement logiciel (SDK) de stockage, soit via l’une des liaisons de stockage, vous devez utiliser un compte de stockage dédié. Par exemple, si vous avez une fonction déclenchée par un hub d’événements qui écrit des données dans le stockage d’objets blob, utilisez deux comptes de stockage : un pour l’application de fonction et un autre pour les objets blob que la fonction stocke.
Routage cohérent via des réseaux virtuels
Plusieurs applications de fonction hébergées dans le même plan peuvent également utiliser le même compte de stockage pour le partage de contenu Azure Files, défini par WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Lorsque vous sécurisez ce compte de stockage à l’aide d’un réseau virtuel, toutes ces applications (y compris les emplacements) doivent utiliser la même valeur pour vnetContentShareEnabled (anciennement WEBSITE_CONTENTOVERVNET) et la même configuration d’intégration de réseau virtuel pour garantir que le trafic est acheminé de manière cohérente via le réseau virtuel prévu. Une incompatibilité dans ce paramètre entre les applications qui utilisent le même compte de stockage Azure Files peut entraîner le routage du trafic via des réseaux publics. Dans cette configuration, les règles de réseau de compte de stockage bloquent l’accès.
Les vnetContentShareEnabled recommandations ne s’appliquent pas à la consommation flexible, aux applications dédiées, aux applications conteneurs ou à l’hébergement de consommation.
Utilisation d’objets blob
Un scénario clé pour Functions est le traitement de fichiers dans un conteneur d’objets blob, par exemple pour le traitement d’images ou l’analyse des sentiments. Pour plus d’informations, consultez Traiter les chargements de fichiers.
Déclencheur sur un conteneur d’objets blob
Il existe plusieurs façons d’exécuter votre code de fonction en fonction des modifications apportées aux objets blob dans un conteneur de stockage, comme indiqué dans ce diagramme :
Utilisez le tableau suivant pour déterminer quel déclencheur de fonction correspond le mieux à vos besoins en matière de traitement des objets blob ajoutés ou mis à jour dans un conteneur :
| Stratégie | Déclencheur d’objet blob (interrogation) | Déclencheur Blob (piloté par les événements) | Déclencheur de file d’attente | Déclencheur Event Grid |
|---|---|---|---|---|
| Latence | Élevée (jusqu’à 10 minutes) | Faible | Moyen(ne) | Faible |
| Limitations des comptes de stockage | Ne prend pas en charge les comptes Blob uniquement¹ ni les comptes pour lesquels l’espace de noms hiérarchique (HNS) est activé, comme les comptes Azure Data Lake Storage Gen2 | Ne prend pas en charge les comptes v1 à usage général | None | Ne prend pas en charge les comptes v1 à usage général |
| Type de déclencheur | Stockage Blob | Stockage Blob | Stockage de files d’attente | Grille d’événements |
| Version d’extension | Quelconque | Stockage v5.x+ | Quelconque | Quelconque |
| Traite les objets blob existants | Oui | Non | Non | Non |
| Filtres | Modèle de nom de blob | Filtres d’événements | n/a | Filtres d’événements |
| Nécessite un abonnement aux événements | Non | Oui | Non | Oui |
| Prend en charge le plan Consommation flexible | Non | Oui | Oui | Oui |
| Prend en charge les scénarios à grande échelle² | Non | Oui | Oui | Oui |
| Fonctionne avec les restrictions d’accès entrant | Oui | Non | Oui | Oui3 |
| Descriptif | Comportement de déclencheur par défaut, qui repose sur l’interrogation du conteneur pour rechercher des mises à jour. Pour plus d’informations, consultez les exemples dans la référence sur le déclencheur stockage Blob. | Consomme des événements de stockage d’objets blob à partir d’un abonnement aux événements. Nécessite Source comme valeur de paramètre de EventGrid. Pour plus d’informations, consultez Tutorial : Déclencher Azure Functions sur des conteneurs d’objets blob à l’aide d’un abonnement aux événements. |
La chaîne de nom d’objet blob est ajoutée manuellement à une file d’attente de stockage quand un objet blob est ajouté au conteneur. Un déclencheur de stockage de file d'attente transmet cette valeur directement à une liaison d'entrée de stockage en blob au sein de la même fonction. | Fournit la flexibilité de déclencher des événements en plus de ceux provenant d’un conteneur de stockage. À utiliser lorsque des événements non liés au stockage doivent également déclencher votre fonction. Pour plus d’informations, consultez Comment travailler avec les déclencheurs et les liaisons d'Event Grid dans Azure Functions. |
- La limitation des comptes blob uniquement s’applique uniquement au déclencheur Blob Storage basé sur l’interrogation. Les liaisons d’entrée et de sortie de Stockage Blob prennent en charge les comptes blob uniquement.
- La scalabilité élevée peut être définie comme des conteneurs qui contiennent plus de 100 000 objets blob ou des comptes de stockage avec plus de 100 mises à jour d’objets blob par seconde.
- Vous pouvez contourner les restrictions d’accès entrant en utilisant l’abonnement aux événements pour remettre des événements sur un canal chiffré dans l’espace IP public à l’aide d’une identité utilisateur connue. Pour plus d’informations, consultez Remettre des événements en toute sécurité à l’aide d’identités managées.
Chiffrement des données de stockage
stockage Azure chiffre toutes les données d’un compte de stockage au repos. Pour plus d’informations, consultez le chiffrement des données au repos dans stockage Azure.
Par défaut, les données sont chiffrées avec des clés gérées par Microsoft. Pour un meilleur contrôle sur les clés de chiffrement, vous pouvez fournir des clés gérées par le client à utiliser pour le chiffrement des données de Blob et de fichier. Ces clés doivent être présentes dans Azure Key Vault pour que Functions puisse accéder au compte de stockage. Pour plus d’informations, consultez Chiffrer vos données d’application au repos à l’aide de clés gérées par le client.
Résidence des données dans la région
Lorsque toutes les données clients doivent rester dans une seule région, utilisez un compte de stockage associé à l’application fonctionnelle qui dispose de redondance dans la région. Utilisez aussi un compte de stockage redondant dans la région avec Azure Durable Functions.
La plateforme stocke d’autres données clients gérées uniquement dans la région lorsque vous hébergez dans un App Service Environment (ASE) à répartition de charge interne. Pour plus d’informations, consultez Redondance de zone ASE.
Considérations relatives à l’ID d’hôte
Les considérations concernant l’ID de l’hôte dans cette section ne s’appliquent pas à la consommation flexible. Dans ce plan d’hébergement, la valeur de l’identifiant hôte est créée de manière à éviter ces problèmes potentiels.
Functions utilise une valeur d’identifiant hôte pour identifier de manière unique une application de fonctions particulière dans des artefacts stockés. Par défaut, l’exécution génère automatiquement cet ID à partir du nom de l’application fonction, tronqué aux 32 premiers caractères. L’exécution utilise cet ID lorsqu’il stocke les informations de corrélation et de suivi par application dans le compte de stockage lié. Lorsque les applications de fonctions ont des noms de plus de 32 caractères et que les 32 premiers caractères sont identiques, cette troncature peut entraîner des valeurs d’ID hôte en double. Lorsque deux applications de fonctions avec des identifiants hôtes identiques utilisent le même compte de stockage, une collision d’identifiant hôte se produit car les données stockées ne peuvent pas être liées de manière unique à la bonne application de fonction.
Remarque
Le même type de collision d’identifiant d’hôte peut se produire entre une application de fonction dans un emplacement de production et cette même application de fonction dans un emplacement de préproduction, lorsque les deux emplacements utilisent le même compte de stockage.
Dans la version 4.x de l’exécution Functions, une erreur est enregistrée et l’hôte s’arrête, entraînant une défaillance totale. Pour plus d’informations, consultez La troncature de l’HostID peut provoquer des collisions.
Éviter les collisions d’ID d’hôte
Utilisez les stratégies suivantes pour éviter les collisions avec l’identifiant de l’hôte :
- Utilisez des comptes de stockage séparés afin que chaque hôte en collision écrive sur un compte différent.
- Renomme l’une de vos applications de fonction pour que son nom soit inférieur à 32 caractères, ce qui modifie l’identifiant hôte calculé pour l’application et supprime la collision.
- Définissez un ID d’hôte explicite pour une ou plusieurs des applications en collision. Pour plus d’informations, consultez Modifier l’ID de l’hôte.
Important
La modification du compte de stockage associé à une application de fonction existante ou la modification de l’ID hôte de l’application peut affecter le comportement des fonctions existantes. Par exemple, un déclencheur Stockage Blob suit s’il traite des objets blob individuels en écrivant des reçus sous un chemin d’accès d’ID d’hôte spécifique dans le stockage. Lorsque l’ID d’hôte change ou que vous pointez vers un nouveau compte de stockage, les objets blob précédemment traités peuvent être retraités.
Remplacer l’ID d’hôte
Vous pouvez définir un identifiant hôte explicite pour votre application fonctionnelle dans les paramètres de l’application en utilisant ce AzureFunctionsWebHost__hostid paramètre. Pour plus d’informations, consultez AzureFunctionsWebHost__hostid.
Lorsqu’une collision survient entre les emplacements, vous devez définir un identifiant hôte spécifique pour chaque emplacement, y compris le slot de production. Vous devez également marquer ces paramètres en tant que paramètres de déploiement afin qu’ils ne soient pas échangés. Pour savoir comment créer des paramètres d’application, consultez Utiliser les paramètres d’application.
Créer une application sans Azure Files
Le service Azure Files fournit un système de fichiers partagé qui prend en charge des scénarios à grande échelle. Lorsque votre application de fonction s’exécute dans un plan Elastic Premium ou sur Windows dans un plan Consommation, un partage Azure Files est créé par défaut dans votre compte de stockage. Les fonctions peuvent utiliser ce partage pour des fonctionnalités telles que la diffusion de logs et comme emplacement partagé de contenu d’application. Le lieu de déploiement dépend de la technologie de déploiement et de la configuration de l’application. Par exemple, une application qui utilise une URL externe de package exécute son package depuis l’URL configurée au lieu du partage Azure Files.
L’utilisation d’Azure Files nécessite une chaîne de connexion, que vous stockez dans les paramètres de l’application sous la forme de WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Azure Files ne prend actuellement pas en charge les connexions basées sur des identités. Si votre scénario exige que vous ne stockiez aucun secret dans les paramètres de l'application, vous devez supprimer la dépendance de votre application à Azure Files. Vous pouvez éviter cette dépendance en créant votre application sans dépendance par défaut Azure Files.
Remarque
Vous devriez également envisager d’exécuter votre application fonctionnelle dans le plan Flex Consumption, qui offre un meilleur contrôle sur le package de déploiement, y compris la possibilité d’utiliser des connexions d’identité gérées. Pour plus d’informations, consultez Configurer les paramètres de déploiement.
Pour faire tourner votre application sans le partage Azure Files, vous devez remplir les conditions suivantes :
Vous devez déployer votre package dans un conteneur Stockage Blob Azure qui n'autorise pas l'accès anonyme et définir l'URL Stockage Blob du package comme
WEBSITE_RUN_FROM_PACKAGEparamètre de l'application.Pour éviter de stocker un identifiant de déploiement dans l’URL du paquet, accordez l’accès à l’identité gérée de l’application fonctionnaire au paquet. Lorsque vous utilisez une identité attribuée par l’utilisateur, définissez
WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_IDégalement . Si vous ne pouvez pas utiliser l’identité managée, utilisez une URL de signature d’accès partagé (SAS) et renouvelez-la avant l’expiration du SAS.Pour supprimer la chaîne de connexion du compte de stockage hôte par défaut dans les paramètres de votre application, configurez
AzureWebJobsStoragel’utilisation d’une identité gérée.Vous devez mettre à jour manuellement le package de déploiement et maintenir l’URL du package de déploiement. Pour des informations sur le redémarrage de l’application et la synchronisation des déclencheurs lors de la mise à jour du paquet, voir Exécuter depuis une URL de paquet externe.
Vous devez également noter les considérations suivantes :
- Votre application ne peut pas compter sur un système de fichiers partagé et écrivable.
- La modification du portail n’est pas prise en charge.
- Les expériences de streaming de journaux dans les clients tels que le portail Azure s’apparentent aux journaux du système de fichiers. Privilégiez les journaux Application Insights.
Si les exigences précédentes correspondent à votre scénario, vous pouvez continuer à créer une application de fonction sans Azure Files. Créez une application sans les paramètres d'application WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE de l'une de ces manières :
- Modèles Bicep/ARM : supprimez les deux paramètres de l’application du modèle ARM ou du fichier Bicep, puis déployez l’application en utilisant le modèle modifié.
- Le portail Azure : efface Ajouter une connexion Azure Files dans l’onglet Stockage lorsque vous créez l’application sur le portail Azure.
Azure Files est utilisé pour activer le scale-out dynamique pour Functions. La mise à l’échelle peut être limitée lorsque vous exécutez votre application sans Azure Files dans le plan Elastic Premium et les plans consommation s’exécutant sur Windows.
Flex Consumption ne dépend pas d'un partage de contenu Azure Files. Il utilise un stockage de déploiement Blob configurable et prend en charge les connexions d’identité gérées. Pour plus d’informations, consultez Configurer les paramètres de déploiement.
Les applications de forfaits dédiés n'ont pas la dépendance par défaut au partage de contenu d'Azure Files décrite dans cette section.
Les fonctions sur Azure Container Apps n'ont pas la dépendance par défaut au partage de contenu Azure Files décrite dans cette section.
Monter des partages de fichiers
Cette fonctionnalité n’est disponible que sous Linux.
Vous pouvez assembler des partages Azure Files sur vos applications de fonctions Linux, que vous pouvez utiliser pour accéder à des fichiers existants, des modèles d’apprentissage automatique ou de grands binaires dans vos fonctions. Pour obtenir des conseils conceptuels sur le choix entre les montages de stockage, les liaisons et les bases de données externes, consultez Choose une stratégie d’accès aux fichiers pour Azure Functions.
Flex Consumption ne prend en charge que les montages Azure Files via Server Message Block (SMB).
Utilisez la commande suivante pour monter un partage existant dans votre application de fonctions Linux.
az webapp config storage-account add
Dans cette commande, share-name est le nom du partage Azure Files existant.
custom-id peut être n’importe quelle chaîne qui définit de façon unique le partage lorsqu’il est monté sur l’application de fonction. En outre, mount-path est le chemin d’accès à partir duquel le partage est accessible dans votre application de fonction.
mount-path doit être au format /dir-name, et ne peut pas commencer par /home.
Pour obtenir un exemple complet, consultez Créer une application de fonction Python et monter un partage Azure Files.
Pour les fonctions sur Azure Container Apps, configurez un volume Azure Files sur l’application conteneur. Pour plus d’informations, consultez Utilisez les montages de stockage dans Azure Container Apps.
Les montures de stockage ne sont pas prises en charge dans le plan Consommation.
Important
Les applications de fonction qui exécutent encore le runtime v3 de fin de vie sur Linux au sein d’un plan de consommation ne seront plus exécutées après le 30 septembre 2026. Pour éviter toute interruption de service, migrez votre application vers le runtime v4.
L’option permettant d’héberger des applications de fonction sur Linux dans un plan Consommation est mise hors service le 30 septembre 2028. Le plan de consommation Linux ne reçoit aucune nouvelle fonctionnalité ni version de langage. Les applications s'exécutant sur Windows dans un plan Consommation ne sont actuellement pas affectées. Migrez vos applications vers le plan Flex Consumption avant la date de mise hors service.