Déploiement DevOps pour les applications logiques Standard dans Azure Logic Apps à locataire unique
S’applique à : Azure Logic Apps (Standard)
Les applications ayant tendance à être de plus en plus des applications cloud distribuées et natives, les organisations gèrent davantage de composants distribués entre davantage d’environnements. Pour maintenir le contrôle et la cohérence, vous pouvez automatiser vos environnements et déployer davantage de composants plus rapidement et avec une confiance accrue au moyen des outils et processus DevOps.
Cet article fournit une introduction et une vue d’ensemble de l’expérience actuelle d’intégration continue et de déploiement continu (CI/CD) pour les workflows d’application logique Standard dans Azure Logic Apps à locataire unique.
Comparaison entre l’architecture monolocataire et l’architecture multilocataire
Dans les applications logiques Azure multilocataires, le déploiement des ressources est basé sur des modèles Azure Resource Manager (modèles ARM), qui combinent et gèrent le provisionnement des ressources pour vos ressources et votre infrastructure d’application logique de Consommation. Dans les applications logiques Azure à locataire unique, le déploiement devient plus facile, car vous pouvez séparer le provisionnement des ressources entre les ressources d’application logique Standard et l’infrastructure.
Lorsque vous créez une ressource d’application logique Standard, les workflows sont optimisés par l’environnement d’exécution Azure Logic Apps à locataire unique repensé. Ce runtime utilise le modèle d’extensibilité d’Azure Functions et est hébergé en tant qu’extension sur le runtime d’Azure Functions. Cette conception offre portabilité, flexibilité et davantage de performances pour les applications logiques Standard, ainsi que d’autres fonctionnalités et avantages hérités de la plateforme Azure Functions et de l’écosystème Azure App Service.
Par exemple, vous pouvez regrouper l’exécution conteneurisée et les workflows repensés dans le cadre de votre application logique Standard. Vous pouvez utiliser des étapes ou des tâches génériques qui génèrent, assemblent et compressent vos ressources d’application logique dans des artefacts prêts à être déployés. Pour déployer des applications logiques Standard, copiez les artefacts dans l’environnement hôte, puis démarrez vos applications pour exécuter vos workflows. Ou bien, intégrez vos artefacts dans des pipelines de déploiement à l’aide des outils et processus que vous connaissez et utilisez déjà. Par exemple, si votre scénario nécessite des conteneurs, vous pouvez conteneuriser des applications logiques Standard et les intégrer à vos pipelines existants.
Pour configurer et déployer vos ressources d’infrastructure, telles que les réseaux virtuels et la connectivité, vous pouvez continuer à utiliser des modèles ARM et provisionner séparément ces ressources avec d’autres processus et pipelines que vous utilisez à ces fins.
Avec les options de génération et de déploiement standard, vous pouvez vous concentrer sur le développement d’applications séparément du déploiement d’infrastructure. Ainsi, vous obtenez un modèle de projet plus générique dans lequel vous pouvez appliquer de nombreuses options de déploiement similaires ou identiques à celles que vous utilisez pour une application générique. Vous bénéficierez également d’une expérience plus cohérente pour créer des pipelines de déploiement autour de vos projets d’application et pour exécuter les tests et validations requis avant la publication en production. Quelle que soit la pile de technologies que vous utilisez, vous pouvez déployer des applications logiques avec les outils de votre choix.
Fonctionnalités de déploiement DevOps
Azure Logic Apps monolocataire hérite de nombreuses fonctionnalités et avantages hérités de la plateforme Azure Functions et de l’écosystème Azure App Service. Ces mises à jour incluent un tout nouveau modèle de déploiement et d’autres façons d’utiliser DevOps pour vos workflows d’application logique.
Développement et test locaux
Lorsque vous utilisez Visual Studio Code avec l’extension Azure Logic Apps (Standard), vous pouvez développer, créer et exécuter localement des workflows d’application logique Standard dans votre environnement de développement sans avoir à déployer sur Azure. Si votre scénario requiert des conteneurs, vous pouvez les créer et les déployer via Logic Apps avec Azure Arc.
Cette fonctionnalité est une amélioration majeure et procure un avantage substantiel par rapport au modèle multilocataire, ce qui vous oblige à développer sur une ressource en cours d’exécution existante dans Azure.
Séparer les responsabilités
Le modèle à locataire unique vous donne la possibilité de séparer les préoccupations entre votre application logique et l'infrastructure sous-jacente. Par exemple, vous pouvez développer, générer, compresser et déployer votre application séparément en tant qu’artefact immuable sur différents environnements. Les workflows d’application logique ont généralement un « code d’application » que vous mettez à jour plus souvent que l’infrastructure sous-jacente. En séparant ces couches, vous pouvez vous concentrer davantage sur la création du workflow de votre application logique et consacrer moins de temps au déploiement des ressources nécessaires dans plusieurs environnements.
Structure des ressources d’application logique
Dans le modèle Azure Logic Apps multilocataire, la structure des ressources d’application logique Consommation ne peut inclure qu’un seul workflow. En raison de cette relation un-à-un, l’application logique et le workflow sont souvent considérés et référencés comme des synonymes. Toutefois, dans le modèle Azure Logic Apps monolocataire, la structure des ressources d’application logique Standard peut inclure plusieurs workflows. Cette relation un-à-plusieurs signifie que dans la même application logique, les workflows peuvent partager et réutiliser d’autres ressources. Les workflows de la même application logique et du même locataire offrent également des performances améliorées en raison de cette location partagée et de la proximité les unes des autres. Cette structure des ressources a la même apparence et le même fonctionnement qu’Azure Functions où une application de fonction peut héberger de nombreuses fonctions.
Pour obtenir plus d’informations et pour connaître les bonnes pratiques relatives à l’organisation des workflows, aux performances et à la mise à l’échelle dans votre application logique, passez en revue les mêmes conseils sur Azure Functions que ceux que vous pouvez généralement appliquer à des applications logiques Azure à locataire unique.
Structure du projet d’application logique
Dans Visual Studio Code, votre projet d’application logique a l’un des types suivants :
- Extension basée sur un bundle (Node.js), qui est le type par défaut
- NuGet basé sur un package (.NET), que vous pouvez convertir à partir du type par défaut
En fonction de ces types, votre projet comprend des dossiers et des fichiers légèrement différents. Un projet NuGet inclut un dossier .bin qui contient des packages et d’autres fichiers de bibliothèque. Un projet basé sur un bundle n’inclut pas le dossier .bin ni d’autres fichiers. Certains scénarios exigent un projet NuGet pour que votre application s’exécute, par exemple quand vous voulez développer et exécuter des opérations intégrées personnalisées. Pour plus d’informations sur la conversion de votre projet pour utiliser NuGet, consultez Activer la création de connecteurs intégrés.
Pour le projet basé sur un bundle par défaut, votre projet a une structure de dossiers et de fichiers similaire à celle de l’exemple suivant :
MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
|| Maps
||| MapName1
||| ...
|| Schemas
||| SchemaName1
||| ...
| WorkflowName1
|| workflow.json
|| ...
| WorkflowName2
|| workflow.json
|| ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json
Au niveau racine de votre projet se trouvent les fichiers et dossiers suivants avec d’autres éléments :
| Nom | Fichier ou dossier | Description |
|---|---|---|
| .vscode | Dossier | Contient les fichiers de paramètres liés à Visual Studio Code, comme les fichiers extensions.json, launch.json, settings.json et tasks.json. |
| Artefacts | Dossier | Contient les artefacts de compte d’intégration que vous définissez et utilisez dans des workflows qui prennent en charge les scénarios interentreprises (B2B, Business-to-Business). Par exemple, l’exemple de structure comprend des mappages et des schémas pour les opérations de transformation et de validation XML. |
| <WorkflowName> | Dossier | Pour chaque workflow, le dossier <WorkflowName> inclut un fichier workflow.json, qui contient la définition JSON sous-jacente de ce workflow. |
| workflow-designtime | Dossier | Contient les fichiers de paramètres liés à l’environnement de développement. |
| .funcignore | Fichier | Contient des informations relatives à votre ensemble d’outils Azure Functions Core Tools installé. |
| connections.json | Fichier | Contient les métadonnées, les points de terminaison et les clés de toutes les connexions managées et fonctions Azure utilisées par vos workflows. Important : Pour utiliser des connexions et des fonctions différentes pour chaque environnement, veillez à paramétrer ce fichier connections.json et mettre à jour les points de terminaison. |
| host.json | Fichier | Contient des paramètres de configuration et des valeurs spécifiques au runtime, par exemple les limites par défaut pour la plateforme, les applications logiques, les workflows, les déclencheurs et les actions Azure Logic Apps à locataire unique. Au niveau racine de votre projet d’application logique, le fichier de métadonnées host.json contient les paramètres de configuration et les valeurs par défaut que tous les workflows d’une même application logique utilisent lors de l’exécution, que ce soit localement ou dans Azure. Remarque : Quand vous créez votre application logique, Visual Studio Code crée un fichier host.snapshot.*.json de sauvegarde dans votre conteneur de stockage. Si vous supprimez votre application logique, ce fichier de sauvegarde n’est pas supprimé. Si vous créez une autre application logique portant le même nom, un autre fichier d’instantané est créé. Vous pouvez avoir jusqu’à 10 instantanés pour la même application logique. Si vous dépassez cette limite, vous obtenez l’erreur suivante : Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host)) Pour résoudre cette erreur, supprimez les fichiers d’instantanés supplémentaires de votre conteneur de stockage. |
| local.settings.json | Fichier | Contient les paramètres d’application, les chaînes de connexion et d’autres paramètres utilisés par vos workflows lors d’une exécution locale. En d’autres termes, ces paramètres et valeurs s’appliquent uniquement quand vous exécutez vos projets dans votre environnement de développement local. Lors d’un déploiement sur Azure, le fichier et les paramètres sont ignorés et ne sont pas inclus dans votre déploiement. Ce fichier stocke les paramètres et les valeurs sous la forme de variables d’environnement local utilisées par vos outils de développement locaux comme valeurs appSettings. Vous pouvez appeler et référencer ces variables d’environnement au moment de l’exécution et au moment du déploiement à l’aide des paramètres d’application et des configurations. Important : Le fichier local.settings.json peut contenir des secrets. Par conséquent, veillez à exclure également ce fichier du contrôle de code source de votre projet. |
Déploiement de conteneur
Azure Logic Apps monolocataire prenant en charge le déploiement sur des conteneurs, vous pouvez conteneuriser vos flux de travail d’application logique et les exécuter là où des conteneurs peuvent s’exécuter. Une fois que vous avez conteneurisé votre application, le déploiement fonctionne essentiellement comme tout autre conteneur déployé et géré par vos soins.
Pour obtenir des exemples qui incluent Azure DevOps, consultez CI/CD pour les conteneurs.
Paramètres d’application et paramètres
Dans Azure Logic Apps multilocataire, les modèles ARM posent un défi quand vous devez gérer des variables d’environnement pour des applications logiques dans différents environnements de développement, de test et de production. Tout ce qui se trouve dans un modèle ARM est défini lors du déploiement. Si vous ne devez changer ne serait-ce qu’une seule variable, vous devez tout redéployer.
Dans Azure Logic Apps monolocataire, vous pouvez appeler et référencer vos variables d’environnement au moment de l’exécution en utilisant les paramètres d’application et les paramètres, ce qui évite les redéploiements aussi fréquents.
Connecteurs managés et opérations intégrées
L’écosystème Azure Logic Apps fournit plus de 1 000 connecteurs et opérations intégrées gérés par Microsoft et hébergés par Azure dans le cadre d’une collection en constante évolution que vous pouvez utiliser dans Azure Logic Apps à locataire unique. La manière dont Microsoft gère les connecteurs gérés reste essentiellement la même dans les Azure Logic Apps à locataire unique que dans les Azure Logic Apps à locataires multiples.
L’amélioration la plus significative est que le service à locataire unique rend les connecteurs gérés les plus populaires disponibles en tant qu’opérations intégrées. Par exemple, vous pouvez utiliser des opérations intégrées pour Azure Service Bus, Azure Event Hubs, SQL et bien d’autres. Dans le même temps, les versions du connecteur managé sont toujours disponibles et continuent de fonctionner.
Les connexions que vous créez à l’aide d’opérations intégrées basées sur le service Azure sont appelées connexions intégrées ou connexions basées sur le fournisseur de services. Les opérations intégrées et leurs connexions s’exécutent localement dans le même processus que celui qui exécute vos workflows. Les deux sont hébergés sur l’environnement d’exécution Azure Logic Apps repensé. En revanche, les connexions managées, ou les connexions d’API, sont créées et exécutées séparément en tant que ressources Azure, que vous déployez en utilisant des modèles ARM. Ainsi, les opérations intégrées et leurs connexions offrent de meilleures performances en raison de leur proximité avec vos workflows. Cette conception fonctionne également bien avec les pipelines de déploiement, car les connexions du fournisseur de services sont empaquetées dans le même artefact de build.
Dans Visual Studio Code, lorsque vous utilisez le concepteur pour développer ou apporter des modifications à vos workflows, le moteur Azure Logic Apps à locataire unique génère automatiquement toutes les métadonnées de connexion nécessaires dans le fichier connections.json de votre projet. Les sections suivantes décrivent les trois types de connexions que vous pouvez créer dans vos workflows. Chaque type de connexion a une structure JSON différente, ce qui est important à comprendre, car les points de terminaison changent quand vous passez d’un environnement à un autre.
Connexion de fournisseur de services
Quand vous utilisez une opération intégrée pour un service tel qu’Azure Service Bus ou Azure Event Hubs dans Azure Logic Apps monolocataire, vous créez une connexion de fournisseur de services qui s’exécute dans le même processus que votre workflow. Cette infrastructure de connexion est hébergée et gérée avec votre ressource d’application logique, et les paramètres d’application stockent les chaînes de connexion pour toutes les opérations intégrées basées sur le fournisseur de services que vos flux de travail utilisent.
Important
Quand vous avez des informations sensibles, comme des chaînes de connexion qui incluent des noms d’utilisateur et des mots de passe, veillez à utiliser le flux d’authentification le plus sécurisé disponible. Par exemple, Microsoft vous recommande d’authentifier l’accès aux ressources Azure avec une identité managée quand sa prise en charge est disponible et d’attribuer un rôle qui a le privilège minimum nécessaire.
Si cette fonctionnalité n’est pas disponible, veillez à sécuriser les chaînes de connexion via d’autres mesures, comme Azure Key Vault, que vous pouvez utiliser avec des paramètres d’application. Vous pouvez ensuite référencer directement des chaînes sécurisées, telles que des chaînes de connexion et des clés. Comme pour les modèles ARM, où vous pouvez définir des variables d’environnement au moment du déploiement, vous pouvez définir des paramètres d’application dans la définition de workflow de votre application logique. Vous pouvez ensuite capturer des valeurs d’infrastructure générées dynamiquement, comme des points de terminaison de connexion, des chaînes de stockage, etc. Pour plus d’informations, consultez Types d’application pour la plateforme d’identités Microsoft.
Dans votre projet d'application logique Standard, chaque workflow possède un fichier workflow.json qui contient la définition JSON sous-jacente du workflow. Cette définition de workflow référence ensuite les chaînes de connexion nécessaires dans le fichier connections.json de votre projet.
L'exemple suivant montre comment la connexion au fournisseur de services pour une opération intégrée Azure Service Bus apparaît dans le fichier connections.json de votre projet :
"serviceProviderConnections": {
"{service-bus-connection-name}": {
"parameterValues": {
"connectionString": "@appsetting('servicebus_connectionString')"
},
"serviceProvider": {
"id": "/serviceProviders/serviceBus"
},
"displayName": "{service-bus-connection-name}"
},
<...>
}
Connexions managées
Quand vous utilisez un connecteur managé pour la première fois dans votre workflow, vous êtes invité à créer une connexion d’API managée pour le service ou le système cible et à authentifier votre identité. Ces connecteurs sont managés par l’écosystème de connecteurs partagés dans Azure. Les connexions d’API existent et s’exécutent en tant que ressources distinctes dans Azure.
Dans Visual Studio Code, pendant que vous continuez à créer et à développer votre workflow à l’aide du concepteur, le moteur Azure Logic Apps à locataire unique crée automatiquement les ressources nécessaires dans Azure pour les connecteurs gérés dans votre workflow. Le moteur ajoute automatiquement ces ressources de connexion au groupe de ressources Azure que vous avez conçu pour contenir votre application logique.
L'exemple suivant montre comment une connexion API pour le connecteur géré Azure Service Bus apparaît dans le fichier connections.json de votre projet :
"managedApiConnections": {
"{service-bus-connection-name}": {
"api": {
"id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
},
"connection": {
"id": "/subscriptions/{subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
},
"connectionRuntimeUrl": "{connection-runtime-URL}",
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('servicebus_1-connectionKey')"
},
},
<...>
}
Connexions Azure Functions
Pour appeler des fonctions créées et hébergées dans Azure Functions, vous utilisez l’opération intégrée Azure Functions. Les métadonnées de connexion pour les appels Azure Functions sont différentes des autres connexions intégrées. Ces métadonnées sont stockées dans le fichier connections.json de votre projet d'application logique, mais leur apparence est différente :
"functionConnections": {
"{function-operation-name}": {
"function": {
"id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
},
"triggerUrl": "{function-url}",
"authentication": {
"type": "QueryString",
"name": "Code",
"value": "@appsetting('azureFunctionOperation_functionAppKey')"
},
"displayName": "{functions-connection-display-name}"
},
<...>
}
Authentification
Dans Azure Logic Apps à locataire unique, le modèle d’hébergement des workflows d’application logique est un locataire Microsoft Entra unique où vos charges de travail bénéficient d’une plus grande isolation que dans le modèle multilocataire. En outre, le runtime d’Azure Logic Apps à locataire unique est portable, ce qui signifie que vous pouvez exécuter vos workflows dans d’autres environnements, par exemple localement dans Visual Studio Code. Toutefois, cette conception exige que les applications logiques puissent authentifier leur identité afin de pouvoir accéder à l’écosystème de connecteurs managés dans Azure. Vos applications ont également besoin des autorisations appropriées pour exécuter des opérations lors de l’utilisation de connexions managées.
Par défaut, chaque application logique monolocataire a une identité managée affectée par le système automatiquement activée. Cette identité diffère des informations d’identification d’authentification ou de la chaîne de connexion utilisées pour la création d’une connexion. Lors de l’exécution, votre application logique utilise cette identité pour authentifier ses connexions par le biais des stratégies d’accès Azure. Si vous désactivez cette identité, les connexions ne fonctionneront pas au moment de l’exécution.
Les sections suivantes fournissent des informations supplémentaires sur les types d’authentification que vous pouvez utiliser pour authentifier les connexions managées, selon l’endroit où s’exécute votre application logique. Pour chaque connexion gérée, le fichier connections.json de votre projet d'application logique contient un objet authentication qui spécifie le type d'authentification que votre application logique peut utiliser pour authentifier cette connexion gérée.
Identité managée
Pour une application logique hébergée et exécutée dans Azure, une identité managée est le type d’authentification par défaut et recommandé à utiliser pour authentifier les connexions managées qui sont hébergées et exécutées dans Azure. Dans le fichier connections.json de votre projet d'application logique, la connexion gérée possède un objet authentication qui spécifie ManagedServiceIdentity comme type d'authentification :
"authentication": {
"type": "ManagedServiceIdentity"
}
Brute
Pour les applications logiques qui s’exécutent dans votre environnement de développement local avec Visual Studio Code, des clés d’authentification brutes sont utilisées pour authentifier les connexions managées qui sont hébergées et exécutées dans Azure. Ces clés sont conçues uniquement pour le développement, pas pour la production, et expirent au terme de 7 jours. Dans le fichier connections.json de votre projet d'application logique, la connexion gérée possède un objet authentication qui spécifie les informations d'authentification suivantes :
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('connectionKey')"
}