Tutoriel pour découvrir Terraform, un outil qui permet de gérer son infrastructure par le code (Infrastructure as Code)

Les fichiers de configuration s'écrivent en HCL (HashiCorp Configuration Language). Le principe est d'écrire des ressources.

Les ressources peuvent être écrites en JSON également, mais il est recommandé de les écrire en HCL.

Lire un fichier de configuration HCL est plutôt simple et intuitif.

C'est un langage dit « human readable ». Ce qu'il faut savoir, c'est que Terraform scanne tous les fichiers se terminant par .tf dans le répertoire courant : il ne va pas scanner les répertoires enfants par contre.

Un fournisseur (provider) est responsable du cycle de vie/du CRUD (create, read, update, delete) d'une ressource : sa création, sa lecture, sa mise à jour et sa suppression.

Plus de 125 fournisseurs (providers) sont actuellement supportés :

• AWS, GCP, Azure, OpenStack… ;
• Heroku, OVH, 1&1… ;
• Consul, Chef, Vault… ;
• Docker, Kubernetes … ;
• GitLab, BitBucket, GitHub… ;
• MySQL, PostgreSQL… ;
• mais encore RabbitMQ, DNSimple, CloudFlare…

La liste complète des fournisseurs (providers) est disponible sur le site de Terraform : https://www.terraform.io/docs/providers/index.html.

Vous ne trouvez pas le fournisseur de vos rêves ? Pas de soucis, vous pouvez écrire votre propre plugin et participer à l'élaboration de nouvelles fonctionnalités de Terraform. Si vous ne codez pas encore en Go, ce sera l'occasion de vous y mettre ;-).

Pour configurer un fournisseur, si nous voulons par exemple déployer une infrastructure Amazon Web Services (AWS), il suffit de créer une ressource fournisseur « aws » dans un fichier se terminant par .tf :

provider "aws" {
  region = "eu-central-1"
}

Bonne pratique : ne pas mettre les informations de connexion directement dans la ressource fournisseur « aws » mais plutôt modifier vos variables d'environnement :

export AWS_ACCESS_KEY=YOUR_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY
export AWS_DEFAULT_REGION=eu-central-1

Ou bien vous pouvez les mettre dans un fichier .aws/credentials :

[default]
aws_access_key_id = YOUR_ACCESS_KEY
aws_secret_access_key = YOUR_SECRET_KEY

Attention, il va de soi que vous devrez prendre les tokens d'un utilisateur qui aura les droits/la bonne policy pour créer les services que vous voulez.

Afin de faire du code propre et qui se réutilise, il est recommandé d'initialiser des variables et de les utiliser dans les autres fichiers .tf.

Définissez vos variables dans un fichier variables.tf, par exemple :

variable "default-aws-region" {
  default = "eu-central-1"
}

variable "aws_account_id" {
  default = "123456789123"
}

variable "tags-tool" {
  default = "Terraform"
}

variable "tags-contact" {
  default = "Aurelie Vache"
}

variable "aws_s3_folder" {
  default = "s3"
}

variable "aws_s3_bucket_terraform" {
  default = "com.developpez.terraform"
}

Appelez-les dans vos ressources :

resource "aws_s3_bucket" "com-developpez-terraform" {
  bucket = "${var.aws_s3_bucket_terraform}"
  acl    = "private"

  tags {
    Tool    = "${var.tags-tool}"
    Contact = "${var.tags-contact}"
  }
}

Les modules sont utilisés pour créer des composants réutilisables, améliorer l'organisation et traiter les éléments de l'infrastructure comme une boite noire.

C'est un groupe de ressources qui prennent en entrée des paramètres et retournent en sortie des outputs.

Dans le même fichier, root.tf, dans lequel vous avez défini votre fournisseur, vous pouvez ensuite définir vos modules :

module "lambda" {
  source            = "./lambda/"
  toto              = "${var.aws_s3_bucket_toto_lambda_key}"
  titi              = "${var.aws_s3_bucket_titi_key}"
  tutu              = "${var.aws_s3_bucket_tutu_key}"
}

Les modules peuvent produire des outputs que l'on pourra utiliser dans d'autres ressources.

output "authorizer_uri" {
  value = "${aws_lambda_function.lambda_toto.invoke_arn}"
}

resource "aws_api_gateway_authorizer" "custom_authorizer" {
  name                             = "CustomAuthorizer"
  rest_api_id                      = "${aws_api_gateway_rest_api.toto_api.id}"
  authorizer_uri                   = "${module.lambda.authorizer_uri}"
  identity_validation_expression   = "Bearer .*"
  authorizer_result_ttl_in_seconds = "30"
}

Les sources de données (Data Sources) servent à récupérer une donnée/ressource existante dans votre infrastructure.

