Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Ce démarrage rapide montre comment configurer une application Durable Functions pour utiliser des connexions basées sur l’identité soit pour le backend de Durable Task Scheduler, soit pour le fournisseur stockage Azure. La plateforme Azure gère une identité gérée depuis Microsoft Entra ID – vous n'avez pas besoin de provisionner ou de faire tourner des secrets.
Ce chemin suppose que votre application est déjà configurée pour utiliser le backend du Durable Task Scheduler. Si votre application utilise toujours le fournisseur stockage Azure, choisissez le chemin stockage Azure dans cet article.
Dans cet article :
- Configuration du développement local : utiliser Azurite ou vos informations d’identification de développeur pour les tests locaux
- Connexions basées sur l'identité pour l'application déployée sur Azure : activez une identité managée et configurez votre fonction
Note
L’identité managée est prise en charge dans Durable Functions extension versions 2.7.0 et ultérieures.
Si vous n’avez pas de compte Azure, créez un compte gratuit avant de commencer.
Prerequisites
Pour effectuer ce démarrage rapide, les éléments suivants sont requis :
- Projet de Durable Functions existant créé dans le portail Azure ou un projet de Durable Functions local déployé sur Azure.
- Connaissance de l’exécution d’une application Durable Functions dans Azure.
Si vous n'avez pas de projet Durable Functions existant déployé dans Azure, nous vous recommandons de commencer par l'un des guides de démarrage rapide suivants :
- Création d’une première fonction durable – C#
- Création d’une première fonction durable – JavaScript
- Créer votre première fonction durable - Python
- Création d’une première fonction durable – PowerShell
- Créer votre première fonction durable - Java
Configuration du développement local
Vous avez deux options pour le développement local. Utilisez l’émulateur local Durable Task Scheduler pour des tests rapides sans identifiants Azure. Si vous devez tester des connexions basées sur l’identité avec une ressource en direct du planificateur, utilisez plutôt vos identifiants de développeur.
Option 1 : Utiliser l’émulateur local Durable Task Scheduler
Lorsque vous développez localement, utilisez l’émulateur Durable Task Scheduler afin de pouvoir tester votre application sans identifiants Azure. Configurez les paramètres de votre application pour qu’ils pointent vers l’émulateur et utilisez le hub des tâches par défaut.
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"DTS_CONNECTION_STRING": "Endpoint=http://localhost:8080;TaskHub=default;Authentication=None",
"TASKHUB_NAME": "default"
}
}
Option 2 : Connexions basées sur l’identité pour le développement local
Strictement parlant, une identité gérée n’est disponible que pour les applications lors de l’exécution sous Azure. Cependant, vous pouvez toujours configurer une application en fonctionnement local pour utiliser des connexions basées sur l’identité en utilisant vos identifiants développeur pour vous authentifier avec votre ressource de planificateur. Ensuite, une fois déployée sur Azure, l’application utilise la configuration d’identité managée à la place.
Lorsque vous utilisez des identifiants développeur, la connexion tente d’obtenir un jeton depuis les emplacements suivants, dans cet 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 réussit, vous obtenez une erreur indiquant que l’application ne peut pas récupérer un jeton d’authentification. Vérifiez que vous êtes connecté à l’un des outils listés avec un compte ayant accès à votre ressource de planificateur.
Configurer le runtime pour utiliser l’identité du développeur local
Dans vos paramètres locaux, définissez le point de terminaison du planificateur et utilisez
Authentication=DefaultAzurepour que l’application utilise vos identifiants de développeur.{ "IsEncrypted": false, "Values": { "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated", "AzureWebJobsStorage": "UseDevelopmentStorage=true", "DTS_CONNECTION_STRING": "Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=DefaultAzure", "TASKHUB_NAME": "<your-task-hub>" } }Attribuez à votre identité de développeur le rôle
Durable Task Data Contributorsur la ressource Scheduler ou sur la portée spécifique du hub de tâches.
Connexions basées sur des identités pour l’application déployée sur Azure
Activer une ressource d’identité managée
Activez une identité gérée pour votre application de fonction. Votre application de fonction doit avoir une identité managée affectée par le système ou une identité managée affectée par l’utilisateur(-trice). Pour activer une identité managée pour votre application de fonction et pour en savoir plus sur les différences entre les deux types d’identités, voir la présentation de l’identité managée.
Attribuer des rôles d’accès à l’identité managée
Naviguez vers votre ressource de planificateur dans le portail Azure et attribuez le Durable Task Data Contributor rôle à votre identité gérée. Pour un accès à privilèges minimum, attribuez le rôle à l’échelle du hub des tâches plutôt qu’à l’ensemble du planificateur. Si vous utilisez une identité attribuée par l’utilisateur, sélectionnez Identité gérée puis + Select les membres.
Ajouter la configuration d’identité managée à votre application
Avant de pouvoir utiliser l’identité managée de votre application, apportez des modifications aux paramètres de l’application :
Dans le portail Azure, dans le menu des ressources de votre application de fonction, sous Settings, sélectionnez Variables de l’environnement.
Ajoutez ou mettez à jour le
DTS_CONNECTION_STRINGparamètre pour que l’application se connecte à votre planificateur en utilisant l’identité gérée de l’application.Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=ManagedIdentitySi vous utilisez une identité managée attribuée par l’utilisateur, incluez l’ID client dans la chaîne de connexion :
Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=ManagedIdentity;ClientID=<your-user-assigned-identity-client-id>Ajoutez ou mettez à jour le
TASKHUB_NAMEparamètre avec le même nom du centre des tâches.Si votre hôte de fonction a besoin d’stockage Azure pour les opérations au niveau hôte, configurez
AzureWebJobsStorageséparément. Le back-end du planificateur utilise la chaîne de connexion DTS plutôt queAzureWebJobsStoragepour l’état Durable.
Vérifier votre configuration
Pour confirmer que votre configuration d’identité managée fonctionne :
- Dans le portail Azure, allez dans votre application de fonctions et déclenchez votre orchestration Durable Functions.
- Vérifiez que l’orchestration s’achève correctement en interrogeant le point de terminaison d’état ou en vérifiant l’onglet Surveillance.
- Si vous voyez des erreurs d’authentification, vérifiez que :
- L’identité managée dispose du rôle
Durable Task Data Contributorsur la ressource du planificateur ou dans la portée du hub de tâches. - Les
DTS_CONNECTION_STRINGréglages etTASKHUB_NAMEsont corrects. - L’application utilise l’identité attendue lors de l’exécution sous Azure.
- L’identité managée dispose du rôle
Configuration du développement local
Vous avez deux options pour le développement local. Utilisez Azurite pour effectuer des tests locaux rapides sans Azure informations d’identification. Si vous devez tester des connexions basées sur des identités par rapport à un compte de stockage Azure réel, utilisez plutôt vos informations d’identification de développeur.
Option 1 : Utiliser l’émulateur de stockage Azure
Lorsque vous développez localement, il est recommandé d'utiliser Azurite, qui est l'émulateur local de stockage Azure. Configurez votre application sur l’émulateur en spécifiant "AzureWebJobsStorage": "UseDevelopmentStorage=true" dans le local.settings.json.
Option 2 : Connexions basées sur l’identité pour le développement local
Strictement, une identité managée est uniquement disponible pour les applications lors de l’exécution sur Azure. Toutefois, vous pouvez toujours configurer une application en cours d’exécution locale pour utiliser la connexion basée sur l’identité à l’aide de vos informations d’identification de développeur pour vous authentifier auprès de Azure ressources. Ensuite, lorsqu’elle est déployée sur Azure, l’application utilise plutôt votre configuration d’identité managée.
Lorsque vous utilisez les informations d’identification du développeur, la connexion tente d’obtenir un jeton à partir des emplacements suivants, dans cet 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 réussit, vous obtenez une erreur indiquant que l’application ne peut pas récupérer un jeton d’authentification. Vérifiez que vous êtes connecté à l'un des outils répertoriés avec un compte qui a accès à votre compte stockage Azure.
Configurer le runtime pour utiliser l’identité du développeur local
Spécifiez le nom de votre compte stockage Azure dans local.settings.json, par exemple :
{ "IsEncrypted": false, "Values": { "AzureWebJobsStorage__accountName": "<<your Azure Storage account name>>", "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated" } }Accédez à votre ressource de compte stockage Azure dans le portail Azure.
Sélectionnez l’onglet Access Control (IAM), puis sélectionnez Add role assignment.
Attribuez chacun des rôles suivants à vous-même. Pour chaque rôle, sélectionnez « + Sélectionner des membres » et recherchez l’e-mail que vous utilisez pour vous connecter à Visual Studio, Visual Studio Code ou le Azure CLI.
- Contributeur aux données de queue de stockage
- Contributeur aux données du Blob de stockage
- Contributeur aux données de la table de stockage
Note
Il s’agit des trois rôles requis pour votre identité managée lors du déploiement sur Azure. Consultez Attribuer des rôles d’accès à l’identité managée.
Connexions basées sur des identités pour l’application déployée sur Azure
Activer une ressource d’identité managée
Pour commencer, activez une identité managée pour votre application. Votre application de fonction doit avoir une identité managée affectée par le système ou une identité managée affectée par l’utilisateur(-trice). Pour activer une identité managée pour votre application de fonction et pour en savoir plus sur les différences entre les deux types d’identités, voir la présentation de l’identité managée.
Attribuer des rôles d’accès à l’identité managée
Accédez à la ressource stockage Azure de votre application sur le portail Azure et attribuez trois rôles de contrôle d'accès basé sur un rôle (RBAC) à votre identité managée :
- Contributeur aux données de queue de stockage
- Contributeur aux données du Blob de stockage
- Contributeur aux données de la table de stockage
Pour trouver votre ressource d’identité, sélectionnez Attribuer l’accès à l’Identité managée, puis + Sélectionner des membres
Ajouter la configuration d’identité managée à votre application
Avant de pouvoir utiliser l’identité managée de votre application, apportez des modifications aux paramètres de l’application :
Dans le portail Azure, dans le menu des ressources de votre application de fonction, sous Settings, sélectionnez Variables de l’environnement.
Dans la liste des paramètres, recherchez AzureWebJobsStorage, puis sélectionnez l’icône Supprimer.
Ajoutez un paramètre pour lier votre compte de stockage Azure à l’application.
Utilisez l’une des méthodes suivantes en fonction du cloud dans lequel votre application s’exécute :
Azure cloud : si votre application s’exécute dans global Azure, ajoutez le paramètre
AzureWebJobsStorage__accountNamequi identifie un nom de compte de stockage Azure. Exemple de valeur :mystorageaccount123Cloud hors Azure : Si votre application s'exécute dans un cloud en dehors d'Azure, vous devez ajouter les trois paramètres suivants pour fournir des URI de service spécifiques (ou endpoints) du compte de stockage au lieu d'un nom de compte.
Nom du paramètre :
AzureWebJobsStorage__blobServiceUriExemple de valeur :
https://mystorageaccount123.blob.core.windows.net/Nom du paramètre :
AzureWebJobsStorage__queueServiceUriExemple de valeur :
https://mystorageaccount123.queue.core.windows.net/Nom du paramètre :
AzureWebJobsStorage__tableServiceUriExemple de valeur :
https://mystorageaccount123.table.core.windows.net/
Vous pouvez obtenir les valeurs de ces variables d’URI dans les informations sur le compte de stockage depuis l’onglet Points de terminaison.
Note
Si vous utilisez Azure Government ou tout autre cloud distinct du Azure global, vous devez utiliser l'option qui fournit des URI de service spécifiques au lieu du nom du compte de stockage uniquement. Pour plus d’informations sur l’utilisation de stockage Azure avec Azure Government, consultez le Develop à l’aide de l’API de stockage dans Azure Government.
Terminez votre configuration d’identité managée (n’oubliez pas de cliquer sur « Appliquer » après avoir apporté des modifications au paramètre) :
Si vous utilisez une identité affectée par le système, n’apportez aucune autre modification.
Si vous utilisez une identité affectée par l’utilisateur, ajoutez les paramètres suivants dans la configuration de votre application :
AzureWebJobsStorage__credential, entrez managedidentity
AzureWebJobsStorage__clientId, obtenez cette valeur GUID à partir de votre ressource d’identité managée
Note
Durable Functions ne prend pas en charge
managedIdentityResourceIdlors de l’utilisation de l’identité affectée par l’utilisateur. UtilisezclientIdà la place.
Vérifier votre configuration
Pour confirmer que votre configuration d’identité managée fonctionne :
- Dans le portail Azure, accédez à votre application de fonction et déclenchez votre orchestration de Durable Functions (par exemple, à l’aide d’une fonction de déclencheur HTTP).
- Assurez-vous que l’orchestration s’est achevée correctement en interrogeant le point de terminaison d’état ou en consultant l’onglet Surveiller.
- Si vous voyez des erreurs d’authentification, vérifiez que :
- Les trois rôles de contributeur de données de stockage sont attribués à l’identité appropriée.
- Le paramètre
AzureWebJobsStoragechaîne de connexion est supprimé. - Les
AzureWebJobsStorage__accountNameparamètres (ou URI de service) sont corrects.
Étapes suivantes
- Vue d’ensemble de l’identité managée pour App Service et Azure Functions
- Vue d’ensemble du planificateur de tâches durables
- fournisseur Durable Functions stockage Azure
- Vue d’ensemble des fournisseurs de stockage Durable Functions