Partager via


Guide du développeur Azure Functions

Dans Azure Functions, toutes les fonctions partagent certains concepts et composants techniques de base, quel que soit votre langage ou environnement de développement. Cet article est spécifique au langage. Sélectionnez votre langage de développement préféré en haut de l'article.

Cet article suppose que vous avez déjà lu la Présentation d’Azure Functions.

Si vous préférez vous lancer directement, vous pouvez suivre un tutoriel de démarrage rapide à l'aide de Visual Studio, Visual Studio Code ou à partir de l'invite de commande.

Si vous préférez vous lancer directement, vous pouvez suivre un tutoriel de démarrage rapide à l'aide de Maven (ligne de commande), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud ou Visual Studio Code.

Si vous préférez vous lancer directement, vous pouvez suivre un tutoriel de démarrage rapide à l'aide de Visual Studio Code ou à partir de l'invite de commande.

Si vous préférez vous lancer directement, vous pouvez suivre un tutoriel de démarrage rapide à l'aide de Visual Studio Code ou à partir de l'invite de commande.

Si vous préférez vous lancer directement, vous pouvez suivre un tutoriel de démarrage rapide à l'aide de Visual Studio Code ou à partir de l'invite de commande.

Si vous préférez vous lancer directement, vous pouvez suivre un tutoriel de démarrage rapide à l'aide de Visual Studio Code ou à partir de l'invite de commande.

Projet de code

Au cœur d'Azure Functions se trouve un projet de code spécifique au langage qui implémente une ou plusieurs unités d'exécution de code appelées fonctions. Les fonctions sont simplement des méthodes qui s'exécutent dans le cloud Azure en fonction d'événements, en réponse à des requêtes HTTP ou selon une planification. Considérez votre projet de code Azure Functions comme un mécanisme d'organisation, de déploiement et de gestion collective de vos fonctions individuelles dans le projet lorsqu'elles s'exécutent dans Azure. Pour plus d'informations, reportez-vous à Organiser vos fonctions.

La façon dont vous mettez en place votre projet de code et indiquez quelles méthodes dans votre projet sont des fonctions dépend du langage de développement de votre projet. Pour obtenir de l'aide détaillée spécifique au langage, reportez-vous à Guide des développeurs C#.

La façon dont vous mettez en place votre projet de code et indiquez quelles méthodes dans votre projet sont des fonctions dépend du langage de développement de votre projet. Pour obtenir de l'aide sur le langage, reportez-vous à Guide des développeurs C#.

La façon dont vous mettez en place votre projet de code et indiquez quelles méthodes dans votre projet sont des fonctions dépend du langage de développement de votre projet. Pour obtenir de l'aide sur le langage, reportez-vous à Guide des développeurs Node.js.

La façon dont vous mettez en place votre projet de code et indiquez quelles méthodes dans votre projet sont des fonctions dépend du langage de développement de votre projet. Pour obtenir de l'aide sur le langage, reportez-vous à Guide des développeurs PowerShell.

La façon dont vous mettez en place votre projet de code et indiquez quelles méthodes dans votre projet sont des fonctions dépend du langage de développement de votre projet. Pour obtenir de l'aide sur le langage, reportez-vous à Guide des développeurs Python.

Toutes les fonctions doivent avoir un déclencheur, qui définit la façon dont la fonction démarre et peut fournir une entrée à la fonction. Vos fonctions peuvent éventuellement définir des liaisons d'entrée et de sortie. Ces liaisons simplifient les connexions à d'autres services sans que vous ayez à travailler avec des kits SDK clients. Pour plus d’informations, consultez Concepts des déclencheurs et liaisons Azure Functions.

Azure Functions fournit un ensemble de modèles de projets et de fonctions spécifiques au langage qui facilitent la création de projets de code et l'ajout de fonctions à votre projet. Vous pouvez utiliser n'importe quel outil qui prend en charge le développement Azure Functions pour générer de nouvelles applications et fonctions à l'aide de ces modèles.

Outils de développement

Les outils suivants assurent une expérience de développement et de publication intégrée pour Azure Functions dans votre langage préféré :

Ces outils s'intègrent à Azure Functions Core Tools afin que vous puissiez exécuter et déboguer sur votre ordinateur local à l'aide du runtime Functions. Pour plus d’informations, consultez Coder et tester Azure Functions localement.