Utiliser une source de données est une bonne pratique. En effet, il est bon de privilégier son utilisation plutôt que de coder en dur des subnet_id, account_id ou autre donnée qui peut être récupérée !

# VPC
data "aws_subnet" "subnet_id_1" {
  filter {
    name = "tag:Name"
    values = ["mysubnet-for-developpez"]
 }
}

Et ensuite vous pouvez appeler cette source de données simplement dans vos fichiers .tf comme ceci :

module "developpez" {
    source = "developpez"
    subnet_id_1 = "${data.aws_subnet.subnet_id_1.id}"
}

Comme nous l'avons vu, il est possible de récupérer une source de données grâce à un système de filtre. C'est super… mais, et oui il y a un mais… malheureusement ce filtrage n'est pas possible avec tous les types de ressources.

Chez AWS il existe deux types de répartition de charge (load balancer) : classique et réseau (network). Imaginons que nous souhaitions récupérer une répartition de charge de type réseau, chez AWS, pour pouvoir créer une AWS Route 53 Record (entrée dans un nom de domaine). Nous ne pouvons appliquer un filtre sur ce type de ressources, nous allons donc devoir trouver une parade pour récupérer notre fameuse répartition de charge de type réseau.

La solution est de réaliser les actions suivantes.

1. Créer un script qui récupère la ressource.
2. Utiliser le résultat de ce script dans une source de données Terraform avec un external provider.
3. Utiliser cette donnée spéciale dans une ressource que vous voulez créer.

II-G-1. Création du script▲

#!/bin/bash
set -e
kubectl get svc mygateway -n istio-system -o json | jq .status.loadBalancer.ingress[0]

$ ./my_module/scripts/get_elb.sh
{
"hostname": "a123456789gsfgfsgfsg12134gsgsg78-123456789dfdsf45545fdsf.elb.eu-central-1.amazonaws.com"
}

II-G-2. Définition de l'external data source▲

data "external" "elb" {
     program= ["bash", "${path.module}/scripts/get_elb.sh"]
}

II-G-3. Définition de la ressource souhaitée▲

resource "aws_route53_record" "mymodule_CNAME" {
    zone_id="${data.aws_route53_zone.my_zone.zone_id}"
    name="${var.domain_name}"
    type="CNAME"
    records= ["${data.external.elb.result.hostname}"]
    ttl="${var.route53_ttl}"
}

Un état (state) est un snapshot de votre infrastructure depuis la dernière fois que vous avez exécuté la commande terraform apply.

Terraform utilise un stockage local pour créer les plans et effectuer les changements sur votre infrastructure, mais il est possible de stocker cet état dans une solution cloud.

Pour configurer le stockage de cet état de manière distante, il suffit de définir un backend.

# Backend configuration is loaded early so we can't use variables

terraform {
  backend "s3" {
    region  = "eu-central-1"
    bucket  = "com.developpez.terraform"
    key     = "state.tfstate"
    encrypt = true
  }
}

terraform init

La commande init va initialiser votre répertoire de travail qui contient vos fichiers de configuration au format .tf.

C'est la première commande à exécuter pour une nouvelle configuration, ou après avoir fait un checkout d'une configuration existante, depuis votre dépôt git par exemple.

La commande init va :

• télécharger et installer les fournisseurs (providers) ;
• initialiser le backend (si défini) ;
• télécharger et installer les modules (si définis).

terraform plan

La commande plan permet de créer un plan d'exécution. Terraform va déterminer quelles actions il doit entreprendre afin d'avoir les ressources listées dans les fichiers de configuration par rapport à ce qui est actuellement en place sur l'environnement/le fournisseur cible.

Cette commande n'effectue concrètement rien sur votre infrastructure.

Bonne pratique : afin de sauver le plan, vous pouvez spécifier un fichier de sortie.

terraform plan -out developpez.out

terraform apply developpez.out

La commande apply, comme son nom l'indique, permet d'appliquer les changements à effectuer sur l'infrastructure. C'est cette commande qui va créer nos ressources.

Attention : depuis la version 0.11 de Terraform, sorti le 16 novembre 2018, lorsque vous utilisez Terraform dans un environnement interactif, en local par exemple, mais pas en CI/CD, il est recommandé de ne plus passer par un plan d'exécution mais de directement utiliser la commande apply et de répondre Yes si vous souhaitez appliquer ce plan.

Après application de la définition de vos ressources, vous pouvez vérifier les fournisseurs (providers) utilisés par Terraform dans vos projet et modules.

$ terraform providers
.
├── provider.aws ~> 1.54.0
└── module.my_module
├── provider.aws (inherited)
└── provider.external

terraform destroy

La commande destroy permet de supprimer TOUTES les ressources.

Un plan de suppression peut être généré au préalable :

terraform plan -destroy

Grâce à la commande console, vous pouvez connaître la valeur d'une ressource Terraform. Cette commande est pratique pour faire du débogage, avant de créer un plan ou de l'appliquer.

