DevOps pour les Logic Apps Standard

Du 13 au 15 juin 2022 s’est déroulé le salon Integrate 2022, le rendez-vous incontournable autour de l’intégration. 

Pour ceux qui souhaitent avoir une idée macro et un retour sur ces trois jours, je vous invite à consulter notre article sur les grandes annonces faites lors de cette édition.  

Je vous propose dans ce nouvel article de nous intéresser à l’automatisation du déploiement des Logic Apps Standard (dites « single-tenant ») via des pipelines CI/CD et tout ce qui a été évoqué pour ce besoin lors de l’Integrate 2022 : nouveautés d’intégration continue et de déploiement continu (CI/CD) et les écueils qu’on peut rencontrer.   

Cet article est une traduction de l’article de Wagner Silveira, disponible en version originale ici.

Séparation des responsabilités et nouvelle structure 

Le nouveau modèle des Logic Apps Standard permet la possibilité de séparer les responsabilités, ce qui favorise le découplage entre le code du workflow (l’application) et l’infrastructure en soi (représentant le service Azure).  

Vous pouvez désormais développer, générer, compresser et déployer votre application séparément en tant qu’artefact immuable sur différents environnements. Les Logic Apps 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 Logic App et consacrer moins de temps au déploiement des ressources nécessaires dans plusieurs environnements. 

Pour le projet basé sur un bundle par défaut (NodeJs), nous avons une structure de dossiers et de fichiers similaire à celle de l’exemple suivant :

Logic Apps Standard : les composants indispensables

L’automatisation du déploiement de Logic Apps Standard via un pipeline CI/CD nécessite un processus différent de celui utilisé par Logic Apps Consumption (multitenant).

Étant donné que Logic Apps Standard encapsule désormais un groupe de workflows dans une seule unité de déploiement (Logic App Standard), pour pouvoir automatiser entièrement le processus de déploiement, les composants suivants sont requis :

L’infrastructure :

• Une ressource type « Logic App Standard » (incluant les dépendances comme « App service plan » & « Storage Account »)
• Les connecteurs dits « gérés » (également connus sous le nom « Azure Connectors »)

Le code :

• json
• La configuration des connexions (connections.json)
• La configuration des paramètres (parameters.json)
• La configuration de l’App (App Settings)

Deux éléments doivent être pris en compte lors du déploiement des connecteurs Azure (connecteurs gérés) :

1. Les politiques d’accès (Access Policies)

Les Logic Apps nécessitent une autorisation de lire les secrets de connexion via une API pour interagir avec le backend du connecteur.

Pour les Logic Apps multilocataires (dites « multi-tenant » ou « consumption Logic App »), cela est implémenté en interne (en tant que service Cloud partagé, le service principal Logic App dispose de ces autorisations nativement pour lire les secrets de connexion).

Tandis que pour le cas d’une Logic App standard, comme l’exécution (Runtime) est hébergée dans l’environnement du client, il est nécessaire d’ajouter explicitement une stratégie d’accès à la connexion (Azure connector) pour ajouter des autorisations pour l’identité gérée attribuée par le système de Logic App.

Pour cela, dans le modèle ARM du Logic App, nous allons créer une identité gérée par le système, utiliser ainsi cette valeur d’identité dans le modèle ARM de la connexion gérée (Azure connector) et ajouter la stratégie d’accès souhaitée.

2. L’URL d’exécution de la connexion gérée :

Dans Logic App Standard, le fichier connections.json contient un champ appelé « connectionRuntimeUrl » qui fait référence à l’URL d’exécution de la connexion Azure utilisée. Par conséquent, lors du déploiement des workflows, il est important de récupérer la « connectionRuntimeUrl » de la connexion Azure qui est déployée dans le portail et de l’appliquer à l’entrée correcte dans le fichier connections.json.

Pour cela, dans le modèle ARM de création de la connexion gérée, pensez à ajouter l’URL d’exécution de la connexion en tant que paramètre d’application (app settings) ainsi que dans le fichier connections.json, qui fera référence à ce paramètre d’application.

Pour plus de détails sur ces concepts, je vous invite à vous référer au schéma ci-dessous et à la documentation Microsoft.

