Dans vos approches d’Infrastructure as Code, l’un des produits fréquemment utilisé est Terraform, de la société Hashicorp. Nous allons voir les différentes installations du produit, allant d’un travail unitaire jusqu’aux solutions plus collaboratives.

Ce premier article décrit les solutions Terraform existantes, et revient sur les basiques de Terraform et sur son installation locale (Terraform communautaire).

Mes prochains articles présenteront Terraform Cloud avec la création de son compte et de son Workspace, le lien vers un repository GitHub et les méthodes d’authentification pour une équipe.

Puis nous testerons les deux méthodes de Run/Apply, soit en local soit en remote.

Il s’agit d’une découverte de Terraform, pour les non-initiés. Des exemples plus complets sont fournis dans les manuels Terraform, et je vous encourage à les parcourir (voir les liens au bas de chaque article).

 

L’offre Terraform

3 offres produits existent pour Terraform :

• Offre Open-source ou communautaire : elle est gratuite et permet la création des ressources, à partir de « provider public » téléchargeables (lien vers et appel des APIs) et fournis par les principaux acteurs du Cloud et des éditeurs de software.

 

• Offre Terraform Cloud : Pour une approche multi-cloud et multi-équipe. Il fournit un workflow pour délivrer, sécuriser, gouverner et vérifier toute infrastructure. L’hébergement est fait dans l’infrastructure Cloud d’HashiCorp, et de nombreux « providers » sont fournis. C‘est une Offre payante, mais utilisation gratuite pour les périmètres restreints.
  

 

• Offre Terraform Enterprise : Pour les grandes entreprises voulant garder la main sur l’installation et présence des données localement, ils peuvent installer et administrer le Terraform Collaboratif sur leur on-premises.

 

Si vous commencez sur Terraform, veillez à démarrer sur la version 0.12.9+, il y a eu un gap technologique, avec une revue syntaxique du langage par rapport à la version précédente 0.11.

 

Les basiques de Terraform

Terraform permet à partir d’un script, en langage HCL, de créer et supprimer des ressources chez les principaux Cloud Provider et de gérer leur évolution.

Par exemple, nous pourrons comparer le périmètre existant du résultat attendu par le fichier descriptif TF. De plus, TF indiquera les actions prévisionnelles pour parvenir au résultat : modification ou suppression/recréation de ressources.

 

Par exemple, le script ci-dessous permet de créer une instance Aws ec2 :

 

Dans l’approche la plus simple, nous installons localement Terraform sur notre PC.

Cela consiste en un download du binaire Terraform, et la mise à jour du PATH pour l’appel.

Nous configurons les accès et crédentials vers notre (nos) Cloud provider, en évitant l’écriture en dur dans les scripts.

Typiquement, nous pouvons réutiliser les configurations des clients Cloud avec les clés API ou les variables d’environnement de notre système.

 

Après création du script TF, comme celui donné en exemple, nous lançons directement les commandes :

terraform init  # Téléchargement des packages API des Cloud Providers

Cette commande intialise le « working directory », en fonction des providers que vous utilisez dans vos scripts,  des backend utilisées pour stocker le fichier tfstate ( décrit plus bas).   Cette commande d’init devra être relancé en cas de modification de vos configurations ou d’utilisation de nouveaux modules provider (elle n’écrase pas vos sources).

 

terraform plan -out myPlan   # Vérifie le script, affiche les actions à réaliser et prépare le plan d'exécution

Cela vous permet de visualiser les actions qui seront réalisées,  avant de les exécuter.

 

terraform apply myPlan         # Exécute les actions : créations, modifications ou suppressions de ressources

Ces actions, comme la création de ressources, sont conservées localement dans un fichier « terraform.tfstate ».

Il permettra d’identifier les différences lors des prochaines modifications du script et de conserver certaines métadonnées des ressources Cloud créées.

Lorsque les scripts concernent un périmètre important, ce fichier tfstate améliore considérablement les performances.

La destruction de l’ensemble des ressources est réalisée par une commande « terraform destroy » (Attention aux actes irréparables).

 

Gestion au sein d’une équipe

Dès que plusieurs personnes sont susceptibles d’intervenir, nous nous heurtons au manque de partage aussi bien pour les scripts que pour le fichier tfstate généré.

 

Scripts TF

Vous rangerez vos sources des scripts TF dans votre repository git ou svn.
Attention, des précautions s’imposent pour bien gérer leur utilisation et effectuer un apply uniquement sur les scripts de la branche stable.

Il faut absolument éviter des Apply sur des ressources identiques. Vous organiserez vos scripts en « layer » ( réseau, compute, db, securité,..) pour faciliter leur modification et leur non adhérence.

Egalement, une séparation par projet / type d’environnement facilitera la gestion du delivery.

 

Fichier Tfstate

Pour le fichier tfstate, il faut le générer dans un répertoire centralisé et partagé, typiquement un service d’object storage Cloud (Aws S3, Cloud Stiorage gcp,…).

Cela peut être facilement configuré dans votre script main.tf, voici un exemple pour Aws :

Le fichier tfstate sera maintenant créé et mis à jour dans mon bucket cpa-tf-web, nommé stage/terraform.tfstate et chiffré.

Mes accès se font avec mon Aws Access Key, qui a les privilèges d’écriture dans ce bucket (IAM policy).

 

 

Liens URL pour aller plus loin

Les offres de services / software Terraform :

http://hashicorp.com/products/terraform/pricing

 

Terraform – Getting Started : indispensable pour démarrer avec terraform (script TF, commandes)

https://learn.hashicorp.com/terraform/getting-started/install.html

 

Terraform Backend : approche collaborative pour la version Terraform communautaire

https://www.terraform.io/docs/backends/config.html