Considérations relatives au stockage pour Azure Functions
Azure Functions nécessite un compte Stockage Azure lorsque vous créez une instance d’application de fonction. Les services de stockage suivants peuvent être utilisés par votre application de fonction :
| Service de stockage | Utilisation de Functions |
|---|---|
| stockage d’objets 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 des 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. |
| Stockage File d’attente Azure | Utilisé par défaut pour des hubs de tâches dans Durable Functions. Utilisé pour des échecs et de nouvelles tentatives de gestion dans des déclencheurs Azure Functions spécifiques. Utilisé pour le suivi d’objets par le déclencheur Stockage Blob. |
| Stockage Table Azure | Utilisé par défaut pour des hubs de tâches dans Durable Functions. |
- 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 sous certaines conditions, vous pouvez créer une application sans Azure Files.
Considérations importantes
Vous devez tenir compte des faits suivants concernant les comptes de stockage utilisés par vos applications fonctionnelles :
Lorsque votre application de fonction est hébergée sur le plan Consommation ou le plan Premium, vos fichiers de code et de configuration de fonction sont stockés dans Azure Files dans le compte de stockage lié. Lorsque vous supprimez ce compte de stockage, le contenu est supprimé et ne peut pas être récupéré. Pour plus d’informations, consultez Le compte de stockage a été supprimé.
Les 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, peuvent être conservées dans le compte de stockage. 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 gérer les journaux de stockage dans un emplacement autre que Stockage Azure. Pour plus d’informations, consultez journal du stockage.
Exigences en matière de compte de stockage
Les comptes de stockage créés dans le cadre du flux de création d'une application de fonction dans le portail Microsoft Azure sont garantis de fonctionner 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. Vous devez donc vous assurer qu’un compte de stockage existant répond à ces exigences :
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 les comptes de stockage blob uniquement et Stockage Premium Azure. Pour plus d’informations sur les types de comptes de stockage, consultez Vue d’ensemble des comptes de stockage.
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.
Lors de la création de votre application de fonction dans le portail, vous êtes uniquement autorisé à choisir un compte de stockage existant dans la même région que l’application de fonction que vous créez. Il s’agit d’une optimisation des performances et non d’une limitation stricte. Pour plus d’informations, consultez Emplacement du compte de stockage.
Lors de la création de votre application de fonction sur un plan avec la prise en charge des zones de disponibilité activée, seuls les comptes de stockage redondant interzone sont pris en charge.
Quand 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 votre fichier Bicep. Lorsque vous n’incluez pas ces paramètres et ressources, votre déploiement automatisé risque d’échouer dans la validation. Pour obtenir de l’aide plus spécifique sur 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 ce compte est supprimé, votre application de fonction ne s’exécute pas. Pour détecter un problème lié au stockage, consultez Comment résoudre les problèmes liés au stockage. Les autres 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 meilleure pratique. Si pour une raison quelconque, vous devez utiliser un compte de stockage dans une région différente de votre application de fonction, vous devez créer votre application de fonction en dehors du portail.
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 fonctionnelles configurent AzureWebJobsStoragela connexion comme une chaîne de connexion stockée dans le paramètre d'application AzureWebJobsStorage, mais vous pouvez également configurer AzureWebJobsStorage pour utiliser une connexion basée sur l'identité sans secret.
Les applications de fonction exécutées dans le cadre d'un plan de consommation (Windows uniquement) ou d'un plan Elastic Premium (Windows ou Linux) peuvent utiliser Azure Files pour stocker les images nécessaires à la mise à l'échelle dynamique. Pour ces plans, définissez la 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 . Il s’agit généralement du 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
Une chaîne de connexion du compte de stockage doit être mise à jour lorsque vous régénérez des clés de stockage. En savoir plus sur la gestion des clés de stockage ici.
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 Azure. Dans ce cas, l’émulateur agit comme un compte de stockage unique. Le même compte de stockage que celui utilisé par votre application de fonction peut également être utilisé pour 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
Vous ne devez pas appliquer de stratégies de gestion du cycle de vie à votre compte Stockage Blob utilisé par votre application de fonction. Functions utilise le stockage Blob pour conserver des informations importantes, telles que les clés d’accès aux fonctions, et les stratégies peuvent supprimer les objets blob (tels que les clés) nécessaires à 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 Azure Monitor peuvent être utilisés pour suivre des événements par rapport au plan de données de stockage. Pour plus d’informations sur la configuration et l’examen de ces journaux, consultez Surveillance du Stockage Azure .
Le journal d’activité Azure Monitor affiche les événements de 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 d'autorisations de stockage trop larges, envisagez d'utiliser une destination autre que le stockage pour ces journaux, telle que Log Analytics. Pour plus d’informations, consultez Supervision du service Stockage Blob Azure.
Optimiser les performances de stockage
Pour optimiser les performances, utilisez un compte de stockage différent pour chaque application de fonction. Ceci est particulièrement important lorsque vous avez des fonctions Durable Functions ou des fonctions déclenchées par Event Hub, qui génèrent un volume élevé de transactions de stockage. Lorsque votre logique d’application interagit avec le stockage Azure, soit directement (à l’aide du SDK 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 Event Hub 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 stockés par la fonction.
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 ce compte de stockage est également sécurisé par un réseau virtuel, toutes ces applications doivent également utiliser la même valeur pour vnetContentShareEnabled (anciennement WEBSITE_CONTENTOVERVNET) afin de garantir que le trafic est acheminé de manière cohérente via le réseau virtuel prévu. Si ce paramètre n’est pas adapté aux applications qui utilisent le même compte de stockage Azure Files, le trafic risque d’être acheminé via des réseaux publics, ce qui entraîne le blocage de l’accès par les règles de réseau du compte de stockage.
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 selon les modifications apportées aux objets blob dans un conteneur de stockage. Utilisez le tableau suivant pour déterminer le déclencheur de fonction répondant le mieux à vos besoins :
| Stratégie | Conteneur (interrogation) | Conteneur (événements) | Déclencheur de file d’attente | Event Grid |
|---|---|---|---|---|
| Latence | Élevée (jusqu’à 10 minutes) | Faible | Moyenne | Faible |
| Limitations des comptes de stockage | Comptes blob uniquement non pris en charge¹ | Comptes v1 universels non pris en charge | Aucun | Comptes v1 universels non pris en charge |
| Type de déclencheur | Stockage Blob | Stockage Blob | Stockage File d’attente | Event Grid |
| Version d’extension | Quelconque | Stockage v5.x+ | Quelconque | Quelconque |
| Traite les objets blob existants | Oui | No | Non | Non |
| Filtres | Modèle de nom d’objet blob | Filtres d’événements | n/a | Filtres d’événements |
| Nécessite un abonnement aux événements | Non | Oui | No | Oui |
| Prend en charge le plan Consommation flexible | Non | Oui | Oui | Oui |
| Prend en charge les scénarios à grande échelle² | Non | Oui | Oui | Oui |
| Description | 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 le Tutoriel : 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. Cette valeur est transférée directement par un déclencheur Stockage File d’attente à une liaison d’entrée Stockage Blob sur la même fonction. | Offre la flexibilité de pouvoir effectuer des déclenchements avec des événements ne provenant pas nécessairement 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 utiliser des déclencheurs Event Grid et des liaisons dans Azure Functions. |
- 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.
Chiffrement des données de stockage
Le stockage Azure chiffre toutes les données dans un compte de stockage au repos. Pour plus d'informations, consultez Fonctionnalité de chiffrement du service Stockage Azure pour les données au repos.
Par défaut, les données sont chiffrées avec des clés managées par Microsoft Pour plus de 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 fichiers et d’objets blob. Ces clés doivent être présentes dans Azure Key Vault pour que Functions puisse accéder au compte de stockage. Pour en savoir plus, consultez Chiffrement 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 client doivent rester dans une seule région, le compte de stockage associé à l’application de fonction doit être un compte avec une redondance dans la région. Un compte de stockage redondant dans la région doit également être utilisé avec Azure Durable Functions.
Les autres données client gérées par la plateforme ne sont stockées au sein de la région que si elles sont hébergées dans un environnement App Service Environment (ASE) avec équilibrage de charge interne. Pour plus d’informations, consultez Redondance de zone ASE.
Considérations relatives à l’ID d’hôte
Functions utilise une valeur d’ID d’hôte comme moyen d’identifier de manière unique une application de fonction particulière dans les artefacts stockés. Par défaut, cet identifiant est généré automatiquement à partir du nom de l'application de la fonction, tronqué aux 32 premiers caractères. Cet ID est ensuite utilisé lors du stockage des informations de corrélation par application et de suivi dans le compte de stockage lié. Lorsque vous avez des applications de fonction avec des noms de plus de 32 caractères et que les 32 premiers caractères sont identiques, cette troncation peut entraîner des valeurs d’ID d’hôte en double. Lorsque deux applications de fonction avec des ID d’hôte identiques utilisent le même compte de stockage, vous obtenez une collision d’ID d’hôte, car les données stockées ne peuvent pas être liées de manière unique à l’application de fonction appropriée.
Notes
Cette même collision d’ID hôte peut se produire entre une application de fonction dans un emplacement de production et la même application de fonction dans un emplacement de préproduction, lorsque les deux emplacements utilisent le même compte de stockage.
À compter de la version 3.x du runtime Functions, la collision d’ID d’hôte est détectée et un avertissement est journalisé. Dans la version 4.x, une erreur est journalisée et l’hôte est arrêté, ce qui entraîne une défaillance matérielle. Vous trouverez plus d’informations sur la collision d’ID d’hôte dans ce problème.
Éviter les collisions d’ID d’hôte
Vous pouvez utiliser les stratégies suivantes pour éviter les collisions d’ID d’hôte :
- Utilisez un compte de stockage séparé pour chaque application de fonction ou chaque emplacement impliqué dans la collision.
- Renommez l’une de vos applications de fonction en une valeur inférieure à 32 caractères, ce qui modifie l’ID d’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 Remplacement de l’ID d’hôte.
Important
La modification du compte de stockage associé à une application de fonction existante ou la modification de l’ID d’hôte de l’application peut avoir un impact sur le comportement des fonctions existantes. Par exemple, un déclencheur Stockage Blob suit s’il a traité des blobs individuels en écrivant des reçus sous un chemin 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 explicitement un ID d’hôte spécifique pour votre application de fonction dans les paramètres de l’application à l’aide du paramètre AzureFunctionsWebHost__hostid. Pour plus d’informations, consultez AzureFunctionsWebHost__hostid.
Lorsque la collision se produit entre des emplacements, vous devez définir un ID d’hôte spécifique pour chaque emplacement, y compris l’emplacement 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.
Clusters avec Azure Arc
Une application de fonction déployée sur un cluster Kubernetes avec Azure Arc n’exige pas nécessairement de compte de stockage. Dans ce cas, un compte de stockage n’est requis par Functions que lorsque l’application de fonction emploie un déclencheur qui a besoin de stockage. Le tableau suivant indique quels déclencheurs peuvent demander un compte de stockage et lesquels n’en demandent pas.
| Non requis | peut avoir besoin de stockage |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Stockage Blob • Event Grid • Event Hubs • IoT Hub • Stockage File d’attente • SendGrid • SignalR • Stockage Table • Timer • Twilio |
Pour créer une application de fonction sur un cluster Kubernetes avec Azure Arc sans stockage, vous devez utiliser la commande Azure CLI az functionapp create. La version d’Azure CLI doit comporter la version 0.1.7 ou une version plus récente de l’extension appservice-kube. Utilisez la commande az --version pour vérifier que l’extension est installée et qu’il s’agit de la bonne version.
Un compte de stockage existant est nécessaire pour créer des ressources d’application de fonction à l’aide de méthodes autres qu’Azure CLI. Si vous envisagez d’utiliser des déclencheurs qui exigent un compte de stockage, créez celui-ci avant l’application de fonction.
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. Quand votre application de fonction s’exécute sur Windows dans un plan Élastique Premium ou Consommation, un partage Azure Files est créé par défaut dans votre compte de stockage. Ce partage est utilisé par Functions pour activer certaines fonctionnalités, comme le streaming de journaux. Il est également utilisé comme emplacement de déploiement des packages partagés, ce qui garantit la cohérence de votre code de fonction déployé sur toutes les instances.
Par défaut, les applications de fonction hébergées dans les plans Premium et Consommation utilisent un déploiement de fichier zip, les packages de déploiement étant stockés dans ce partage de fichiers Azure. Cette section s’applique seulement à ces plans d’hébergement.
L’utilisation d’Azure Files nécessite l’utilisation d’une chaîne de connexion, qui est stockée dans les paramètres de votre application en tant que WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. Pour le moment, Azure Files ne prend pas en charge les connexions basées sur l’identité. Si votre scénario vous contraint à ne pas stocker de secrets dans les paramètres de l’application, vous devez supprimer la dépendance de votre application par rapport à Azure Files. Pour ce faire, vous pouvez créer votre application sans la dépendance Azure Files par défaut.
Remarque
Vous devez également envisager l’exécution dans votre application de fonction dans le plan Consommation flexible, qui est actuellement en préversion. Le plan Consommation flexible offre un meilleur contrôle sur le package de déploiement, notamment la possibilité d’utiliser des connexions d’identité managée. Pour plus d’informations, consultez Configurer les paramètres de déploiement dans l’article Consommation flexible.
Pour exécuter votre application sans le partage de fichiers Azure, vous devez satisfaire aux exigences suivantes :
- Vous devez déployer votre package sur un conteneur Stockage Blob Azure distant, puis définir l’URL qui fournit l’accès à ce package comme paramètre d’application
WEBSITE_RUN_FROM_PACKAGE. Cette option vous permet de stocker le contenu de votre application dans Stockage Blob au lieu d’Azure Files, qui prend en charge les identités managées.
Vous êtes responsable de la mise à jour manuelle du package de déploiement et de la maintenance de l’URL du package de déploiement, qui contient probablement une signature d’accès partagé (SAP).
- Votre application ne peut pas reposer sur un système de fichiers accessible en écriture partagé
- L’application ne peut pas utiliser la version 1.x du runtime Functions.
- 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 ci-dessus correspondent à votre scénario, vous pouvez créer une application de fonction sans Azure Files. Pour ce faire, vous pouvez créer une application sans les paramètres d’application WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE. Pour commencer, générez un modèle ARM pour un déploiement standard, supprimez ces deux paramètres, puis déployez le modèle modifié.
Comme Azure Files est utilisé pour activer le scale-out dynamique pour Functions, la mise à l’échelle peut être limitée lors de l’exécution de votre application sans Azure Files dans le plan Élastique Premium et dans les plans Consommation s’exécutant sur Windows.
Monter des partages de fichiers
Cette fonctionnalité est actuellement disponible uniquement sous Linux.
Vous pouvez monter des partages Azure Files existants dans vos applications de fonction Linux. Monter un partage vers votre application de fonction Linux vous permet d’accéder à des modèles Machine Learning existants ou à d’autres données dans vos fonctions. Vous pouvez utiliser la commande suivante pour monter un partage existant dans votre application de fonction Linux.
az webapp config storage-account add
Dans cette commande, share-name est le nom du partage Azure Files existant, et custom-id peut représenter 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 les scripts dans Créer une application de fonction Python et monter un partage Azure Files.
Actuellement, seul un stockage storage-type de type AzureFiles est pris en charge. Vous pouvez uniquement monter cinq partages sur une application de fonction donnée. Le montage d’un partage de fichiers peut augmenter le temps de démarrage à froid d’au moins 200 à 300 ms, voire plus si le compte de stockage se trouve dans une autre région.
Le partage monté est disponible pour votre code de fonction à l’emplacement mount-path spécifié. Par exemple, lorsque mount-path est /path/to/mount, vous pouvez accéder au répertoire cible à l’aide des API du système de fichiers, comme dans l’exemple Python suivant :
import os
...
files_in_share = os.listdir("/path/to/mount")
Étapes suivantes
En savoir plus sur les options d’hébergement d’Azure Functions.