Infra as code : créer un blog multi régions avec Terraform sur Public Cloud – Part 1

Temps de lecture estimé : 5 minute(s)

Terraform, développé par HashiCorp, fait partie des solutions de choix pour bâtir et orchestrer efficacement une architecture en mode Infrastructure as 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 blog jusqu’en production avec certificats Let’s Encrypt et enregistrement de nom de domaine pour moins de 10 euros 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 as 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 : provider, resource, variable et output, 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.

Provider et Resources

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 provider du projet, c’est-à-dire le fournisseur 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 providers 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.

 

provider "openstack" {
   # URL d'authentification
   auth_url = "https://auth.cloud.ovh.net/v2.0"
   region   = "SBG3"
}
provider

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

 

resource "openstack_objectstorage_container_v1" "backend" {
  region         = "SBG3"
  name           = "demo" 
}
resource

Variables et Outputs

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 as 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.

variable "region" {
  description = "The id of the openstack region"
  default = "SBG3"
}

resource "openstack_objectstorage_container_v1" "backend" {
  region         = "${var.region}"
  name           = "demo" 
}
vars

Centraliser l’état et les espaces de travail

A 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 {
  backend "swift" {
    container = "demo-remote-state"
  }
}
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 blog.

 

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