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 :
Exemple GitHub pour Azure Logic Apps monolocataire
Cet exemple comprend un exemple de projet d’application logique pour Azure Logic Apps monolocataire ainsi que des exemples pour le déploiement Azure et pour GitHub Actions.
Exemple Azure DevOps pour Azure Logic Apps monolocataire
Cet exemple comprend un exemple de projet d’application logique pour Azure Logic Apps monolocataire ainsi que des exemples pour le déploiement Azure et pour Azure Pipelines.
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 :
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.
- Pour tout bogue ou problème que vous rencontreriez, créez un problème dans GitHub.
- Pour toute question, demande, commentaire ou retour d’expérience, utilisez de formulaire de commentaires.