Déploiement de Logic App Standard étape par étape

En se basant sur les considérations du schéma ci-dessus, je vous propose de détailler les étapes de déploiement Logic App standard (infrastructure), de ses workflows (code d’application) avec les trois types de connexions (connexions intégrées natives/de fournisseur de services, connexions Azure et connexions de fonction).

Étape 1 – Créer le modèle ARM de l’infrastructure Logic App

Dans ce modèle, nous ajoutons une ressource d’infrastructure Logic App et toutes les ressources dépendantes telles que le compte de stockage, Application Insight, le plan de service d’application et les configurations VNET. Dans cette étape, nous allons :

• Définir le modèle ARM pour déployer la Logic App et ses ressources dépendantes.
• Activer l’identité managée sur la ressource Logic App et générer l’ID du Tenant Azure et l’ObjectId de l’identité managée

Exemple :

Étape 2 – Créer le modèle ARM des connexions gérées

Dans ce modèle, nous ajoutons des ressources de connexion Azure. Ce modèle prendra les entrées du modèle précédent et les utilisera pour créer une stratégie d’accès pour l’identité gérée de la Logic App. Dans cette étape, nous allons :

• Définir le modèle ARM pour les connexions API à utiliser dans Logic App
• Ajouter la stratégie d’accès pour fournir l’accès à l’identité gérée de Logic App
• Générer l’URL d’exécution de la connexion « connectionRuntimeUrl»

Exemple :

Étape 3 – Préparer le pipeline Infrastructure as Code (IaC)

Une fois que les deux modèles (infrastructure de la Logic App et des connexions) sont prêts, passons au pipeline DevOps pour déployer ces ressources sur Azure et mettre à jour les paramètres de l’application.

Le pipeline DevOps doit comprendre les étapes ci-dessous :

• Déployer le modèle d’infrastructure Logic App
• Récupérer les paramètres de sortie ARM (Output)
• Déployer le modèle des connexions
• Récupérer les paramètres de sortie ARM (Output)
• Ajouter l’URL d’exécution de la connexion dans la configuration des paramètres de l’application (App Settings)

Exemple :

Étape 4 – Préparer le pipeline CI (Intégration Continue)

Dans cette étape, nous allons créer un package ZIP du dossier des workflows, basé sur le référentiel de code source. Par exemple, vous pouvez pousser votre projet VSCode vers le contrôle de code source (Azure DevOpsèRepo Git) et déclencher une exécution de ce pipeline à l’issue d’un commit.

Mettons à jour la section des connexions Azure « connections.json » avec la propriété de paramètre d’application de l’URL d’exécution de la connexion « connectionRuntimeUrl » et paramétrons le champ d’authentification (on crée un fichier de paramètres pour stocker les détails d’authentification

Je vous invite à vous référer à l’extrait de code du fichier connections.json pour plus de détails.

Pour le Pipeline CI, veuillez suivre les étapes ci-dessous :

• Ajouter le dossier du projet à votre repo Git.
• Créer un pipeline DevOps pour zipper le dossier du projet et publier les artefacts générés.

Exemple :

Étape 5 – Préparer le pipeline de CD (Déploiement Continue)

Dans cette étape, nous allons créer un pipeline pour déployer le package zip créé à l’étape précédente. Pour cela, nous mettons à jour les App Settings de la Logic App afin que les configurations mises dans le fichier « connections.json » puissent matcher durant l’exécution.

Pour le Pipeline CD, veuillez suivre les étapes ci-dessous :

• Injecter les valeurs de l’App Settings pour les connexions gérées et celles de l’app (Logic App)
• Déployer les workflows à partir du package archivé dans le pipeline CI

Exemple :

L’essentiel à retenir

Il est important de passer du temps et d’envisager de tirer parti de l’automatisation dans tout type de plateforme/service ; cela vous fera non seulement gagner du temps, mais rendra également votre application plus évolutive et stable à long terme, ce qui vous fera économiser des efforts et des coûts.

🔊 Ressources : vous trouverez ci-après le lien du code source utilisé pour l’aboutissement de cet article : https://github.com/hbrigui/LogicAppStandardCICD