Configurer le déploiement DevOps pour les workflows d’application logique Standard dans Azure Logic Apps monolocataire

S’applique à : Azure Logic Apps (Standard)

Cet article explique comment déployer un projet d’application logique Standard vers des Azure Logic Apps à locataire unique à partir de Visual Studio Code vers votre infrastructure à l’aide d’outils et de processus DevOps. Selon que vous préférez GitHub ou Azure DevOps pour le déploiement, choisissez la voie et les outils qui conviennent le mieux à votre scénario. Vous pouvez utiliser les exemples inclus qui contiennent des exemples de projets d’application logique ainsi que des exemples de déploiement Azure avec GitHub ou Azure DevOps. Pour plus d’informations sur DevOps pour un locataire unique, consultez Vue d’ensemble du déploiement DevOps pour Azure Logic Apps monolocataire.

Prérequis

  • Compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit.

  • Un projet d’application logique Standard créé avec Visual Studio Code et l’extension Azure Logic Apps (standard).

    Si vous n’avez pas encore configuré votre projet ou votre infrastructure d’application logique, vous pouvez utiliser les exemples de projets inclus pour déployer un exemple d’application et d’infrastructure, en fonction des options de source et de déploiement que vous préférez utiliser. Pour plus d’informations sur ces exemples de projets et les ressources incluses pour exécuter l’exemple d’application logique, consultez Déployer votre infrastructure.

  • Si vous souhaitez effectuer un déploiement sur Azure, vous avez besoin d’une ressource Application logique (standard) existante créée dans Azure. Pour créer rapidement une ressource d’application logique vide, consultez Créer des workflows d’application logique monolocataire - Portail.

Déployer des ressources d’infrastructure

Si vous n’avez pas encore configuré de projet ou d’infrastructure d’application logique, vous pouvez utiliser les exemples de projets suivants pour déployer un exemple d’application et d’infrastructure, en fonction des options de source et de déploiement que vous préférez utiliser :

Les deux exemples incluent les ressources suivantes qu’une application logique utilise pour s’exécuter.

Nom de la ressource Obligatoire Description
Application logique (standard) Yes Cette ressource Azure contient les workflows qui s’exécutent dans Azure Logic Apps monolocataire.
Plan d’hébergement Functions Premium ou App Service Yes Cette ressource Azure spécifie les ressources d’hébergement à utiliser pour l’exécution de votre application logique, telles que le calcul, le traitement, le stockage, le réseau, etc.

Important : Dans l’expérience actuelle, la ressource Application logique (standard) nécessite le plan d’hébergement Workflow Standard, qui est basé sur le plan d’hébergement Functions Premium.

Compte Azure Storage Oui, pour les flux de travail avec et sans état Cette ressource Azure stocke les métadonnées, les clés de contrôle d’accès, l’état, les entrées, les sorties, l’historique des exécutions et d’autres informations sur vos flux de travail.
Application Insights Facultatif Cette ressource Azure fournit des fonctionnalités de supervision pour vos workflows.
Connexions d’API Facultatif, s’il n’en existe aucune Ces ressources Azure définissent toutes les connexions d’API managées que vos workflows utilisent pour exécuter des opérations de connecteur managé, comme Office 365, SharePoint, etc.

Important : Dans votre projet d’application logique, le fichier connections.json contient des métadonnées, des points de terminaison et des clés pour toutes les connexions d’API managées et fonctions Azure utilisées par vos workflows. Pour utiliser des connexions et des fonctions différentes dans chaque environnement, veillez à paramétriser le fichier connections.json et à mettre à jour les points de terminaison.

Pour plus d’informations, consultez Ressources de connexion d’API et stratégies d’accès.

Modèle Azure Resource Manager (ARM) Facultatif Cette ressource Azure définit un déploiement d’infrastructure de référence que vous pouvez réutiliser ou exporter.

Ressources de connexion d’API et stratégies d’accès