$ echo "aws_iam_user.developpez.arn" | terraform console
arn:aws:iam::123456789123:user/developpez

terraform get

Cette commande get est utile si, par le passé, vous avez déjà fait un terraform init puis ajouté un module. Il faut préciser maintenant à Terraform qu'il faut récupérer le module ou bien le mettre à jour. Si vous ne le faites pas, lors d'un terraform plan, Terraform vous demandera de le faire.

terraform graph | dot -Tpng > graph.png`

La CLI graph permet de dessiner un graphique de dépendances visuel des ressources Terraform en fonction des fichiers de configuration.

Au bout d'un certain nombre de ressources dans un répertoire, Terraform n'arrive plus à générer ce graphique. J'espère que ce problème sera corrigé dans les futures versions.

Commençons tout d'abord par installer Terraform.

curl -O https://releases.hashicorp.com/terraform/0.11.10/terraform_0.11.10_linux_amd64.zip
sudo unzip terraform_0.11.10_linux_amd64.zip -d /usr/local/bin/
rm terraform_0.11.10_linux_amd64.zip

0.11.10 étant la dernière version de Terraform, stable, à ce jour.

Ces commandes vont extraire un binaire dans /usr/local/bin/, qui est déjà dans la variable d'environnement PATH.

Vous pouvez également installer Terraform grâce à l'outil tfenv, un Terraform version manager. La première chose à faire est de télécharger le binaire de tfenv et de le mettre dans la variable d'environnement PATH.

$ git clone https://github.com/Zordrak/tfenv.git
 ~/.tfenv
$ echo 'export PATH="$HOME/.tfenv/bin:$PATH"'
 >> $HOME/bashrc

Ensuite, vous pouvez simplement installer Terraform ou le mettre à jour en précisant la version désirée.

tfenv install 0.11.10

Afin de vérifier que Terraform est correctement installé, veuillez vérifier la version courante de l'outil.

$ terraform --version
 Terraform v0.11.10

Pour information la commande terraform -version fonctionne également.

Pour indiquer à Terraform sur quel compte AWS vous souhaitez déployer l'infrastructure souhaitée, vous devez définir des variables d'environnement AWS au préalable, par exemple dans un fichier .aws/credentials ou avec des variables d'environnement.

export AWS_ACCESS_KEY_ID="an_aws_access_key"
export AWS_SECRET_ACCESS_KEY="a_aws_secret_key"
export AWS_DEFAULT_REGION="a-region"

Si vous vous êtes déjà renseignés sur Terraform avant de consulter ce tutoriel, vous avez sans doute vu que la pratique d'organisation du code que l'on voit sur le net est que toutes les ressources Terraform sont écrites dans un fichier main.tf qui contient un peu de tout : la définition des ressources à créer, la définition du remote state, de la version du/des providers à utiliser…

Personnellement je ne recommande pas du tout cette approche. Je pense qu'il ne faut pas confondre les pratiques et les bonnes pratiques.

Faire du Terraform c'est faire de l'infrastructure as Code et donc c'est faire/écrire du code. Il s'agit donc de coder proprement. Afin que le code puisse être maintenable, s'il y a une bonne pratique à connaître, c’est qu'il vaut mieux bien organiser son code, et ce cas s'applique également pour de l'IaC et donc nos fichiers Terraform.

Au revoir l'énorme fichier main.tf contenant des torchons, des serviettes et des chaussettes (ou plutôt du GCP, Azure, AWS, Kubernetes, Vault….) et bonjour une organisation de fichier .tf qui consiste à séparer par fichier, par type de ressources, et à utiliser des modules.

Exemple :

.
├── backend.tf
├── cfg
│   ├── s3.dev.tf
│   ├── s3.prerprod.tf
│   └── s3.prod.tf
├── mymodule1
│   ├── aws_acm.tf
│   ├── aws_api_gateway.tf
│   ├── aws_cloudwatch.tf
│   ├── aws_iam.tf
│   ├── aws_kinesis.tf
│   ├── aws_lambda.tf
│   ├── aws_r53.tf
│   ├── aws_s3.tf
│   ├── data.tf
│   ├── output.tf
│   ├── resources
│   │   └── swagger.json
│   └── variables.tf
├── data.tf
├── mymodule2
│   ├── aws_els.tf
│   ├── output.tf
│   └── variables.tf
├── root.tf
├── scripts
│   ├── migrateMapping.sh
│   └── resources
│       └── myproject.json
└── variables.tf

jq est un command-line JSON processor léger. Combiné avec les output de Terraform, cela peut être très puissant.

V-B-1. Installation▲

sudo apt install jq

V-B-2. Utilisation▲

$ terraform output -json | jq '.elastic_endpoint.value'
"vpc-toto-12fgf1235f4d1235get123.eu-central-1.es.amazonaws.com"

Afin de nous faciliter la vie, il y a quelques petits outils intéressants à connaître et à utiliser. Si vous avez une infrastructure AWS existante et que vous devez la dupliquer dans plusieurs autres comptes, Terraforming (https://github.com/dtan4/terraforming) est fait pour vous. C'est un outil écrit en Ruby qui permet d'extraire des ressources AWS existantes et de générer un fichier Terraform correspondant.

Pour l'installer, voici la marche à suivre :

sudo apt install ruby
gem install terraforming

Pour extraire un type de ressources, c'est très simple. Par exemple, si l'on veut extraire des buckets s3 :

terraforming s3 > aws_s3.tf

Comme vous pouvez le constater, si vous testez cette commande sur un compte AWS qui contient des buckets s3, cette dernière n'extrait que les buckets, elle n'extrait pas les objets : les zip, jar et divers fichiers contenus dans vos buckets.

Il vous faudra du coup écrire les ressources aws_s3_object comme ceci :

resource "aws_s3_bucket_object" "authorizer_keystore" {
  bucket = "${var.aws_s3_bucket_authorizer}"
  key    = "${var.aws_s3_bucket_authorizer_keystore_key}"
  source = "${var.aws_s3_folder}/${var.aws_s3_bucket_authorizer_keystore_key}"
  etag   = "${md5(file("${var.aws_s3_folder}/${var.aws_s3_bucket_authorizer_keystore_key}"))}"

  tags {
    Tool    = "${var.tags-tool}"
    Contact = "${var.tags-contact}"
  }
}

Attention, Terraforming ne prend pas en compte toutes les ressources AWS, notamment les API Gateway. De ce fait, même si vous souhaitez dupliquer une API GW existante, il vous faudra vous les écrire à la mimine.

Plutôt que de créer vos propres modules, une autre bonne pratique est de consulter avant sur le module registry s'il n’en existe pas déjà un répondant à vos besoins.

En tant que développeur et DevOps, on aime bien avoir des petits guides qui nous résument tout ce qu'il y a à savoir sur une technologie. N'en ayant pas trouvé d'existant concernant Terraform, j'ai décidé de créer ma propre Cheat SHeet que j'ai mise sur Github afin de la partager avec tout le monde : github.com/scraly/terraform-cheat-sheet

• Support de presque tous les services AWS et d'autres (cloud) providers.
• Open source.
• Pas de rolling update pour les ASG (Auto Scaling Group).
• HCL/JSON.
• State management.
• Support de Vault.

• Support de presque tous les services AWS (uniquement ce cloud provider).
• Service géré et « offert par AWS ».
• Le rolling update d'EC2 par un ASG est supporté.
• JSON / YAML (depuis 2016).
• Pas de State management.

Il n'y a pas de meilleure technologie, chacune à ses avantages et ses inconvénients. CloudFormation couvre un peu plus de ressources AWS pour le moment que Terraform, mais ne prend pas en compte d'autres fournisseurs.

À noter qu'il est possible de charger du CloudFormation (CF) dans du Terraform, si par exemple vous avez déjà votre stack écrite en CF.

# Setup of an CloudformationStack with terraform
resource "aws_cloudformation_stack" "my_stack" {
    depends_on = [
        "aws_s3_bucket_object.lambda_code",
        "aws_s3_bucket_object.authorizer"
    ]
    name = "${var.cf_stack_name}"
    template_url = "https://${aws_s3_bucket.deployment_bucket.bucket_domain_name}/cf_logic.json"
    provider = "aws.region"
 
    parameters {
        LambdaCodeAuthorizer = "${basename(var.authorizer_lambda_jar)}",
        S3CodeBucket = "${aws_s3_bucket.deployment_bucket.id}",
        ...
    }
 
    tags {
        Tool    = "${var.tags-tool}"
          Contact = "${var.tags-contact}"
    }
}

• Permet de définir de l'Infrastructure as Code (IaC).
• Syntaxe concise et lisible.
• Réutilisation de : variables, inputs, outputs, modules.
• Commande plan.
• Multi cloud support.
• Développement très actif.

• Outil jeune (comporte des bogues).
• Pas de rollback possible.
• Assez verbeux.
• Pauvre gestion des secrets (à combiner avec Vault par exemple !).

J'ajouterai que les messages d'erreurs ne sont pas super explicites :

* module.lambda.aws_lambda_function.lambda_toto: 1 error(s) occurred:

* module.lambda.aws_lambda_function.lambda_toto: aws_lambda_function.lambda_toto: InvalidSignatureException: Signature expired: 20171218T075729Z is now earlier than 20171218T080647Z (20171218T081147Z - 5 min.)
    status code: 403, request id: 17c82bc7-e3cb-11e7-8a7e-6b18fbf66fae