Partage 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 préféré. Cet article est spécifique à une langue. 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 vue d'ensemble Azure Functions.

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

Si vous préférez vous lancer directement, vous pouvez suivre un didacticiel 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 didacticiel de démarrage rapide à l’aide de Visual Studio Code ou à partir de l’invite de commandes commande.

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

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

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

Projet de code

Au cœur de Azure Functions est un projet de code spécifique au langage qui implémente une ou plusieurs unités d’exécution de code appelées functions. Les fonctions sont simplement des méthodes qui s’exécutent dans le cloud Azure en fonction des événements, en réponse aux requêtes HTTP ou selon une planification. Considérez votre projet de code Azure Functions comme un mécanisme permettant d'organiser, de déployer et de gérer collectivement 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 des conseils spécifiques au langage, consultez le guide Java développeurs.

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 des conseils spécifiques au langage, consultez le guide Python développeurs.

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 Azure Functions concepts de déclencheurs et de liaisons.

Azure Functions fournit un ensemble de modèles de projet et de fonction spécifiques au langage qui facilitent la création de nouveaux projets de code et l’ajout de fonctions à votre projet. Vous pouvez utiliser l’un des outils qui prennent en charge Azure Functions développement pour générer de nouvelles applications et fonctions à l’aide de ces modèles.

Outils de développement

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

  • Éclipse

  • Gradle

  • IntelliJ IDEA

  • Quarkus

  • Spring Cloud

Ces outils s’intègrent à Azure Functions Core Tools pour pouvoir exécuter et déboguer sur votre ordinateur local à l’aide du runtime Functions. Pour plus d’informations, consultez Codez et testez 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 dans le 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 Azure Ressource, une application de fonction équivaut à une ressource de site (Microsoft.Web/sites) dans Azure App Service, ce qui équivaut à une application web.

Un conteneur de fonctions 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 les autres ressources requises n'existent pas déjà 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 à des 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 Azure Functions concepts de déclencheurs et de liaisons.

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

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

En tant que meilleure pratique de sécurité, Azure Functions tire parti des fonctionnalités des paramètres d’application de Azure App Service pour vous aider à stocker plus en toute sécurité des chaînes, des clés et d’autres jetons nécessaires pour se connecter à d’autres services. Les paramètres d’application dans Azure sont stockés et sont accessibles au moment de l’exécution par votre application en tant que variable d’environnement namevalue paires. 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 du chaîne de connexion réel. 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é . Au lieu de la chaîne de connexion, vous définissez connection sur le nom d’une variable d’environnement qui contient le 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 application lors de l’exécution dans le Azure et dans le fichier de paramètres local lors du développement localement.

Valeurs de connexion

Lorsque le nom de connexion est résolu en une seule valeur exacte, le runtime identifie la valeur en tant que chaîne de connexion, qui inclut généralement un secret. Les détails d’un chaîne de connexion dépendent du service auquel vous vous connectez.

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 d’objet blob Azure peut être Storage1. Tant qu’aucune valeur de chaîne unique n’est configurée par une variable d’environnement nommée , une variable d’environnement nommée peut être utilisée pour informer la propriété 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.

Remarque

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

Par exemple : .

Configurer une connexion basée sur une identité

Certaines connexions dans Azure Functions peuvent être configurées pour utiliser une identité au lieu d’un secret. La prise en charge dépend de la version du runtime et de l’extension qui utilise la connexion. Dans certains cas, une chaîne de connexion peut toujours être requise dans Functions même si le service auquel vous vous connectez prend en charge les connexions basées sur des identités. 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 Elastic 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 Azure Files scénarios d’authentification pris en charge

Les connexions basées sur l’identité sont uniquement prises en charge sur Functions 4.x. Si vous utilisez la version 1.x, vous devez d’abord migrer vers la version 4.x.

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

Source de connexion Plans pris en charge En savoir plus
Azure déclencheurs et liaisons d’objets blob Tous Azure extension Blobs version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Azure déclencheurs et liaisons file d’attente Tous Azure extension Files d’attente 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 Azure Extension Tables 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 pour Azure SQL avec des liaisons d’identité managée et SQL
Azure Event Hubs déclencheurs et liaisons Tous Azure Event Hubs extension version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Azure Service Bus déclencheurs et liaisons Tous Azure Service Bus extension version 5.0.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
liaison de sortie Azure Event Grid Tous Azure Event Grid extension version 3.3.0 ou ultérieure,
Pack d’extensions 3.3.0 ou version ultérieure
Azure Cosmos DB déclencheurs et liaisons Tous Azure Cosmos DB extension version 4.0.0 ou ultérieure,
Version 4.0.2 et ultérieures du pack d’extensions
Azure déclencheurs et liaisons SignalR Tous Azure extension SignalR version 1.7.0 ou ultérieure
Pack d’extensions version 3.6.1 et ultérieures
Azure Web PubSub déclencheurs et liaisons Tous Azure Web PubSub extension version 1.10.0 ou ultérieure
Pack d’extensions version 3.6.1 et ultérieures
fournisseur de stockage Durable Functions (stockage Azure) Tous Durable Functions extension 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é

