Déploiement DevOps pour Azure Logic Apps monolocataire

Article
01/04/2024

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 Azure Logic Apps monolocataire.

Comparaison entre l’architecture monolocataire et l’architecture multilocataire

Dans Azure Logic Apps multilocataire, le déploiement des ressources repose sur des modèles Azure Resource Manager (modèles ARM), qui combinent et gèrent le provisionnement des ressources à la fois pour les applications logiques et l’infrastructure. Dans Azure Logic Apps monolocataire, le déploiement devient plus facile, car vous pouvez séparer le provisionnement des ressources entre les applications et l’infrastructure.

Quand vous créez des applications logiques avec le type de ressource Application logique (Standard) , vos workflows reposent sur le runtime Azure Logic Apps monolocataire remanié. 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 une portabilité, une flexibilité et des performances accrues pour vos applications logiques 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 empaqueter le runtime conteneurisé remanié et les workflows dans le cadre de votre application logique. 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 vos applications, copiez les artefacts dans l’environnement hôte, puis démarrez vos applications pour exécuter vos workflows. Ou bien, intégrez vos artefacts à des pipelines de déploiement en utilisant les outils et processus que vous connaissez et utilisez déjà. Par exemple, si votre scénario nécessite des conteneurs, vous pouvez conteneuriser vos applications logiques 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

Quand vous utilisez Visual Studio Code avec l’extension Azure Logic Apps (Standard), vous pouvez développer, générer et exécuter localement les workflows d’application logique monolocataire dans votre environnement de développement sans avoir à effectuer de déploiement 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 monolocataire vous donne la possibilité de séparer les responsabilités entre l’application 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.

Diagramme conceptuel montrant des pipelines de déploiement distincts pour les applications et l’infrastructure.

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 des centaines de connecteurs managés par Microsoft et des opérations intégrées dans le cadre d’un regroupement en constante évolution que vous pouvez utiliser dans Azure Logic Apps monlocataire. La façon dont Microsoft gère ces connecteurs et les opérations intégrées demeure presque la même dans Azure Logic Apps monolocataire.

L’amélioration la plus importante est que le service monolocataire rend davantage de connecteurs managés populaires également 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 autres. Dans le même temps, les versions du connecteur managé sont toujours disponibles et continuent de fonctionner.

Les connexions que vous créez en utilisant des opérations intégrées sont appelées connexions intégrées ou connexions de 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 unes comme les autres sont hébergées sur le runtime Logic Apps remanié. 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, quand vous utilisez le concepteur pour développer ou apporter des modifications à vos workflows, le moteur de Logic Apps génère automatiquement 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.

Dans votre projet d’application logique, chaque workflow a 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 du fournisseur de services pour une opération Service Bus intégrée 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 avec le concepteur, le moteur de Logic Apps crée automatiquement les ressources nécessaires dans Azure pour les connecteurs managé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 d’API pour le connecteur Service Bus managé s’affiche 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 Azure Functions intégrée. 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 présentent un aspect différent :

"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 monolocataire, le modèle d’hébergement pour les workflows d’application logique est un locataire unique dans lequel vos charges de travail bénéficient d’une isolation plus grande 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 managée, le fichier connections.json de votre projet d’application logique a un objet authentication qui spécifie le type d’authentification que votre application logique peut utiliser pour authentifier cette connexion managé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 managée a 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 managée a un objet authentication qui spécifie les informations d’authentification suivantes :

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

Étapes suivantes

Configurer le déploiement DevOps pour Azure Logic Apps monolocataire

Partager via