Delphin Habierre

4 septembre 2019

Déployer un process Serverless avec Terraform et Azure DevOps

Nous vous avions déjà parlé de Terraform sur le blog Cellenza, pour rappel c’est un outil open source développé par HashiCorp, qui est utilisé pour provisionner et gérer des infrastructures IT dans le cloud. Écrit en Go et fonctionnant en mode Infrastructure as a Code, il permet de facilement administrer l’infrastructure grâce à du code au lieu de procéder à un ensemble d’opérations manuelles.

Pour bien débuter avec Terraform, je vous recommande la lecture de ces articles :

Dans cet article, nous allons donc voir comment déployer un processus Serverless avec Terraform et Azure DevOps. Pour rappel, le Serveless est un modèle d’architecture sans serveurs, c’est-à-dire des applications, des services ou de simples fonctions qui s’exécutent à la demande uniquement. On parle également de Function as a Service ou « FaaS », si vous souhaitez en savoir plus, nous avons traité le sujet dans notre Cell’Insights #9 – Serverless, la nouvelle révolution du Cloud ?

Rappel des objectifs pour déployer un process Serverless avec Terraform

Dans cet article, nous allons voir :

Comment mettre en place un traitement à base d’Azure Functions,
Utiliser conjointement Terraform et Azure DevOps dans l’optique de déployer l’infrastructure Azure, de manière automatique et continue.

Notre architecture d’exemple se compose de la façon suivante :

3 Azure Functions, ayant des types de trigger différents,
1 Blob Storage, pour persister les données reçues,
1 Service Bus, exposant une Queue.

Architecture Serverless Terraform

Le scénario que nous allons développer est donc le suivant :

(1) une requête HTTP/POST est initiée sur la function F1,
(2) la function F1 enregistre le body de la requête (JSON) dans le Blob Storage et poste un message (contenant le lien du blob) sur la Queue,
(3) la function F2 se déclenche, charge le JSON depuis le Blob Storage et fait un traitement,
(4) la function F3 se déclenche et fait un autre traitement.

L’intérêt de faire persister les données de la requête HTTP dans un blob est double, tout d’abord, cela permet de garder une trace des requêtes pour éventuellement les rejouer en debug. L’autre avantage est que la taille des messages sur la queue du ServiceBus est limitée.

A présent nous allons :

créer la stack Terraform pour la description déclarative de l’infrastructure,
créer la solution Visual Studio contenant les Azure Functions,
mettre en place la CI/CD avec Azure Pipelines pour l’intégration & le déploiement continu.

Sources de cet article

Vous pouvez retrouver les sources de la stack Terraform et de la solution Visual Studio sur ce repository.

Avant toute chose, je vous conseille de réaliser les actions ci-dessous :

Créez un repository sur Azure DevOps,
Uploadez les sources dessus.

Quelques prérequis avant de commencer

Avant d’aller plus loin dans cet article, vous aller avoir besoin des éléments suivants :

Note : l’installation de Terraform sur votre poste n’est pas nécessaire. Cependant, cela peut être utile pour exécuter les commandes “valide” et “plan” en local avant de procéder au commit des modifications sur le repository.

Voici également quelques outils utiles à avoir avec soi :

Création de l’infrastructure

Première partie, l’infrastructure avec Terraform

Commençons tout d’abord par définir l’infrastructure grâce à Terraform.

💡 Remarque : toutes les variables de la forme __variablename__ seront substituées lors du déploiement sur l’environnement cible.

Fichier provider.tf

Le rôle de ce fichier est de spécifier les versions de Terraform & du provider AzureRM à utiliser pour l’exécution de la stack.

Pour une exécution locale, il suffit de commenter au préalable le bloc backend (qu’il faudra évidemment dé-commenter avant tout commit).

Fichier variables.tf

Ici, le rôle de ce fichier est de définir les différentes variables.

Dans notre exemple, les variables function_f1_username & function_f1_password seront utilisées pour une Authentification Basic au niveau de la function F1.

Fichier variables.tfvars

Il est question ici d’affecter les valeurs des variables. Ici, ces variables tokeneurisées, seront substituées lors du déploiement sur l’environnement cible, lors de la Release dans Azure Pipelines.

Pour exécution locale de la stack, nous pourrons utiliser le fichier variables.local.tfvars (cf. notes dans provider.tf).

Fichier main.tf

Ce fichier contient la définition des différentes ressources Azure à créer.

Remarque : en tant que développeur, la ressource la plus intéressante est la ressource function_app / app_settings qui définie les chaînes de connexion et autres variables qui seront utilisées dans les Azure Functions.

Voici ce à quoi correspond ce fichier :

FUNCTIONS_WORKER_RUNTIME : runtime dotnet,
APPINSIGHTS_INSTRUMENTATIONKEY : clé Application Insights pour le monitoring des functions,
KeyVaultName : nom du KeyVault pour accéder aux secrets,
StorageConnectionString : chaîne de connexion pour accéder au Blob Storage,
StorageBlobContainerName : nom du conteneur du blob dans lequel seront persistées les données des requêtes,
ServiceBusConnectionString : chaîne de connexion pour accéder au Service Bus,
ServiceBusQueueName : nom de la queue exposée par le Service Bus.

Comme nous pouvons le voir, la plupart de ces variables découlent de la stack Terraform, nous n’aurons donc jamais à les renseigner, ni dans les variables Terraform (variables.tfvars), ni côté Azure DevOps (variables de la Release).

Côté C# / Functions, ces variables seront injectées dans les variables d’environnement et chargées à leur habitude via l’objet IConfigurationRoot.

Nous pouvons remarquer qu’il n’y a pas de trace des variables pour l’authentification (function_f1_username & function_f1_password). En effet, elles seront protégées par le KeyVault (et chargées également par IConfigurationRoot).

Fichier complet :

Azure DevOps – Build

Voici la définition de la Build qui va tout simplement permettre de packager les fichiers Terraform.

Pour rappel, il n’y a aucune substitution de variable au niveau de la Build. Cette opération sera réalisée lors de la phase de Release.

Terraform build Azure DevOps

Nous activons l’intégration continue dès qu’une modification est effectuée sur des fichiers du répertoire terraform/

Terraform build Azure DevOps

Lorsque la première build est effectuée, nous obtenons l’artifact suivant :

Terraform build Azure DevOps

Azure DevOps – Release

Créons à présent la phase de Release dans Azure DevOps.

Terraform build Azure DevOps

💡 Important : je recommande d’utiliser ici le Host 2017. Avec le Host 2019, en cas d’erreur, Terraform n’affiche pas le message.

L’étape suivante permet de mettre en place le backend des states de Terraform sur le Blob Storage partagé (resource group shared) si celui-ci n’existe pas.