Il existe également un éditeur dans le Portail Azure qui vous permet de mettre à jour votre code et votre fichier de définition function.json directement dans le portail. Vous devez utiliser cet éditeur uniquement pour les petites modifications ou la création de fonctions de preuve de concept. Vous devez toujours développer vos fonctions localement, lorsque cela est possible. Pour plus d'informations, consultez Créer votre première fonction à l’aide du portail Azure.

La modification du portail est prise en charge uniquement pour Node.js version 3, qui utilise le fichier function.json.

Déploiement

Lorsque vous publiez votre projet de code sur Azure, vous déployez essentiellement votre projet sur une ressource d'application de fonction existante. Une application de fonction fournit un contexte d’exécution dans Azure dans lequel vos fonctions s’exécutent. À ce titre, elle constitue l’unité de déploiement et de gestion de vos fonctions. Du point de vue des ressources Azure, une application de fonction équivaut à une ressource de site (Microsoft.Web/sites) dans Azure App Service, ce qui équivaut à une application Web.

Une application de fonction est constitué d’une ou de plusieurs des fonctions individuelles qui sont gérées, déployées et mises à l’échelle ensemble. Toutes les fonctions d'une application de fonction partagent le même plan de tarification, la même méthode de déploiement et la même version du runtime. Pour plus d'informations, reportez-vous à Comment gérer une application de fonction.

Lorsque l'application de fonction et toutes les autres ressources requises n'existent pas encore dans Azure, vous devez d'abord créer ces ressources avant de pouvoir déployer vos fichiers projet. Vous pouvez créer ces ressources de l'une des manières suivantes :

En plus de la publication basée sur des outils, Functions prend en charge d'autres technologies pour le déploiement du code source sur une application de fonction existante. Pour plus d’informations, consultez Technologies de déploiement dans Azure Functions.

Se connecter aux services

Une exigence majeure de tout service de calcul basé sur le cloud est la lecture et l'écriture de données vers d'autres services cloud. Functions fournit un ensemble complet de liaisons qui vous permet de vous connecter plus facilement aux services sans avoir à travailler avec des kits SDK clients.

Que vous utilisiez les extensions de liaison fournies par Functions ou que vous utilisiez directement des kits SDK clients, vous stockez en toute sécurité les données de connexion et ne les incluez pas dans votre code. Pour plus d’informations, consultez Connexions.

Liaisons

Functions fournit des liaisons pour de nombreux services Azure et quelques services tiers, qui sont implémentés en tant qu'extensions. Pour plus d'informations, reportez-vous à la liste complète des liaisons prises en charge.

Les extensions de liaison peuvent prendre en charge les entrées et les sorties ; de nombreux déclencheurs font également office de liaisons d'entrée. Les liaisons vous permettent de configurer la connexion aux services afin que l'hôte Functions puisse gérer l'accès aux données à votre place. Pour plus d’informations, consultez Concepts des déclencheurs et liaisons Azure Functions.

Si vous rencontrez des problèmes avec des erreurs provenant de liaisons, reportez-vous à la documentation Codes d'erreur de liaison Azure Functions.

Kits de développement logiciel (SDK) client

Bien que Functions fournisse des liaisons pour simplifier l'accès aux données dans votre code de fonction, vous pouvez toujours utiliser un kit de développement logiciel (SDK) client dans votre projet pour accéder directement à un service donné, si vous préférez. Vous devrez peut-être utiliser directement les kits SDK clients si vos fonctions nécessitent une fonctionnalité du kit SDK sous-jacent qui n'est pas prise en charge par l'extension de liaison.

Lorsque vous utilisez des kits SDK clients, vous devez utiliser le même processus pour stocker et accéder aux chaînes de connexion que celui utilisé par les extensions de liaison.

Lorsque vous créez une instance de kit SDK client dans vos fonctions, vous devez obtenir les informations de connexion requises par le client à partir des variables d'environnement.

Lorsque vous créez une instance de kit SDK client dans vos fonctions, vous devez obtenir les informations de connexion requises par le client à partir des variables d'environnement.

Lorsque vous créez une instance de kit SDK client dans vos fonctions, vous devez obtenir les informations de connexion requises par le client à partir des variables d'environnement.

Lorsque vous créez une instance de kit SDK client dans vos fonctions, vous devez obtenir les informations de connexion requises par le client à partir des variables d'environnement.

Lorsque vous créez une instance de kit SDK client dans vos fonctions, vous devez obtenir les informations de connexion requises par le client à partir des variables d'environnement.

Connexions

