Déploiement DevOps pour les flux de travail d’application logique standard dans Azure Logic Apps

S’applique à : Azure Logic Apps (Standard)

À mesure que les charges de travail d’intégration augmentent dans les environnements de développement, de test et de production, le déploiement manuel et les mises à jour des workflows d’application logique standard deviennent lentes, sujettes aux erreurs et difficiles à maintenir cohérentes. Avec la tendance vers les applications cloud distribuées et natives, les équipes doivent gérer davantage de composants distribués dans d’autres environnements. Votre équipe a besoin d’un moyen de générer, de tester et de publier des modifications de flux de travail de manière fiable à l’aide des mêmes pratiques DevOps que celles que vous appliquez au code d’application.

Les flux de travail d’application logique standard dans les Azure Logic Apps à locataire unique prennent en charge l’intégration continue et le déploiement continu (CI/CD) avec les outils DevOps que vous utilisez déjà. Contrairement au modèle mutualisé, l’Azure Logic Apps monolocataire sépare le code d’application de l’infrastructure. Vous pouvez donc créer, générer et déployer vos workflows indépendamment , localement, dans des conteneurs ou via des pipelines automatisés.

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 monolocataire et multilocataire

Dans multitenant Azure Logic Apps, le déploiement de ressources est basé sur des modèles Azure Resource Manager (modèles ARM). Ces modèles combinent et gèrent le provisionnement des ressources de votre application logique Consumption ainsi que de l’infrastructure. Dans single-tenant Azure Logic Apps, le déploiement est plus facile, car vous pouvez séparer le provisionnement de 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é Azure Functions et est hébergé en tant qu’extension du runtime 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. Vous pouvez également intégrer vos artefacts dans des pipelines de déploiement à l’aide des outils et processus que vous connaissez déjà et utilisez. 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 technologique que vous utilisez, vous pouvez déployer des applications logiques à l’aide de vos propres outils choisis.

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 nécessite un déploiement local à l’aide de l’infrastructure que vous contrôlez, consultez Créer des flux de travail d’application logique standard pour le déploiement hybride sur votre propre infrastructure.

Cette fonctionnalité est une amélioration majeure et offre un avantage substantiel par rapport au modèle multilocataire, ce qui vous oblige à développer sur une ressource existante et en cours d’exécution 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 peut inclure des dossiers ou des fichiers légèrement différents. Par exemple, un projet nuget basé sur des packages a un dossier .bin qui contient des packages et d’autres fichiers de bibliothèque. Un projet basé sur un bundle d’extensions n’inclut pas ce dossier .bin .

Certains scénarios nécessitent l’exécution d’un projet basé sur un package NuGet pour que votre application s’exécute, par exemple lorsque vous souhaitez 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.

Le projet basé sur l’extension par défaut a un dossier et une structure de fichiers semblable à l’exemple suivant :

MyWorkspaceName
| MyBundleBasedLogicAppProjectName
  || .vscode
  || Artifacts
     ||| Maps 
         |||| MapName1
         |||| ...
     ||| Rules
     ||| Schemas
         |||| SchemaName1
         |||| ...
  || lib
     ||| builtinOperationSdks
         |||| JAR
         |||| net472
     ||| custom
  || WorkflowName1
     ||| workflow.json
     ||| ...
  || WorkflowName2
     ||| workflow.json
     ||| ...
  || workflow-designtime
     ||| host.json
     ||| local.settings.json
  || .funcignore
  || connections.json
  || host.json
  || local.settings.json

Au niveau racine de votre projet, vous trouverez les dossiers et fichiers suivants, ainsi que d’autres éléments :

Déploiement de conteneur

Azure Logic Apps à locataire unique prend en charge le déploiement sur des conteneurs. Vous pouvez conteneuriser vos flux de travail d’application logique et les exécuter là où les 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 conteneurs.

Paramètres d’application et variables

Dans les Azure Logic Apps multilocataires, les modèles ARM présentent un défi quand vous devez gérer des variables d’environnement pour les applications logiques dans différents environnements de développement, de test et de production. Vous définissez tout dans un modèle ARM lors du déploiement. Si vous devez modifier une seule variable, vous devez tout redéployer.

Dans Azure Logic Apps à locataire unique, vous pouvez appeler et référencer vos variables d’environnement lors de l'exécution en utilisant les paramètres d'application et les paramètres associés, ce qui réduit la fréquence des redéploiements.

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 façon dont Microsoft gère les connecteurs managés reste principalement la même dans les Azure Logic Apps monolocataires que dans les Azure Logic Apps multilocataires.

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 des opérations intégrées basées sur Azure Service 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 API sont créées et exécutées séparément en tant que ressources Azure, que vous déployez à l’aide de 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 intégrées dans le même artefact de construction.

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.

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 flux de travail fait référence aux 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é. l'écosystème des connecteurs partagés de Azure gère ces connecteurs. 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 flux de travail à l’aide du concepteur, le moteur de Azure Logic Apps monolocataire crée automatiquement les ressources nécessaires dans Azure pour les connecteurs managés de votre flux de travail. 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 de Azure Functions

Pour appeler des fonctions créées et hébergées dans Azure Functions, 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 les Azure Logic Apps monolocataires, le modèle d’hébergement pour les flux de travail d’application logique est un seul locataire Microsoft Entra où vos charges de travail bénéficient d’un plus grand isolement que dans le modèle multilocataire. De plus, l'environnement d'exécution des Azure Logic Apps à locataire unique est portable, ce qui signifie que vous pouvez exécuter vos workflows dans d'autres environnements, tels que Visual Studio Code local. 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 attribuée par le système et activée automatiquement. 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 fonctionnent 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"
}

Non traité

Pour les applications logiques qui s’exécutent dans votre environnement de développement local à l’aide de Visual Studio Code, les clés d’authentification brutes authentifient les connexions managées hébergées et exécutées dans Azure. Utilisez ces clés uniquement pour le développement, et non pour la production, car elles expirent après sept jours. Dans le fichier connections.json de votre projet d’application logique, la connexion managée inclut un authentication objet qui spécifie les informations d’authentification suivantes :

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

Contenu connexe

• Configurer le déploiement DevOps pour Azure Logic Apps à locataire unique