Dans Azure Logic Apps monolocataire, chaque ressource de connexion d’API ou managée dans vos workflows nécessite une stratégie d’accès associée. Cette stratégie a besoin de l’identité de votre application logique pour fournir les autorisations permettant d’accéder à l’infrastructure de connecteur managée. Les exemples de projets inclus comprennent un modèle ARM qui comporte toutes les ressources d’infrastructure nécessaires, y compris ces stratégies d’accès.

Le diagramme suivant montre les dépendances entre votre projet d’application logique et les ressources d’infrastructure :

Diagramme conceptuel montrant les dépendances d’infrastructure pour un projet d’application logique dans le modèle Azure Logic Apps monolocataire.

Déployer des ressources d’application logique (déploiement zip)

Après avoir envoyé votre projet d’application logique vers votre dépôt source, vous pouvez configurer des pipelines de build et de mise en production soit à l’intérieur, soit en dehors d’Azure, qui déploient des applications logiques sur une infrastructure.

Générer votre projet

Pour configurer un pipeline de build basé sur le type de projet de votre application logique, effectuez les actions correspondantes dans le tableau suivant :

Type de projet Description et étapes
Basé sur NuGet La structure de projet NuGet est basée sur .NET Framework. Pour générer ces projets, veillez à suivre les étapes de génération de .NET Standard. Pour plus d’informations, consultez la documentation de Créer un package NuGet avec MSBuild.
Basé sur un lot Le projet d’extension basé sur un lot n’est pas propre à un langage et ne nécessite aucune étape de génération propre au langage. Vous pouvez utiliser n’importe quelle méthode pour compresser vos fichiers projet.

Important : Assurez-vous que votre fichier .zip contient les véritables artefacts de build, y compris tous les dossiers de flux de travail, les fichiers config tels que host.json, connections.json et tout autre fichier connexe.

Avant la mise en production vers Azure

Les connexions d’API managées dans le fichier connections.json de votre projet d’application logique sont créées spécifiquement pour une utilisation locale dans Visual Studio Code. Avant de pouvoir mettre en production vos artefacts de projet Visual Studio Code dans Azure, vous devez les mettre à jour. Pour utiliser les connexions d’API managées dans Azure, vous devez mettre à jour leurs méthodes d’authentification afin qu’elles figurent dans le format approprié à utiliser dans Azure.

Mettre à jour le type d’authentification

Pour chaque connexion d’API managée qui utilise l’authentification, vous devez mettre à jour l’objet authentication à partir du format local dans Visual Studio Code au format Portail Azure, comme indiqué dans les premier et deuxième exemples de code, respectivement :

Format Visual Studio Code