Une bonne pratique de sécurité Azure Functions consiste à tirer parti des fonctionnalités des paramètres d'application d'Azure App Service pour vous aider à stocker de manière plus sécurisée les chaînes, clés et autres jetons nécessaires pour vous connecter à d'autres services. Les paramètres d’application dans Azure sont stockés sous forme chiffrée et sont accessibles au moment de l’exécution par votre application en tant que paires de variables d’environnement name value. Pour les déclencheurs et les liaisons qui nécessitent une propriété de connexion, vous définissez le nom du paramètre d'application au lieu de la chaîne de connexion réelle. Vous ne pouvez pas configurer une liaison directement avec une chaîne de connexion ou une clé.

Par exemple, considérez une définition de déclencheur qui a une propriété connection. Au lieu de la chaîne de connexion, vous définissez connection comme le nom d'une variable d'environnement qui contient la chaîne de connexion. L'utilisation de cette stratégie d'accès aux secrets rend vos applications plus sécurisées et facilite la modification des connexions entre les environnements. Pour encore plus de sécurité, vous pouvez utiliser des connexions basées sur l'identité.

Le fournisseur de configuration par défaut utilise des variables d’environnement. Ces variables sont définies dans les paramètres d'application lors de l'exécution dans Azure et dans le fichier de paramètres locaux lors du développement local.

Valeurs de connexion

Quand le nom de la connexion correspond à une seule valeur exacte, le runtime identifie la valeur en tant que chaîne de connexion, qui comprend généralement un secret. Les détails d'une chaîne de connexion dépendent du service auquel vous souhaitez vous connecter.

Toutefois, un nom de connexion peut également faire référence à un ensemble de plusieurs éléments de configuration, utiles pour la configuration des connexions basées sur l’identité. Les variables d’environnement peuvent être traitées comme une collection à l’aide d’un préfixe partagé qui se termine par deux traits de soulignement __. Il est ensuite possible de référencer le groupe en définissant le nom de la connexion sur ce préfixe.

Par exemple, la propriété connection pour une définition de déclencheur de blobs Azure peut être Storage1. Tant qu’aucune valeur de chaîne unique n’est configurée par une variable d’environnement nommée Storage1, une variable d’environnement nommée Storage1__blobServiceUri peut être utilisée pour informer la propriété blobServiceUri de la connexion. Les propriétés de connexion sont différentes pour chaque service. Reportez-vous à la documentation du composant qui utilise la connexion.

Notes

Lorsque vous utilisez Azure App Configuration ou Key Vault pour fournir des paramètres pour les connexions d’identité managée, les noms de paramètres doivent utiliser un séparateur de clé valide tel que : ou / à la place de __ pour s’assurer que les noms sont résolus correctement.

Par exemple : Storage1:blobServiceUri.

Configurer une connexion basée sur une identité

Dans Azure Functions, certaines connexions peuvent être configurées pour utiliser une identité plutôt qu’un secret. La prise en charge dépend de l’extension qui utilise la connexion. Dans certains cas, une chaîne de connexion peut toujours être nécessaire dans Functions, même si le service auquel vous vous connectez prend en charge les connexions basées sur une identité. Pour obtenir un tutoriel sur la configuration de vos applications de fonction avec des identités managées, consultez le tutoriel sur la création d’une application de fonction avec des connexions basées sur l’identité.

Remarque

Lors de l’exécution dans un plan Consommation ou Élastique Premium, votre application utilise les paramètres WEBSITE_AZUREFILESCONNECTIONSTRING et WEBSITE_CONTENTSHARE lors de la connexion à Azure Files sur le compte de stockage utilisé par votre application de fonction. 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

Les composants suivants prennent en charge les connexions basées sur l’identité :

Source de connexion Plans pris en charge En savoir plus
Déclencheurs et liaisons d’objets blob Azure Tous Extension Objets blob Azure version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Déclencheurs et liaisons de Files d’attente Azure Tous Extension Files d’attente Azure version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Tables Azure (lors de l’utilisation de Stockage Azure) Tous Extension Tables Azure version 1.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Azure SQL Database Tous Connecter une application de fonction à Azure SQL avec une identité managée et des liaisons SQL
Déclencheurs et liaisons Azure Event Hubs Tous Extension Azure Event Hubs version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Déclencheurs et liaisons Azure Service Bus Tous Extension Azure Service Bus version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Liaison de sortie Azure Event Grid Tous Extension Azure Event Grid version 3.3.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Déclencheurs et liaisons Azure Cosmos DB Tous Version 4.0.0 et ultérieures de l’extension Azure Cosmos DB
Version 4.0.2 et ultérieures du pack d’extensions
Déclencheurs et liaisons Azure SignalR Tous Extension Azure SignalR version 1.7.0 ou ultérieure
Pack d’extensions version 3.6.1 et ultérieures
Fournisseur de stockage Durable Functions (Stockage Azure) Tous Extension Durable Functions version 2.7.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Stockage exigé par l’hôte (« AzureWebJobsStorage ») Tous Connexion au stockage hôte avec une identité

