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.
Durable Functions est un ensemble de déclencheurs et de liaisons Azure Functions qui sont alimentés en interne par Durable Task Framework (DTFx). DTFx prend en charge différents fournisseurs de stockage principal, y compris le fournisseur Stockage Azure utilisé par Durable Functions. À partir de Durable Functions v2.5.0, les utilisateurs peuvent configurer leurs applications de fonction pour utiliser des fournisseurs de stockage DTFx autres que le fournisseur de stockage Azure.
Remarque
Le fournisseur de stockage Azure par défaut pour Durable Functions est le plus simple à utiliser, car il ne nécessite aucune configuration supplémentaire. Toutefois, il existe des compromis de coût, d’extensibilité et de gestion des données qui peuvent favoriser l’utilisation d’un autre fournisseur back-end.
Durable Functions prend en charge deux types de fournisseurs principaux : « Bring your own (BYO) » et Azure managed. Les options BYO incluent Stockage Azure, Netherite et Microsoft SQL Server (MSSQL). L’option managée Azure est le nouveau planificateur de tâches durable actuellement en préversion. Cet article décrit tous les fournisseurs principaux pris en charge, les compare les uns aux autres et fournit des informations de base sur la façon de commencer à les utiliser.
Remarque
Il n’est actuellement pas possible de migrer des données d’un fournisseur principal de stockage vers un autre. Si vous souhaitez utiliser un nouveau fournisseur, vous devez créer une application configurée avec le nouveau fournisseur.
Planificateur de tâches persistant (version préliminaire)
Le planificateur de tâches durables est un fournisseur back-end entièrement géré et très performant pour Durable Functions. Il a été conçu et construit à partir de zéro avec l’aide de Microsoft Research. Ce nouveau fournisseur vise à offrir la meilleure expérience utilisateur dans des aspects tels que la gestion, l’observabilité, les performances et la sécurité.
Les principaux avantages du planificateur de tâches durables sont les suivants :
- Réduction de la charge de gestion et des opérations par rapport aux fournisseurs d'infrastructure BYO
- Le tableau de bord d’observabilité et de gestion de première classe est fourni prêt à l’emploi.
- Prend en charge le débit le plus élevé de tous les back-ends aujourd’hui.
- Prise en charge de l’authentification à l’aide de l’identité managée.
Les utilisateurs Durable Functions existants peuvent tirer parti du planificateur sans modification de code. En savoir plus sur le planificateur de tâches durable et sur la prise en main.
Vous trouverez des exemples de planificateur de tâches durables sur GitHub.
Stockage Azure
Stockage Azure est le fournisseur de stockage par défaut pour Durable Functions. Il utilise des files d’attente, des tables et des objets blob pour conserver l’état de l’orchestration et de l’entité. Il utilise également des objets blob et des baux d’objets blob pour gérer les partitions. Dans de nombreux cas, le compte de stockage utilisé pour stocker l’état d’exécution de Durable Functions est le même que le compte de stockage par défaut utilisé par Azure Functions (AzureWebJobsStorage). Toutefois, il est également possible de configurer Durable Functions avec un compte de stockage distinct. Le fournisseur Stockage Azure est intégré à l’extension Durable Functions et n’a pas d’autres dépendances.
Les principaux avantages du fournisseur Stockage Azure sont les suivants :
- Aucune configuration requise : vous pouvez utiliser le compte de stockage qui a été créé pour vous par l’expérience d’installation d’application de fonction.
- Modèle de facturation sans serveur à faible coût : Stockage Azure dispose d’un modèle de tarification basé sur la consommation reposant entièrement sur l’utilisation (plus d’informations).
- Meilleure prise en charge des outils : Stockage Azure offre une émulation locale interplateforme et s’intègre à Visual Studio, Visual Studio Code et le Azure Functions Core Tools.
- Plus mature : Stockage Azure est le stockage principal d’origine et le plus éprouvé pour Durable Functions.
- Prise en charge de l’utilisation de l’identité à la place des secrets pour la connexion au fournisseur de stockage.
Le code source des composants DTFx du fournisseur Stockage Azure se trouve dans le référentiel GitHub Azure/durabletask.
Remarque
Des comptes Stockage Azure standard à usage général sont requis lors de l’utilisation du fournisseur Stockage Azure. Tous les autres types de compte de stockage ne sont pas pris en charge. Nous vous recommandons vivement d’utiliser des comptes de stockage à usage général v1 hérités, car les comptes de stockage v2 plus récents peuvent être plus coûteux pour les charges de travail Durable Functions. Pour plus d’informations sur les types de comptes de stockage Azure, consultez l’article Vue d’ensemble du compte de stockage.
Netherite
Remarque
La prise en charge de l’utilisation du back-end de stockage Netherite avec Durable Functions se terminera le 31 mars 2028. Nous vous recommandons de commencer à évaluer le Durable Task Scheduler pour les charges de travail que vous utilisez actuellement avec Netherite. Consultez l’annonce de fin de support.
Le stockage principal Netherite a été conçu et développé par Microsoft Research. Il utilise Azure Event Hubs et la technologie de base de données FASTER en plus d’objets blob de pages Azure. La conception de Netherite permet un traitement à débit plus élevé des orchestrations et des entités par rapport à d’autres fournisseurs. Dans certains scénarios de test, le débit a augmenté d’un ordre de grandeur supérieur à celui du fournisseur Stockage Azure par défaut.
Les principaux avantages du fournisseur de stockage Netherite comprennent les suivants :
- Débit plus élevé à moindre coût par rapport à d’autres fournisseurs de stockage.
- Prend en charge l’optimisation des performances, ce qui vous permet de mettre à l’échelle les performances en fonction des besoins.
- Prend en charge jusqu’à 32 partitions de données avec les références SKU De base et Standard d’Event Hubs.
- Plus rentable que les autres fournisseurs pour les charges de travail à débit élevé.
Vous pouvez en apprendre plus sur les détails techniques du fournisseur de stockage Netherite, notamment sa prise en main, dans la documentation de Netherite. Le code source du fournisseur de stockage Netherite se trouve dans le référentiel GitHub Microsoft/durabletask-netherite. Une évaluation plus approfondie du fournisseur de stockage Netherite est également disponible dans le document de recherche suivant : Workflows sans serveur avec Durable Functions et Netherite.
Remarque
Le nom Netherite provient du monde de Minecraft.
Microsoft SQL Server (MSSQL)
Le fournisseur de stockage Microsoft SQL Server (MSSQL) conserve tout l’état dans une base de données Microsoft SQL Server. Il est compatible avec les déploiements locaux et hébergés sur le cloud de SQL Server, y compris les bases de données Azure SQL.
Les principaux avantages du fournisseur de stockage MSSQL sont les suivants :
- Prend en charge les environnements déconnectés : aucune connectivité Azure n’est requise lors de l’utilisation d’une installation SQL Server.
- Portable dans plusieurs environnements et clouds, y compris Azure et en local.
- Forte cohérence des données, permettant la sauvegarde/restauration et le basculement sans perte de données.
- Prise en charge native du chiffrement de données personnalisé (une fonctionnalité de SQL Server).
- S’intègre avec les applications de base de données existantes via des procédures stockées intégrées.
Vous pouvez en apprendre plus sur les détails techniques du fournisseur de stockage MSSQL, notamment sa prise en main, dans la documentation du fournisseur Microsoft SQL. Le code source du fournisseur de stockage MSSQL se trouve dans le référentiel GitHub Microsoft/durabletask-mssql.
Configurer le fournisseur Stockage Azure
Le fournisseur Stockage Azure est le fournisseur de stockage par défaut et n’a besoin d’aucune configuration explicite, de références de package NuGet ou de références de pack d’extensions. Vous pouvez trouver l’ensemble complet d’options de configuration de host.jsonici, sous le chemin d’accès extensions/durableTask/storageProvider.
Connexions
La propriété connectionName dans host.json est une référence à la configuration de l’environnement qui spécifie la façon dont l’application doit se connecter au stockage Azure. Elle peut spécifier :
- Le nom d’un préfixe partagé pour plusieurs paramètres d’application, définissant ensemble une connexion basée sur l’identité. Les identités managées utilisent l’authentification Microsoft Entra pour fournir la connexion la plus sécurisée à votre compte de stockage.
- Le nom d’un paramètre d’application contenant une chaîne de connexion. Pour obtenir une chaîne de connexion, suivez les étapes indiquées dans Gérer les clés d’accès au compte de stockage.
Si la valeur configurée est à la fois une correspondance exacte pour un paramètre unique et une correspondance de préfixe pour d’autres paramètres, la correspondance exacte est utilisée. Si aucune valeur n’est spécifiée dans host.json, la valeur par défaut est AzureWebJobsStorage.
Connexions basées sur l’identité
Si vous utilisez la version 2.7.0 ou ultérieure de l’extension et le fournisseur de stockage Azure, au lieu d’utiliser une chaîne de connexion avec un secret, vous pouvez faire en sorte que l’application utilise une identité Microsoft Entra. Pour ce faire, vous devez définir les paramètres sous un préfixe commun qui correspond à la propriété connectionName dans le déclencheur et la configuration de liaison.
Pour utiliser une connexion basée sur une identité pour Durable Functions, configurez les paramètres d’application suivants :
| Propriété | Modèle de variable d’environnement | Descriptif | Valeur d'exemple |
|---|---|---|---|
| URI du service blob | <CONNECTION_NAME_PREFIX>__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 |
| URI du service de file d’attente | <CONNECTION_NAME_PREFIX>__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 |
| URI du service de table | <CONNECTION_NAME_PREFIX>__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 |
Des propriétés supplémentaires peuvent être définies pour personnaliser la connexion. Consultez Propriétés communes pour les connexions basées sur l’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.
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 :
- 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
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.
Configuration de fournisseurs de stockage alternatifs
La configuration de fournisseurs de stockage alternatifs est généralement un processus en deux étapes :
- Ajoutez le package NuGet approprié à votre application de fonction (cette exigence est temporaire pour les applications qui utilisent des packs d’extension).
- Mettez à jour le fichier host.json pour spécifier le fournisseur de stockage que vous souhaitez utiliser.
Si aucun fournisseur de stockage n’est explicitement configuré dans host.json, le fournisseur Stockage Azure est activé par défaut.
Configuration d’un planificateur de tâches durable (réversion)
Consultez la documentation de prise en main du planificateur de tâches durable.
Configuration du fournisseur de stockage MSSQL
L’activation du fournisseur de stockage MSSQL nécessite une modification de configuration dans votre host.json. Pour les utilisateurs de C#, une étape d’installation supplémentaire est également nécessaire.
Configuration host.json
L’exemple ci-dessous montre la configuration minimale requise pour activer le fournisseur de stockage MSSQL.
{
"version": "2.0",
"extensions": {
"durableTask": {
"storageProvider": {
"type": "mssql",
"connectionStringName": "SQLDB_Connection"
}
}
}
}
Pour obtenir des instructions de configuration plus détaillées, consultez la documentation et la documentation de prise en main du fournisseur MSSQLsur github.io.
Installer l’extension MSSQL de tâche durable (.NET uniquement)
Remarque
Si votre application utilise des packs d’extensions, ignorez cette section. En effet, les packs d’extensions évitent d’avoir à effectuer une gestion manuelle des extensions.
Vous devez installer la dernière version de l’extension du fournisseur de stockage MSSQL sur NuGet : Microsoft.Azure.Functions.Worker.Extensions.DurableTask.SqlServer. Cela signifie généralement inclure une référence à celle-ci dans votre fichier .csproj et de générer le projet.
Comparaison des fournisseurs de stockage
Il existe de nombreux compromis significatifs entre les différents fournisseurs de stockage pris en charge. Le tableau suivant peut être utilisé pour vous aider à comprendre ces compromis et déterminer quel fournisseur de stockage est le mieux adapté à vos besoins.
Remarque
La prise en charge de l’utilisation du back-end de stockage Netherite avec Durable Functions se terminera le 31 mars 2028. Nous vous recommandons de commencer à évaluer le Durable Task Scheduler pour les charges de travail que vous utilisez actuellement avec Netherite. Consultez l’annonce de fin de support.
| Fournisseur de stockage | Stockage Azure | Netherite | MSSQL | DTS |
|---|---|---|---|---|
| État du support officiel | ✅ Disponibilité générale (GA) | ✅ Disponibilité générale (GA) | ✅ Disponibilité générale (GA) | Aperçu public |
| Dépendances externes | Un compte Stockage Azure (usage général v1) | Azure Event Hubs Un compte Stockage Azure (usage général) |
SQL Server 2019 ou Azure SQL Database | N/A |
| Options de développement et d’émulation locales | Azurite v3.12+ (multiplateforme) | Prend en charge l’émulation en mémoire des hubs de tâches (plus d’informations) | SQL Server Développeur (prend en charge les conteneurs Windows, Linux et Docker) | Émulateur du planificateur de tâches durable |
| Configuration du hub de tâches | Explicite | Explicite | Implicite par défaut (plus d’informations) | Explicite |
| Débit maximal | Modéré | Très élevée | Modéré | Très élevée |
| Taille maximale de l’orchestration/de l’entité (nœuds) | 16 | 32 | N/A | N/A |
| Taille maximale de l’activité (nœuds) | N/A | 32 | N/A | N/A |
| Prise en charge des entités durables | ✅ Entièrement pris en charge | ✅ Entièrement pris en charge | ️⚠ pris en charge, sauf quand .NET Isolé es utilisé | ✅ Entièrement pris en charge |
|
Prise en charge de la mise à l’échelle de KEDA 2.0 (plus d’informations) |
❌ Non pris en charge | ❌ Non pris en charge | ✅ Pris en charge avec l’outil de mise à l’échelle MSSQL (plus d’informations) | À venir! |
| Prise en charge des packs d’extensions (recommandé pour les applications hors .NET) | ✅ Entièrement pris en charge | ✅ Entièrement pris en charge | ✅ Entièrement pris en charge | À venir! |
| Prix-performances configurables ? | ❌ Non | ✅ Oui (TU et CU Event Hubs) | ✅ Oui (processeurs virtuels SQL) | À venir! |
| Prise en charge des environnements déconnectés | ❌ Connectivité Azure requise | ❌ Connectivité Azure requise | ✅ Entièrement pris en charge | ❌ Connectivité Azure requise |
| Connexions basées sur l’identité | ✅ Entièrement pris en charge | ❌ Non pris en charge | ⚠Nécessite des mises à l’échelle basées sur le runtime | ✅ Entièrement pris en charge |
| Plan Consommation Flex | ✅ Entièrement pris en charge (voir les notes) | ❌ Non pris en charge | ✅ Entièrement pris en charge | ❌ Non pris en charge |