Lorsqu’elles sont hébergées dans le service Azure Functions, les connexions basées sur des identités utilisent une identité 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 et . 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 assigner un rôle dans Azure RBAC, à l’aide de 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 en 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 Propriétaire des données d’objet Blob de stockageetContributeur aux données en file d’attente du stockage1

Des autorisations supplémentaires doivent également être accordées à la connexion AzureWebJobsStorage2.
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 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 l’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 Descriptif
Informations d’identification du jeton <CONNECTION_NAME_PREFIX>__credential Cette propriété détermine la façon dont un jeton doit être obtenu pour la connexion. La propriété ne doit pas être définie dans les scénarios de développement locaux. Lorsque vous envisagez d’utiliser l’authentification d’identité managée, définissez cette propriété sur . Lorsque vous envisagez de vous connecter à une ressource dans un autre domaine, utilisez plutôt .
ID client <CONNECTION_NAME_PREFIX>__clientId Lorsque a pour valeur , 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 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 les scénarios interlocataires. Consultez la section scénarios interlocataires .

Cette propriété est utilisée différemment dans des scénarios de développement local lorsque ne doit pas être défini.
ID de ressource <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Lorsque a pour valeur , 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 identificateur de ressource correspondant à une identité assignée par l'utilisateur à l'application. 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é.

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

variables d’environnement Kit de développement logiciel (SDK) Azure

Attention

L'utilisation des variables d'environnement EnvironmentCredential de la Kit de développement logiciel (SDK) Azure n'est pas recommandée en raison de l'impact potentiellement involontaire sur d'autres connexions. Ils ne sont pas entièrement pris en charge lors du déploiement sur Azure Functions.

Les variables d'environnement associées au EnvironmentCredential du Kit de développement logiciel (SDK) Azure peuvent également être définies, mais elles ne sont pas traitées par le service Functions pour la mise à l'échelle dans les plans consommation. Ces variables d’environnement ne sont pas spécifiques à une connexion et s’appliquent par défaut, sauf si une propriété correspondante n’est pas définie pour une connexion donnée. Par exemple, si était défini, il serait utilisé comme si avait été configuré. La définition explicite de remplacerait cette valeur par défaut.

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

Remarque

Le développement local avec des connexions basées sur des identités nécessite la version 4.0.3904 de Azure Functions Core Tools ou une version ultérieure.

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
  • Contexte utilisateur actuel dans Visual Studio
  • Contexte utilisateur actuel dans Visual Studio Code
  • Contexte utilisateur actuel dans le Azure CLI

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

Votre identité peut déjà avoir des attributions de rôles sur Azure ressources 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. Vous pouvez ajouter des propriétés de configuration pour la connexion qui pointent vers l’autre identité 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 lorsqu’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 Descriptif
ID client <CONNECTION_NAME_PREFIX>__tenantId ID de locataire (répertoire) Microsoft Entra.
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 requises pour la connexion basée sur l'identité aux objets blob Azure :

