Accueil > Déployer un process Logic App avec Azure DevOps & Terraform
Delphin Habierre

Déployer un process Logic App avec Azure DevOps & Terraform

Déployer un process Logic App avec Azure DevOps & Terraform

Dans cet article, nous allons voir comment déployer un process Logic App avec Terraform et Azure DevOps, de manière automatisée et continue.

Pour rappel, Logic App est un service Azure qui permet de créer des workflows, d’automatiser l’exécution de processus métier mais aussi d’intégrer une multitude de composants entre eux, à l’image de Biztalk et Worflow Fondation. Dans cet article, nous n’allons pas présenter la façon de créer des Logic Apps, un exemple de type HelloWorld déjà implémenté est fourni.

💡 Remarque : le service LogicApp n’est pas disponible sur toutes les régions. Nous utiliserons donc la région WestEurope (Ireland) pour nos tests. Si vous souhaitez en savoir plus sur ce service, voici le lien vers la documentation officielle : https://docs.microsoft.com/fr-fr/azure/logic-apps/

Si vous débuter avec Terraform, je vous recommande la lecture de l’article suivant :

 

Les pré-requis pour se lancer dans ce tutoriel

Avant d’aller plus loin, voici ce dont nous aurons besoin pour déployer un processus de Logic App avec Azure DevOps & Terraform :

 

Côté Logic App

Toutes les sources de ce blog post sont disponibles à cette adresse.

Nous allons d’abord procéder à la création d’un Logic App avec un trigger de type HTTP, c’est-à-dire un worflow qui sera déclenché par un appel HTTP.

Commençons par créer un nouveau projet de type Azure Resource Group :

 

nouveau projet de type Azure Resource Group

 

configuration d'nouveau projet de type Azure Resource Group

 

Puis, sélectionnons le template Logic App :

 

nouveau projet de type Azure Resource Group et template logic app

 

Dans le Solution Explorer, ouvrons à présent le Designer avec un clic droit sur LogicApp.json puis Open With Logic App Designer (ou Ctrl + L). Voici notre petit workflow :

 

Déployer un process Logic App avec Azure DevOps & Terraform

 

Si l’on résume, voici le découpage étape par étape :

  • Step 1 : déclencheur HTTP sur méthode POST, avec un body { « name »: « value » },
  • Step 2 : création d’une variable Message et affectation de sa valeur,
  • Step 3 : réponse retour au destinataire.

💡 Remarques :

  • le visuel fx parameters(…) dans le bloc Initialize variable correspond à la valeur du paramètre environment qui sera passée en paramètre du Logic App (cf. fichier LogicApp.json),
  • l’endpoint HTTP du Logic App sera connu lors du déploiement de celui-ci sur Azure. Nous verrons par la suite comment le récupérer depuis le KeyVault.

Le Logic App prend en entrée différents paramètres. Dans notre exemple, nous utilons le paramètre environment dans le message retour. Ces paramètres seront définis dans la Release Logic Apps d’Azure DevOps.

 

Du côté de Terraform

Terraform sous Windows

Cette étape n’est pas obligatoire pour la suite de l’article. A suivre uniquement si vous souhaitez tester la stack Terraform en local, avant de passer par Azure DevOps.

  1. Installation de Chocolatey

Source : https://chocolatey.org/install

 

  1. Installation de Terraform

Source : https://chocolatey.org/packages/terraform

 

💡 Remarque : nous forçons la version pour être en accord avec la version spécifiée dans le fichier provider.tf (que nous allons voir très bientôt). Vous pouvez installer la dernière version (sans spécifier la version). Dans ce cas, pensez à modifier le fichier provider.tf en conséquence.

Ouvrons un nouveau terminal et vérifions que le binaire Terraform est bien dans le PATH :

terraform.exe --version

La version s’affiche, Good ! 😃

 

Définition de la stack Terraform

Commençons tout d’abord par définir l’infrastructure Azure.

 

provider.tf

Le rôle de ce fichier est de spécifier la version de Terraform et du provider AzureRM à utiliser lors de l’exécution de la stack.

Le voici dans sa forme la plus simpliste (des évolutions sont prévues par la suite) :

 

J’ai l’habitude de spécifier la version de Terraform aussi bien dans ce fichier que côté Azure DevOps pour éviter tout effet de bord lors des montées de version.

 

main.tf

Ce fichier, quant à lui, contient la définition des différentes ressources Azure à déployer.

💡 Remarque : nous faisons intervenir la ressource azurerm_key_vault car nous l’utiliserons pour stocker, de manière automatique et sécurisée, l’enpoint HTTP du Logic App.

 

variables.tf

Ce fichier défini les différentes variables :

 

variables.tfvars

Il est question ici d’affecter les valeurs des variables :

 

Ces variables, tokeneurisées, seront substituées lors du déploiement sur l’environnement cible, lors de l’exécution de la Release dans Azure DevOps.

 

variables.local.tfvars

Pour une exécution locale (à des fins de test), nous pourrons utiliser le fichier variables.local.tfvars :

 

Procédons au test de la stack en local

