Infra as code : créer un blogue multi régions avec Terraform sur Cloud Public – 1re partie

Infra as code : créer un blogue multi régions avec Terraform sur Cloud Public – 1re partie

Terraform, développé par HashiCorp, fait partie des solutions de choix pour bâtir et orchestrer efficacement une architecture en mode infrastructure en tant que code. Dans cette série d’articles, nous allons illustrer de façon concrète l’intérêt d’utiliser cet outil avec le cloud public OVH pour déployer  et mettre à jour un site Web hautement disponible en multi régions. Votre mission, si vous l’acceptez : déployer un blogue jusqu’en production avec certificats Let’s Encrypt et enregistrement de nom de domaine pour moins de 10 euros  (environ 15,00 $ CAD) par mois!

L’idée n’est pas de proposer un guide pas à pas (notre documentation est là pour ça), mais plutôt de montrer à l’aide d’un projet concret comment et pourquoi Terraform répond aux attentes du moment en matière d’orchestration et d’automatisation. Une bonne façon de s’ouvrir au potentiel de l’infra en tant que code!

Dans ce billet, nous rappellerons l’intérêt de Terraform et présenterons brièvement les concepts qui en sous-tendent l’utilisation : fournisseur, ressource, variable et sorite (outputa0, ainsi que la notion d’état du projet et d’espaces de travail, indispensable pour le travail collaboratif.

 

Terraform en quelques mots?

Terraform est un outil open source qui permet de créer et maintenir des infrastructures complexes dans le cloud. Écrit en Go, il exploite des fichiers de configuration déclaratifs qui décrivent l’infrastructure et définissent la façon dont elle se répartit entre des fournisseurs différents. Terraform gère indifféremment les clouds publics ou privés.

Dit autrement, l’outil orchestre indifféremment les appels d’API vers une longue liste de fournisseurs et prend en charge toutes les ressources d’une architecture, des machines virtuelles aux enregistrements DNS en passant par les bases de données, les éléments réseau, les blocs de stockage ou l’architecture logicielle. Il n’est pas agnostique, mais par sa nature extensible, il s’accommode de plateformes très variées.

Pourquoi ça change la donne? Avec Terraform, chaque élément de l’architecture ainsi élaborée est susceptible d’être édité, versionné ou partagé sur un dépôt. On profite donc d’environnements aisément reproductibles grâce à l’automatisation, avec suivi complet des modifications et gestion du cycle de vie, le tout à partir d’un code à la fois maintenable et compréhensible.

 

Fournisseur et Ressources

La description de l’infrastructure se fait au moyen de fichiers de configuration (.tf), qui peuvent être écrits soit au moyen d’une syntaxe spécifique (HCL), soit en JSON. La première étape consiste à configurer le fournisseur du projet, c’est-à-dire celui qui va héberger les ressources nécessaires à la création et au développement d’applications. En pratique, il n’est pas rare de faire appel à plusieurs fournisseurs au sein d’un même projet : c’est même l’une des raisons d’être de Terraform.

Voici par exemple comment décrire le provider OpenStack hébergé par OVH.

Terraform provider

Il suffit ensuite d’initialiser l’environnement pour être en mesure de créer ou nettoyer (détruire) une ressource.

Terraform resource

 

Variables et Sorties

Impossible de déployer à grande échelle et de façon sécurisée avec des valeurs inscrites en dur dans des fichiers de configuration : dans une optique d’infrastructure en tant que code, on cherche à obtenir le résultat le plus générique possible. Terraform prévoit donc la déclaration d’un certain nombre de variables qui serviront comme autant de paramètres pour les différentes ressources du projet. Il s’agira par exemple du nom servant à identifier une ressource, d’identifiants de connexion ou de la région de déploiement. Ces variables sont assignables à partir des fichiers de configuration, de la ligne de commande ou de paramètres liées à l’environnement d’exécution.

Après les variables en entrée (input), il est logique de formater la sortie (output) pour obtenir des données exploitables, soit par l’utilisateur final, soit par des modules Terraform. Ce sont ces sorties (adresse IP d’une ressource par exemple) qui serviront ensuite à exposer les données et exploiter l’infrastructure.

Dans cet exemple, nous voyons par exemple comment l’utilisation des variables permet de modifier la région sur laquelle on déploie un container.

Terraform vars

 

Centraliser l’état et les espaces de travail

À chaque exécution, Terraform créée un fichier d’état baptisé terraform.state qui référence, au format JSON, les ressources déployées et leur statut. Il est stocké localement, mais peut aussi être conservé sur un espace partagé via la fonction « Remote Backend », pour faciliter le travail en équipe et garantir que tout le monde dispose bien d’un état à jour de l’infrastructure.

Terraform remotestate

 

Grâce à ces informations, Terraform déterminera à la prochaine commande d’exécution quelles sont les actions à réaliser pour obtenir la liste des ressources listées dans les fichiers de configuration à partir de ce qui est déjà en production. Vous pouvez également gérer d’autres environnements en utilisant les espaces de travail. Vous pourrez avoir plus de détails sur ces fonctionnalités en allant voir cet exemple,

Voilà qui conclut ce premier volet! Dans notre prochain billet, nous étudierons plus en en détails les modalités d’exploitation de Terraform sur le cloud public OVH, et commencerons à déployer une première version de notre blogue.

Pour connaître le détail complet des recettes Terraform liées à cet article, consultez nos articles Github :

- Installation et configuration de Terraform ;

- Utilisation des variables et des formats de sortie ;

- Bonnes pratiques et gestion du status.