Quand elles sont hébergées dans le service Azure Functions, les connexions basées sur une identité utilisent une identité managée. L’identité attribuée par le système est utilisée par défaut, bien qu’une identité attribuée par l’utilisateur puisse être spécifiée avec les propriétés credential et clientID. Notez que la configuration d’une identité affectée par l’utilisateur avec un ID de ressource n’est pas prise en charge. Lors d’une exécution dans d’autres contextes, tels que le développement local, votre identité de développeur est utilisée à la place, même si cela peut être personnalisé. Consultez Développement local avec connexions basées sur une identité.

Accorder l’autorisation à l’identité

Quelle que soit l’identité utilisée, elle doit avoir les autorisations nécessaires pour effectuer les actions prévues. Pour la plupart des services Azure, cela signifie que vous devez attribuer un rôle dans Azure RBAC en utilisant des rôles intégrés ou personnalisés qui fournissent ces autorisations.

Important

Parmi les autorisations exposées par le service cible, certaines ne sont peut-être pas nécessaires pour tous les contextes. Dans la mesure du possible, adhérez au principe du privilège minimum, en accordant à l’identité uniquement les privilèges nécessaires. Par exemple, si l’application a juste besoin de pouvoir lire à partir d’une source de données, utilisez un rôle qui a uniquement l’autorisation de lecture. Il serait inapproprié d’attribuer un rôle qui autorise aussi l’écriture dans ce service, car ce serait une autorisation excessive pour une opération de lecture. De même, vous voudrez vous assurer que l’attribution de rôle est limitée aux seules ressources qui doivent être lues.

Choisissez l'un de ces onglets pour en savoir plus sur les autorisations pour chaque composant :

Vous devez créer une attribution de rôle qui donne accès à votre conteneur d’objets blob au moment de l’exécution. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Le tableau suivant présente les rôles intégrés qui sont recommandés lors de l’utilisation de l’extension Stockage Blob dans le cadre d’un fonctionnement normal. Il est possible que votre application nécessite des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison Exemples de rôles intégrés
Déclencheur Propriétaire des données Blob du stockage et Contributeur aux données en file d’attente du stockage1

Des autorisations supplémentaires doivent également être accordées à la connexion AzureWebJobsStorage.2
Liaison d’entrée Lecteur des données blob du stockage
Liaison de sortie Propriétaire des données Blob du stockage

1 Le déclencheur Blob gère l’échec sur plusieurs tentatives en écrivant des blobs incohérents dans une file d’attente sur le compte de stockage spécifié par la connexion.

2 La connexion AzureWebJobsStorage est utilisée en interne pour les blobs et les files d’attente qui activent le déclencheur. Si elle est configurée de manière à utiliser une connexion basée sur une identité, elle a besoin d’autorisations supplémentaires au-delà de la spécification par défaut. Ces autorisations requises sont couvertes par les rôles Propriétaire des données Blob du stockage, Contributeur aux données en file d’attente du stockage et Contributeur de compte de stockage. Pour en savoir plus, consultez Connexion au stockage hôte avec une identité.

Propriétés courantes pour les connexions basées sur une identité

Une connexion basée sur une identité pour un service Azure accepte les propriétés courantes suivantes, où <CONNECTION_NAME_PREFIX> est la valeur de votre propriété connection dans la définition de déclencheur ou de liaison :

