Guide du développeur Azure Functions

Article
09/22/2023

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.

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é :

Visual Studio

Visual Studio Code
Azure Functions Core Tools (invite de commandes)

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.

La modification du portail est prise en charge uniquement pour Python version 1, 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 :

Lors de la publication de Microsoft Visual studio

Utilisation de Visual Studio Code
Par programmation à l'aide d'Azure CLI, d'Azure PowerShell, de modèles ARM ou de modèles Bicep
Dans le portail Azure :

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.

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 chiffrés et sont accessibles lors du runtime par votre application en tant que paires de variables d'environnement namevalue. 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 d’objet Blob de stockageetContributeur aux données en file d’attente du stockage¹ Des autorisations supplémentaires doivent également être accordées à la connexion AzureWebJobsStorage.²
Liaison d’entrée	Lecteur des données blob du stockage
Liaison de sortie	Propriétaire des données Blob du stockage

¹ 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.

² 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é.

Vous devrez créer une attribution de rôle qui donne accès à votre file d’attente 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 File d’attente dans le cadre d’un fonctionnement normal. Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison	Exemples de rôles intégrés
Déclencheur	Lecteur de données en file d’attente du stockage, Processeur de messages de données en file d’attente du stockage
Liaison de sortie	Contributeur aux données en file d’attente du stockage, Expéditeur de messages de données en file d’attente du stockage

Vous devez créer une attribution de rôle qui donne accès à votre service de table Stockage Azure 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 quand vous utilisez l’extension Tables Azure sur Stockage Azure dans le cadre d’un fonctionnement normal. Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison	Exemples de rôles intégrés (Stockage Azure¹)
Liaison d’entrée	Lecteur de données de table du stockage
Liaison de sortie	Contributeur aux données de table du stockage

¹ Si votre application se connecte à des tables dans Azure Cosmos DB for Table, l’utilisation d’une identité n’est pas prise en charge et la connexion doit utiliser une chaîne de connexion.

Vous devrez créer une attribution de rôle qui donne accès à votre Event Hub au moment de l’exécution. L’étendue de l’attribution de rôle peut être pour un espace de noms Event Hubs, ou pour le Event Hub lui-même. 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 Event Hubs dans le cadre d’un fonctionnement normal. Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison	Exemples de rôles intégrés
Déclencheur	Récepteur de données Azure Event Hubs, Propriétaire de données Azure Event Hubs
Liaison de sortie	Expéditeur de données Azure Event Hubs

Vous devrez créer une attribution de rôle qui donne accès à vos rubriques et files d’attente 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 Service Bus dans le cadre d’un fonctionnement normal. Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison	Exemples de rôles intégrés
Déclencheur¹	Récepteur de données Azure Service Bus, Propriétaire de données Azure Service Bus
Liaison de sortie	Expéditeur de données Azure Service Bus

¹ Pour le déclenchement à partir de rubriques Service Bus, l’attribution de rôle doit avoir une étendue effective sur la ressource d’abonnement Service Bus. Si seule la rubrique est incluse, une erreur se produit. Certains clients, tels que le Portail Azure, n’exposent pas la ressource d’abonnement Service Bus en tant qu’étendue pour l’attribution de rôle. En pareil cas, Azure CLI peut être utilisé à la place. Pour plus d’informations, consultez Rôles Azure intégrés pour Azure Service Bus.

Vous devez créer une attribution de rôle qui donne accès à votre rubrique Event Grid 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 Event Hubs dans le cadre d’un fonctionnement normal. Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison	Exemples de rôles intégrés
Liaison de sortie	Contributeur EventGrid, expéditeur de données EventGrid

Cosmos DB n’utilise pas Azure RBAC pour les opérations de données. Au lieu de cela, il utilise un système RBAC intégré à Cosmos DB qui repose sur des concepts similaires. Vous devrez créer une attribution de rôle qui donne accès à votre compte de base de données au moment de l’exécution. Les rôles de gestion Azure RBAC 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 Azure Cosmos DB dans le cadre d’un fonctionnement normal. Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez.

Type de liaison	Exemples de rôles intégrés¹
Déclencheur²	Contributeur de données intégré Cosmos DB
Liaison d’entrée	Lecteur de données intégré Cosmos DB
Liaison de sortie	Contributeur de données intégré Cosmos DB

¹ Ces rôles ne peuvent pas être utilisés dans une attribution de rôle Azure RBAC. Pour plus d’informations sur l’attribution de ces rôles, consultez la documentation du Système RBAC intégré à Cosmos DB.

² Lors de l’utilisation de l’identité, Cosmos DB traite la création de conteneurs comme une opération de gestion. Il n’est pas disponible en tant qu’opération de plan de données pour le déclencheur. Vous devez vous assurer de créer les conteneurs nécessaires au déclencheur (y compris le conteneur de bail) avant de configurer votre fonction.

Vous devrez créer une attribution de rôle qui donne accès à votre stockage Azure au moment de l’exécution. Les rôles de gestion comme Propriétaire ne sont pas suffisants. Les rôles intégrés suivants sont recommandés lors de l’utilisation de l’extension Durable Functions pour un fonctionnement normal :

Votre application peut nécessiter des autorisations supplémentaires en fonction du code que vous écrivez. Si vous utilisez le comportement par défaut ou si vous définissez explicitement connectionName sur « AzureWebJobsStorage », consultez Connexion au stockage hôte avec une identité pour d’autres considérations relatives aux autorisations.

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.

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 la connexion de stockage définie AzureWebJobsStorage pour activer les comportements de base tels que la coordination de l’exécution singleton des déclencheurs de minuteur et le stockage par défaut de clé d’application. 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 de 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>

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