{
   "managedApiConnections": {
      "sql": {
         "api": {
            "id": "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/providers/Microsoft.Web/locations/westus/managedApis/sql"
      },
      "connection": {
         "id": "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/ase/providers/Microsoft.Web/connections/sql-8"
      },
      "connectionRuntimeUrl": "https://xxxxxxxxxxxxxx.01.common.logic-westus.azure-apihub.net/apim/sql/xxxxxxxxxxxxxxxxxxxxxxxxx/",
      "authentication": {
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('sql-connectionKey')"
      }
   }
}

Format de Portail Azure

{
   "managedApiConnections": {
      "sql": {
         "api": {
            "id": "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/providers/Microsoft.Web/locations/westus/managedApis/sql"
      },
      "connection": {
         "id": "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/ase/providers/Microsoft.Web/connections/sql-8"
      },
      "connectionRuntimeUrl": "https://xxxxxxxxxxxxxx.01.common.logic-westus.azure-apihub.net/apim/sql/xxxxxxxxxxxxxxxxxxxxxxxxx/",
      "authentication": {
         "type": "ManagedServiceIdentity",
      }
   }
}

Créer des connexions d’API en fonction des besoins

Si vous déployez votre flux de travail d’application logique dans une région ou un abonnement Azure différent de votre environnement de développement local, vous devez également veiller à créer ces connexions d’API managées avant le déploiement. Le déploiement de modèle Azure Resource Manager (modèle ARM) est le moyen le plus simple de créer des connexions d’API managées.

L’exemple suivant montre une définition de ressource de connexion d’API managée SQL dans un modèle ARM :

{
   "type": "Microsoft.Web/connections",
   "apiVersion": "2016–06–01",
   "location": "[parameters('location')]",
   "name": "[parameters('connectionName')]",
   "properties": {
      "displayName": "sqltestconnector",
      "api": {
         "id": "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/sql"
      },
      "parameterValues": {
         "authType": "windows", 
         "database": "TestDB",
         "password": "TestPassword",
         "server": "TestServer",
         "username": "TestUserName"
      }
   }
}

Pour rechercher les valeurs que vous devez utiliser dans l’objet properties afin d’élaborer la définition de la ressource de connexion, vous pouvez utiliser l’API suivante pour un connecteur spécifique :

GET https://management.azure.com/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/{connector-name}?api-version=2016-06-01

Dans la réponse, recherchez l’objet connectionParameters, qui contient toutes les informations permettant d’élaborer la définition de ressource pour ce connecteur spécifique. L’exemple suivant illustre une définition de ressource pour une connexion managée SQL :

{
   "type": "Microsoft.Web/connections",
   "apiVersion": "2016–06–01",
   "location": "[parameters('location')]",
   "name": "[parameters('connectionName')]",
   "properties": {
      "displayName": "sqltestconnector",
      "api": {
         "id": "/subscriptions/{Azure-subscription-ID}/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/sql"
      },
      "parameterValues": {
         "authType": "windows",
         "database": "TestDB",
         "password": "TestPassword",
         "server": "TestServer",
         "username": "TestUserName"
      }
   }
}

Vous pouvez également capturer et examiner la trace réseau de lorsque vous créez une connexion à l’aide du concepteur de flux de travail dans Azure Logic Apps. Recherchez l’appel PUT qui est envoyé à l’API managée du connecteur comme décrit précédemment, puis examinez le corps de la demande pour obtenir toutes les informations nécessaires.

Publier sur Azure

Pour configurer un pipeline de mise en production qui effectue le déploiement sur Azure, choisissez l’option associée pour GitHub, Azure DevOps ou Azure CLI.

Notes

Azure Logic Apps ne prend pas en charge les emplacements de déploiement Azure.

Pour les déploiements GitHub, vous pouvez déployer votre application logique avec GitHub Actions, par exemple, les actions GitHub dans Azure Functions. Pour effectuer cette action, vous devez transmettre les informations suivantes :

  • Nom d’application logique à utiliser pour le déploiement
  • Fichier zip qui contient vos véritables artefacts de build, y compris tous les dossiers de flux de travail, les fichiers config tels que host.json, connections.json et tout autre fichier connexe.
  • Votre profil de publication, qui est utilisé pour l’authentification
- name: 'Run Azure Functions Action'
  uses: Azure/functions-action@v1
  id: fa
  with:
   app-name: 'MyLogicAppName'
   package: 'MyBuildArtifact.zip'
   publish-profile: 'MyLogicAppPublishProfile'

Pour plus d’informations, consultez la documentation Livraison continue avec GitHub Actions.

Après la mise en production dans Azure

Chaque connexion d’API possède des stratégies d’accès. Une fois le déploiement zip terminé, vous devez ouvrir votre ressource d’application logique dans le Portail Azure et créer des stratégies d’accès pour chaque connexion d’API afin de définir des autorisations pour l’application logique déployée. Le déploiement zip ne crée pas de paramètres d’application automatiquement. Ainsi, après le déploiement, vous devez créer ces paramètres d’application basés sur le fichier local.settings.json dans votre projet Visual Studio Code local.

Étapes suivantes

Nous aimerions que vous nous fassiez part de votre expérience avec Azure Logic Apps monolocataire.