Le fait de tester localement permet de s’assurer que la stack Terraform est valide, sans pour autant mettre en place les Builds et Releases côté Azure DevOps. Cela permet de gagner du temps sur la phase de conception initiale de la stack.

Une fois la première version validée, il ne sera plus question d’exécution manuelle, nous passerons par Azure DevOps et de multiples environnements (DEV, REC, QA, etc.).

Avant tout, nous devons créer un Service Principal (si vous n’en avez pas déjà un).

Source : https://www.terraform.io/docs/providers/azurerm/auth/service_principal_client_secret.html

 

Exportons les variables d’environnement suivantes dans une console Powershell :

 

Il est plus sûr d’utiliser des variables d’environnement (certes c’est moins pratique…) que de mettre les valeurs dans le fichier provider.tf. Cela évitera que les valeurs (surtout CLIENT_SECRET) se retrouvent sur le repository GIT par erreur.

Initialisons le provider Terraform (cette action n’est à réaliser qu’une seule fois) :

terraform.exe init

 

Créons finalement la stack sur le compte Azure :

terraform.exe apply -var-file="variables.locals.tfvars"

 

Si tout fonctionne, les ressources sont créées sur Azure. Nous pouvons à présent supprimer le Resource Group pour libérer les ressources.

 

Preparation à Azure DevOps

Etant donné que le déploiement de la stack Terraform se fera au travers d’Azure DevOps et non plus à la main, modifions le fichier provider.tf comme suit :

 

La section backend définie l’emplacement d’un Storage Account + Blob sur lequel seront stockés les states Terraform.

 

Côté Azure DevOps

Pour rappel, les sources utilisées dans cet article sont disponibles sur GitHub à cette adresse.

 

Repository

Créons un nouveau projet dans Azure DevOps et uploadons-y les sources ci-dessus :

 

Définition des Builds

Les 2 Builds sont relativement simples :

  • Build Terraform : copier les fichiers Terraform et publier le ZIP,
  • Build LogicApps : copier les fichiers Logic App et publier le ZIP.

Voici la définition de la Build Terraform :

 

💡 Notons que nous utilisons ici un agent de build Ubuntu car nous n’utilisons aucune spécificité Windows.

 

Exactement sur le même principe, la build de la solution LogicApps :

 

 

Définition des Releases

Nous définissons à présent 2 Releases :

  • une Release pour la création et mise à jour de la stack Terraform,
  • une Release de déploiement des LogicApps dans leurs conteneurs (conteneurs créés et configurés par la Release Terraform).

 

Release de Terraform

Définition de la Release :

 

Cette étape crée le backend (= Storage Account + Blob) afin de stocker les states de Terraform, un state (= un fichier) par environnement.

 

Script Azure CLI :

 

Cette étape récupère l’Access Key du Storage Account créé précédemment et positionne la valeur de la variable tf_storage_account_key. Avec cette clé, le process pourra accéder aux states dans les steps Terraform suivants.

 

Script Powershell :

 

Etape faisant la variabilisation dans les différents fichiers contenant des variables à substituer, selon l’environnement cible.

 

Step Terraform initialisant le provider AzureRM avec la version spécifiée dans le fichier provider.tf.

 

Step Terraform appliquant la stack.

 

💡 Remarque : nous utiliserons uniquement les actions init et apply de Terraform dans un souci de simplification.

Définition des variables et de leurs valeurs qui seront passées à la stack Terraform (cf. variables.tfvars).

 

Une fois la Release déployée nous obtenons les Resource Groups suivants :

 

Pour rappel, logicapps-shared contient un Storage Account qui stocke les states de Terraform.

Contenu de logicapps-dev :

 

Release LogicApps

Définition de la Release :

 

Step déployant le LogicApp :

 

Le champs Override template parameters permet de spécifier les valeurs des paramètres à passer au Logic App lors de son déploiement. Ces variables peuvent être définies dans la section Variables de la Release.

Step récupérant l’Url du LogicApp et l’enregistrant dans le KeyVault, sous la clé LogicApp–Hello–Endpoint :

 

Script Powershell :

 

Définition des variables et de leurs valeurs par environnement (Scope ‘Release’ = quelque soit l’environnement, si non défini sur un scope précis).

 

Récupération de l’endpoint HTTP du LogicApp en C#

Une fois la Release LogicApps exécutée, il est possible de récupérer l’endpoint au travers du KeyVault :

 

 

Ce secret peut être récupéré côté C# via l’objet ConfigurationRoot :

 

Notons l’importance de la syntaxe XXX–XXX–XXX de la clé, qui est traduite en XXX:XXX:XXX en C#.

Pour cela, il faudra ajouter le package nuget Microsoft.Extensions.Configuration.AzureKeyVault au projet.

Exemple d’utilisation dans une WebApp :

 

Reste à effectuer un appel POST sur l’endpoint en utilisant une instance HttpClient et le body attendu ({ « name »: « John Doe » }) !

 

Conclusion

Dans cet article, nous avons vu comment provisionner une infrastructure Azure avec Terraform pour déployer un LogicApp et stocker son endpoint secret, le tout, déployé de manière continue au travers l’excellent Azure DevOps 😃

Nos autres articles
Commentaires
Laisser un commentaire

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.