{
  "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 dans AzureWebJobsStorage pour activer les comportements de base tels que la coordination de l’exécution singleton des déclencheurs du 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 pour les comportements par défaut. Vous ne devez pas le déplacer vers une connexion basée sur l’identité si vous utilisez des versions antérieures d’extensions qui ne prennent pas en charge ce type de connexion, y compris les déclencheurs et les liaisons pour les objets blob Azure, Event Hubs et Durable Functions. De même, 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 un package de déploiement externe.

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

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

Paramètre Descriptif 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://nom_compte_stockage.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 AzureWebJobsStorage à l'aide d'un compte de stockage qui utilise le suffixe DNS et le nom de service par défaut pour le Azure global, en suivant le format https://<accountName>.[blob|queue|file|table].core.windows.net, vous pouvez définir à la place 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 Descriptif 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 à et ne peut pas être utilisée pour d’autres connexions basées sur l’identité. nom_du_compte_de_stockage

Vous devez 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 également avoir besoin d’autres autorisations 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 Les fonctions utilisent le stockage blob pour la coordination générale et comme magasin de clés par défaut.

Ce scénario représente le jeu minimal d’autorisations pour l’opération normale, mais il n’inclut pas la prise en charge des événements de diagnostic1.
No extension (host only), with support for diagnostic events1Aucune extension (hôte uniquement), avec prise en charge des événements de diagnostic 1 Propriétaire des données Blob du stockage,
Contributeur aux données de table du stockage		 Les événements de diagnostic sont conservés dans le stockage de tables à l’aide de la connexion AzureWebJobsStorage.
Azure Blobs (déclencheur uniquement) Tout :
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 d’objet blob utilise en interne Azure Files d’attente et écrit des reçus blob. Il utilise la connexion AzureWebJobsStorage à ces fins, 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.
Durable Functions Tout :
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 d’orchestration. Il utilise la connexion AzureWebJobsStorage par défaut, mais vous pouvez spécifier une autre connexion dans la configuration de l’extension Durable Functions.

1 Pour certains types de problèmes, Azure Functions pouvez déclencher un événement de diagnostic qui peut faciliter la résolution des problèmes, même lorsque le problème empêche le démarrage de l’application de fonction. Si le contributeur aux données de table de stockage n’est pas affecté, vous pouvez voir des avertissements dans vos journaux sur l’incapacité d’écrire ces événements.

Connexion à une ressource dans un autre client

Si votre fonction doit se connecter à une ressource dans un autre locataire Microsoft Entra, votre connexion doit utiliser des informations d’identification d’identité federated identity. Cela nécessite une identité managée affectée par l’utilisateur et une inscription d’application Entra ID multilocataire. Vous ne pouvez pas utiliser une identité managée affectée par le système pour les connexions entre locataires.

Important

Lorsque vous configurez un déclencheur pour une connexion entre locataires dans les types de plan Consommation ou Flex Consumption, la plateforme ne met plus à l’échelle l’application de fonction en fonction de ce déclencheur.

Pour configurer une connexion basée sur une identité interlocataire, vous devez d’abord configurer votre infrastructure en procédant comme suit :

  1. Dans le locataire où votre application de fonctions est déployée, créez une identité managée assignée par l'utilisateur.
  2. Affectez cette identité à l’application de fonction.
  3. Dans le même locataire, créez une inscription d’application Entra mutualisée qui représente la ressource interlocataire à laquelle vous souhaitez accéder.
  4. Ajoutez l'identité gérée en tant qu'identité fédérée dans l'enregistrement de l'application.
  5. Dans le locataire où la ressource est déployée, créez une application d’entreprise pour l’enregistrement de l’application.
  6. Attribuez des autorisations pour l’application d’entreprise pour accéder à la ressource.

Une connexion basée sur l'identité inter-locataire utilise les propriétés suivantes, où est la valeur de la propriété dans la définition du déclencheur ou du liant :

Propriété Modèle de variable d’environnement Descriptif
Informations d’identification du jeton <CONNECTION_NAME_PREFIX>__credential Obligatoire. Lorsque vous vous connectez à une ressource dans un autre locataire, définissez cette propriété sur .
Azure Cloud <CONNECTION_NAME_PREFIX>__azureCloud Obligatoire. Cette propriété détermine l’environnement cloud Azure. Les valeurs autorisées sont « publiques » pour Azure cloud public, « usgov » pour Azure US Government Cloud et « chine » pour Azure exploitées par 21Vianet.
ID client <CONNECTION_NAME_PREFIX>__clientId Obligatoire. Quand est défini sur , définissez cette propriété sur l'ID client (ID d'application) de l'inscription de l'application.

Cette propriété est utilisée différemment dans les connexions basées sur une identité monolocataire. Consultez la section propriétés courantes .

Cette propriété est utilisée différemment dans des scénarios de développement local lorsque ne doit pas être défini.
ID client <CONNECTION_NAME_PREFIX>__tenantId Obligatoire. Quand est défini sur , définissez cette propriété sur l'ID de locataire de la ressource.

Cette propriété est utilisée différemment dans des scénarios de développement local lorsque ne doit pas être défini.
ID client d’identité gérée <CONNECTION_NAME_PREFIX>__managedIdentityClientId Quand est défini sur , cette propriété spécifie l'identité attribuée par l'utilisateur que vous avez configurée en tant qu'informations d'identification de l'identité fédérée et attribuée à l'application.1 La propriété accepte un ID client correspondant à cette identité attribuée par l'utilisateur.
ID d’objet de l’identité managée <CONNECTION_NAME_PREFIX>__managedIdentityObjectId Quand est définie , cette propriété spécifie l'identité attribuée par l'utilisateur que vous avez configurée en tant qu'identité fédérée et attribuée à l'application.1 La propriété accepte un ID d'objet (ID principal) correspondant à cette identité attribuée par l'utilisateur.
ID de ressource d'identité gérée <CONNECTION_NAME_PREFIX>__managedIdentityResourceId Lorsque est défini sur , cette propriété spécifie l'identité assignée par l'utilisateur que vous avez configurée en tant qu'identité d'informations d'identité fédérée et assignée à l'application.1 La propriété accepte un identifiant de ressource correspondant à cette identité assignée par l'utilisateur.

1 Lorsque est définie à , votre connexion doit spécifier exactement l’un des , , ou .

Cela est également documenté par le Kit de développement logiciel (SDK) Azure dans un format JSON.

Problèmes liés aux rapports

Élément Descriptif Lien
Temps d'exécution Hôte script, déclencheurs et liaisons, prise en charge linguistique Fichier un problème
Modèles Problèmes de code avec le modèle de création Fichier un problème

Référentiels open source

Le code de Azure Functions est open source, et vous pouvez trouver des composants clés dans ces référentiels GitHub :

Étapes suivantes

Pour plus d’informations, consultez les ressources suivantes :

  • Last updated on