Propriété Modèle de variable d’environnement Description
Informations d’identification du jeton <CONNECTION_NAME_PREFIX>__credential Définit la façon dont un jeton doit être obtenu pour la connexion. Ce paramètre doit être défini sur managedidentity si votre fonction Azure déployée utilise l’authentification de l’identité managée. Cette valeur n’est valide que lorsqu’une identité managée est disponible dans l’environnement d’hébergement.
ID client <CONNECTION_NAME_PREFIX>__clientId Lorsque credential a pour valeur managedidentity, cette propriété permet de spécifier l’identité attribuée par l’utilisateur qui doit être utilisée pour obtenir un jeton. La propriété accepte un ID client correspondant à une identité attribuée par l’utilisateur affectée à l’application. Il incorrect de spécifier à la fois un ID de la ressource et un ID client. Par défaut, l’identité affectée par le système est utilisée. Cette propriété est utilisée différemment dans des scénarios de développement local lorsque credential ne doit pas être défini.
ID de ressource <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Lorsque credential a pour valeur managedidentity, cette propriété permet de spécifier l’identifiant de la ressource à utiliser lors de l’obtention d’un jeton. La propriété accepte un identifiant de ressource correspondant à l’ID de la ressource de l’identité managée définie par l’utilisateur. Il n’est pas correct de spécifier à la fois un ID de la ressource et un ID client. Si aucun des deux n’est spécifié, l’identifiant attribué par le système est utilisé. Cette propriété est utilisée différemment dans des scénarios de développement local lorsque credential ne doit pas être défini.

D'autres options peuvent être prises en charge pour un type de connexion donné. Reportez-vous à la documentation du composant qui effectue la connexion.

Développement local avec connexions basées sur une identité

Remarque

Le développement local avec des connexions basées sur l'identité nécessite des versions 4.0.3904 d'Azure Functions Core Tools.

Lorsque vous exécutez un projet de fonction localement, la configuration ci-dessus indique au runtime d’utiliser votre identité de développeur locale. La connexion tente d’obtenir un jeton à partir des emplacements suivants, dans l’ordre :

  • Un cache local partagé entre les applications Microsoft
  • Le contexte utilisateur actuel dans Visual Studio
  • Le contexte utilisateur actuel dans Visual Studio Code
  • Le contexte utilisateur actuel dans Azure CLI

Si aucune de ces options ne fonctionne, une erreur se produit.

Votre identité a peut-être déjà des attributions de rôles pour les ressources Azure utilisées pour le développement, mais ces rôles peuvent ne pas fournir l’accès aux données nécessaire. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Revérifiez quelles autorisations sont nécessaires pour les connexions de chaque composant et vérifiez qu’elles vous sont affectées.

Dans certains cas, vous souhaiterez peut-être spécifier l’utilisation d’une identité différente. Pour la connexion, vous pouvez ajouter des propriétés de configuration qui pointent vers l’identité de substitution en fonction d’un ID client et d’un secret client pour un principal de service Microsoft Entra. Cette option de configuration n’est pas prise en charge quand elle est hébergée dans le service Azure Functions. Pour utiliser un ID et un secret sur votre ordinateur local, définissez la connexion avec les propriétés extra suivantes :

Propriété Modèle de variable d’environnement Description
ID client <CONNECTION_NAME_PREFIX>__tenantId ID du locataire Microsoft Entra (répertoire).
ID client <CONNECTION_NAME_PREFIX>__clientId ID client (application) d’une inscription d’application dans le locataire.
Clé secrète client <CONNECTION_NAME_PREFIX>__clientSecret Un secret client qui a été généré pour l’inscription de l’application.

Voici un exemple de propriétés local.settings.json obligatoires pour une connexion à des objets blob Azure basée sur l’identité :

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

Connexion au stockage hôte avec une identité

L’hôte Azure Functions utilise l’ensemble de connexions au stockage dans AzureWebJobsStorage pour les comportements de base comme la coordination de l’exécution unique de déclencheurs de minuteur et du stockage de clés d’application par défaut. Cette connexion peut également être configurée pour utiliser une identité.

Attention

Dans Functions, d’autres composants reposent sur AzureWebJobsStorage pour les comportements par défaut. Vous ne devez pas les déplacer vers une connexion basée sur une identité si vous utilisez des versions antérieures des extensions qui ne prennent pas en charge ce type de connexion, ce qui inclut les déclencheurs et les liaisons pour les objets blob Azure, Event Hubs et Durable Functions. De même, AzureWebJobsStorage est utilisé pour les artefacts de déploiement lors de l’utilisation de la génération côté serveur dans Linux, et si vous l’activez, vous devrez effectuer le déploiement via AzureWebJobsStorage.

En outre, votre application de fonction peut réutiliser AzureWebJobsStorage pour d’autres connexions au stockage dans leurs déclencheurs, liaisons et/ou code de fonction. Assurez-vous que toutes les utilisations de AzureWebJobsStorage peuvent utiliser le format de connexion basé sur l’identité avant de modifier cette connexion à partir d’une chaîne de connexion.

