Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : Azure Logic Apps (Standard)
Ce guide montre principalement comment configurer le déploiement d’un projet d’application logique Standard dans Visual Studio Code sur votre infrastructure à l’aide d’outils et de processus DevOps. Si votre application logique Standard existe dans le Portail Azure, vous pouvez télécharger les fichiers d’artefact de votre application logique à utiliser avec le déploiement DevOps. Selon que vous souhaitez utiliser GitHub ou Azure DevOps, choisissez le chemin d’accès et les outils qui conviennent le mieux pour votre scénario de déploiement.
Si vous n’avez pas d’application logique Standard, vous pouvez toujours suivre ce guide à l’aide de l’exemple lié de projets d’application logique Standard, ainsi que des exemples de déploiement sur Azure via GitHub ou Azure DevOps. Pour plus d’informations, consultez la vue d’ensemble du déploiement DevOps pour Azure Logic Apps à locataire unique.
Prérequis
Compte Azure avec un abonnement actif. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit.
Application logique Standard à utiliser avec vos outils et processus DevOps.
Vous pouvez télécharger les fichiers d’artefact de votre ressource d’application logique Standard à partir du portail Azure, ou utiliser un projet d’application logique standard créé avec Visual Studio Code et l’extension Azure Logic Apps (Standard) pour Visual Studio Code.
Portail : le fichier zip téléchargé contient des fichiers d’artefacts d’application logique Standard, tels que workflow.json, connections.json, host.jsonet local.settings.json. Veuillez consulter la rubrique Télécharger les fichiers d’artefacts d’application logique Standard à partir du portail.
Visual Studio Code : vous avez besoin d’une ressource d’application logique Standard vide dans le portail Azure pour votre destination de déploiement. Pour créer rapidement une ressource d’application logique standard vide, consultez Créer des flux de travail d’application logique à locataire unique - Portail.
Si vous n’avez pas d’application logique ou d’infrastructure existante, vous pouvez utiliser l’exemple lié de projets d’application logique Standard pour déployer un exemple d’application logique et d’infrastructure, selon que vous souhaitez utiliser GitHub ou Azure DevOps. Pour plus d’informations sur les exemples de projets et de ressources inclus pour exécuter l’exemple d’application logique, consultez Déployer les ressources d’infrastructure.
Déployer des ressources d’infrastructure
Pour essayer l’expérience de déploiement DevOps sans configuration préalable de l’application logique Standard ou de l’infrastructure, utilisez les exemples de projets suivants pour configurer le déploiement pour un exemple d’application logique Standard et d’infrastructure, selon que vous souhaitez utiliser GitHub ou Azure DevOps :
Exemple GitHub pour Azure Logic Apps monotenant
Cet exemple inclut un exemple de projet d’application logique Standard ainsi que des exemples pour le déploiement Azure et GitHub Actions.
Exemple d'Azure DevOps pour Azure Logic Apps à locataire unique
Cet exemple inclut un exemple de projet d’application logique Standard ainsi que des exemples pour le déploiement Azure et Azure Pipelines.
Les deux exemples incluent les ressources suivantes qu’une application logique Standard utilise pour s’exécuter :
Nom de la ressource | Obligatoire | Descriptif |
---|---|---|
Application logique Standard | Oui | Cette ressource Azure contient les workflows qui s’exécutent dans Azure Logic Apps monolocataire. Important : dans votre projet d’application logique, chaque flux de travail a un fichier workflow.json qui contient la définition de flux de travail, qui inclut les définitions de déclencheur et d’action. |
Connexions d’API | Oui, si des connexions d’API existent | 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 les fonctions Azure utilisées par vos flux de travail. Pour utiliser différentes connexions et fonctions dans chaque environnement, veillez à paramétrer le fichier connections.json et à mettre à jour les points de terminaison. Pour plus d’informations, consultez les ressources de connexion d’API et les stratégies d’accès. |
Plan d’hébergement Functions Premium ou App Service | Oui | 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 d’application logique Standard nécessite le plan d’hébergement Standard de workflow, qui est basé sur le plan d’hébergement Azure Functions Premium. |
Compte de stockage Azure | 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. |
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 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.
Par exemple, le diagramme suivant montre les dépendances entre un projet d’application logique Standard et les ressources d’infrastructure :
Télécharger les artefacts d’application logique Standard à partir du portail
Si votre application logique Standard se trouve dans le portail Azure, vous pouvez télécharger un fichier zip qui contient les fichiers d’artefact de votre application logique, notamment workflow.json, connections.json, host.jsonet local.settings.json.
Dans le portail Azure, recherchez et ouvrez votre ressource d’application logique Standard.
Dans le menu de l’application logique, sélectionnez Vue d’ensemble.
Dans la barre d’outils Vue d’ensemble , sélectionnez Télécharger le contenu de l’application. Dans la zone de confirmation qui s’affiche, sélectionnez Télécharger.
Lorsque l’invite s’affiche, sélectionnez Enregistrer sous, accédez au dossier local souhaité, puis sélectionnez Enregistrer pour enregistrer le fichier zip.
Extrayez le fichier zip.
Dans Visual Studio Code, ouvrez le dossier contenant les fichiers décompressés.
Lorsque vous ouvrez le dossier, Visual Studio Code crée automatiquement un espace de travail.
Modifiez le contenu du dossier pour inclure uniquement les dossiers et fichiers nécessaires pour le déploiement à l’aide de DevOps.
Lorsque vous avez terminé, enregistrez vos modifications.
Générer et déployer une application logique (déploiement zip)
Vous pouvez configurer des pipelines de build et de mise en production à l’intérieur ou à l’extérieur d’Azure qui déploient des applications logiques Standard sur votre infrastructure.
Générer votre projet
Envoyez (push) vos fichiers de projet et d’artefact d’application logique Standard vers votre référentiel source, par exemple GitHub ou Azure DevOps.
Configurer un pipeline de build basé sur le type de projet de votre application logique, en effectuant les actions correspondantes suivantes :
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 relative à la création d’un package NuGet à l’aide de 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. Compressez vos fichiers projet à l’aide de n’importe quelle méthode souhaitée.
Important
Assurez-vous que votre fichier zip contient les artefacts de build réels de votre projet au niveau racine, y compris tous les dossiers de flux de travail, fichiers de configuration tels que host.json, connections.json, local.settings.jsonet tous les autres fichiers associés. N’ajoutez pas de dossiers supplémentaires ni ne placez d’artefacts dans des dossiers qui n’existent pas déjà dans la structure de votre projet.
Par exemple, la liste suivante montre un exemple MyBuildArtifacts.zip structure de fichiers :
MyStatefulWorkflow1-Folder MyStatefulWorkflow2-Folder connections.json host.json local.settings.json
Avant de publier sur 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Web/locations/westus/managedApis/sql"
},
"connection": {
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ase/providers/Microsoft.Web/connections/sql-2"
},
"connectionRuntimeUrl": "https://xxxxxxxxxxxxxx.01.common.logic-westus.azure-apihub.net/apim/sql/xxxxxxxxxxxxxxxxxxxxxxxxx/",
"authentication": {
"type": "Raw",
"scheme": "Key",
"parameter": "@appsetting('sql-connectionKey')"
}
}
}
}
Format du portail Azure
{
"managedApiConnections": {
"sql": {
"api": {
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Web/locations/westus/managedApis/sql"
},
"connection": {
"id": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ase/providers/Microsoft.Web/connections/sql-2"
},
"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 application logique Standard 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Web/locations/{Azure-region-location}/managedApis/sql"
},
"parameterValues": {
"authType": "windows",
"database": "TestDB",
"password": "TestPassword",
"server": "TestServer",
"username": "TestUserName"
}
}
}
Pour rechercher les valeurs nécessaires pour l’objet properties
afin de pouvoir terminer la définition de ressource de connexion, utilisez 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 les informations nécessaires pour compléter 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 du connecteur managé comme décrit précédemment, puis examinez le corps de la demande pour obtenir toutes les informations nécessaires.
Définition de ressource de passerelle de données locale
Si votre connexion utilise une ressource de passerelle de données locale, cette définition de ressource existe séparément de la définition de ressource du connecteur. Pour afficher la définition de ressource de la passerelle de données, consultez Automatiser le déploiement pour Azure Logic Apps à l’aide de modèles Azure Resource Manager et de Microsoft.Web connectionGateways.
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.
Pour les déploiements GitHub, vous pouvez déployer votre application logique à l’aide de GitHub Actions, par exemple, gitHub Actions 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 artefacts de build réels, y compris tous les dossiers de flux de travail, fichiers de configuration tels que host.json, connections.json, local.settings.jsonet tous les autres fichiers associés.
- Votre profil de publication, 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, passez en revue la livraison continue à l’aide de GitHub Action.
Après le déploiement sur 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 Standard 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. Après le déploiement, vous devez créer ces paramètres d’application en fonction du fichier local.settings.json dans votre projet d’application logique.
Contenu connexe
Nous aimerions que vous nous fassiez part de votre expérience avec Azure Logic Apps monolocataire.
- Pour les bogues ou les problèmes, créez vos problèmes dans GitHub.
- Pour des questions, des demandes, des commentaires et d’autres commentaires, utilisez ce formulaire de commentaires.