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. 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. |
1 Le stockage Blob est le magasin par défaut des clés de fonction, mais vous pouvez configurer un autre magasin.
2 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 déjà sécurisé à l’aide d’un pare-feu ou d’un réseau privé virtuel lorsque vous créez votre application de fonction dans le portail Azure. Toutefois, le portail ne filtre actuellement pas ces comptes de stockage sécurisés. Pour savoir comment utiliser un compte de stockage sécurisé avec votre application de fonction, consultez Comment utiliser un compte de stockage sécurisé avec Azure Functions.
Vous ne pouvez pas utiliser de comptes de stockage sécurisés avec des applications de fonction hébergées dans le plan de 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.
Vous pouvez créer des applications de fonction dans un plan Elastic Premium ou Dedicated (App Service) à l’aide de l’automatisation du déploiement. Toutefois, vous devez inclure des configurations réseau spécifiques dans votre modèle ARM ou fichier Bicep. Lorsque vous n’incluez pas ces paramètres et ressources, votre déploiement automatisé risque d’échouer dans la validation. Pour plus d’informations, consultez Déploiements sécurisés.
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.
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 :
| Considération | Stockage Blob (interrogation) | Stockage Blob (basé sur les événements) | Stockage de files 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 |
| 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 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. |
1 Les liaisons d’entrée et de sortie Stockage Blob prennent en charge les comptes blob uniquement.
2 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
Azure Files est configuré par défaut pour les plans de consommation Elastic Premium et non-Linux pour servir de système de fichiers partagé dans des scénarios à grande échelle. Le système de fichiers est utilisé par la plateforme pour certaines fonctionnalités telles que le streaming de journaux, mais il assure essentiellement la cohérence de la charge utile de la fonction déployée. Lorsqu’une application est déployée à l’aide d’une URL de package externe, le contenu de l’application est pris en charge à partir d’un système de fichiers en lecture seule distinct. Cela signifie que vous pouvez créer votre application de fonction sans Azure Files. Si vous créez votre application de fonction avec Azure Files, un système de fichiers accessible en écriture est toujours fourni. Toutefois, ce système de fichiers peut ne pas être disponible pour toutes les instances d’application de fonction.
Lorsque Azure Files n’est pas utilisé, vous devez tenir compte des exigences suivantes :
- Vous devez effectuer le déploiement à partir d’une URL de package externe
- 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 éléments ci-dessus sont correctement pris en compte, vous pouvez créer l’application sans Azure Files. Créez l’application de fonction sans spécifier les paramètres WEBSITE_CONTENTAZUREFILECONNECTIONSTRING et WEBSITE_CONTENTSHARE. Vous pouvez éviter ces paramètres en générant un modèle ARM pour un déploiement standard, en supprimant ces deux paramètres, puis en déployant le modèle.
Étant donné que les fonctions utilisent Azure Files pendant certaines parties du processus de montée en charge dynamique, la mise à l'échelle peut être limitée lors de l'exécution sans les plans Azure Files on Consumption et Elastic Premium.
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.