Pour utiliser une connexion basée sur l’identité pour AzureWebJobsStorage, configurez les paramètres d’application suivants :

Paramètre Description Valeur d'exemple
AzureWebJobsStorage__blobServiceUri URI de plan de données du service BLOB du compte de stockage, utilisant le schéma HTTPS. https://<storage_account_name>.blob.core.windows.net
AzureWebJobsStorage__queueServiceUri URI de plan de données du service File d’attente du compte de stockage, utilisant le schéma HTTPS. https://<storage_account_name>.queue.core.windows.net
AzureWebJobsStorage__tableServiceUri URI de plan de données d’un service Table du compte de stockage, utilisant le schéma HTTPS. https://<storage_account_name>.table.core.windows.net

Il est également possible de définir des propriétés courantes pour les connexions basées sur une identité.

Si vous configurez un compte de stockage AzureWebJobsStorage qui utilise le suffixe DNS et le nom de service par défaut pour Azure global, en respectant le format https://<accountName>.[blob|queue|file|table].core.windows.net, vous pouvez à la place définir AzureWebJobsStorage__accountName sur le nom de votre compte de stockage. Les points de terminaison de chaque service de stockage sont déduits pour ce compte. Cette inférence ne fonctionne quand le compte de stockage se trouve dans un cloud souverain ou s'il a un DNS (Domain Name System) personnalisé.

Paramètre Description Valeur d'exemple
AzureWebJobsStorage__accountName Nom de compte d’un compte de stockage, valide uniquement si le compte n’est pas dans un cloud souverain et n’a pas de DNS personnalisé. Cette syntaxe est unique à AzureWebJobsStorage et ne peut pas être utilisée pour d’autres connexions basées sur l’identité. <storage_account_name>

Vous devrez créer une attribution de rôle qui fournit l’accès au compte de stockage pour « AzureWebJobsStorage » au moment de l’exécution. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Le rôle Propriétaire des données Blob du stockage couvre les besoins de base du stockage d’hôtes de fonctions - L’accès en lecture et en écriture aux objets blob et la capacité à créer des conteneurs sont nécessaires pour l’exécution. Plusieurs extensions utilisent cette connexion comme emplacement par défaut pour les blobs, les files d’attente et les tables, et ces utilisations peuvent ajouter des exigences, comme indiqué dans le tableau ci-dessous. Vous pouvez avoir besoin d’autorisations supplémentaires si vous utilisez « AzureWebJobsStorage » à d’autres fins.

Extension Rôles requis Explication
Aucune extension (hôte uniquement) Propriétaire des données Blob du stockage Utilisé pour la coordination générale, magasin de clés par défaut
Objets Blob Azure (déclencheur uniquement) La totalité de :
Contributeur de compte de stockage,
Propriétaire des données Blob du stockage,
Contributeur aux données en file d’attente du stockage
Le déclencheur blob utilise en interne les files d’attente Azure et écrit les reçus d’objets blob. Il utilise AzureWebJobsStorage, quelle que soit la connexion configurée pour le déclencheur.
Azure Event Hubs (déclencheur uniquement) (aucune modification par rapport à l’exigence par défaut)
Propriétaire des données Blob du stockage
Les points de contrôle sont conservés dans les objets blob à l’aide de la connexion AzureWebJobsStorage.
Déclencheur de minuteur (aucune modification par rapport à l’exigence par défaut)
Propriétaire des données Blob du stockage
Pour garantir une exécution par événement, les verrous sont pris avec les objets blob à l’aide de la connexion AzureWebJobsStorage.
Fonctions durables La totalité de :
Contributeur aux données Blob du stockage,
Contributeur aux données en file d’attente du stockage,
Contributeur aux données de table du stockage
Durable Functions utilise des objets blob, des files d’attente et des tables pour coordonner les fonctions d’activité et maintenir l’état de l’orchestration. Il utilise la connexion AzureWebJobsStorage pour tous ces paramètres par défaut, mais vous pouvez spécifier une autre connexion dans la configuration de l’extension de Durable Functions.

Problèmes liés aux rapports

Élément Description Lien
Runtime Hôte script, déclencheurs et liaisons, prise en charge linguistique Signaler un problème
Modèles Problèmes de code avec le modèle de création Signaler un problème
Portail Problème d'interface utilisateur ou d'expérience Signaler un problème

Référentiels open source

Le code d'Azure Functions est open source ; vous pouvez trouver des composants clés dans ces référentiels GitHub :

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :