À la découverte de Terraform

Pour faire simple je vous suggère de suivre les tutoriels Get Started officiels de Hashicorp (qui produit Terraform) : j’ai suivi celui pour AWS et ça aide à prendre l’outil en main et assimiler les commandes de base.

On y voit ainsi la syntaxe des fichiers .tf (qui contiennent la configuration de notre infra) et .tfvars (qui permettent d’injecter des variables via un fichier, en remplacement ou complément des variables d’environnement), les commandes terraform init pour installer les dépendances, terraform plan pour générer un plan d’exécution avant d’appliquer nos modifications et terraform apply pour déployer une nouvelle version de l’infra.

Les tutoriels sont très bien faits et vous permettront de voir les bases de Terraform appliquées à votre fournisseur préféré.

Pour commencer on peut tout mettre dans un même dossier, qui servira de racine à notre projet Terraform. On verra dans un prochain article comment organiser un projet plus complexe avec des modules.

Les fichiers .tf seront chargés automatiquement, peu importe leur nom : les noms utilisés dans cet article ne sont qu’une convention ou des suggestions. Libre à vous d’en utiliser d’autres si besoin, tant que vous vous y retrouvez.

Les fichiers .tfvars ne sont pas lus automatiquement, c’est à vous de les inclure lors de certaines commandes (plan ou apply par exemple).

Les fichiers .tfstate sont générés par Terraform automatiquement : évitez d’y toucher, c’est un risque à perdre des données importantes.

Avant toute chose, dans un projet tout neuf, on indique à Terraform quel fournisseur utiliser :

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.27"
    }
  }
  required_version = ">= 1.0"
}

provider "aws" {
  profile = var.aws_profile
  region  = var.aws_region

  default_tags {
    tags = {
      Project     = var.project_name
      Environment = var.environment
    }
  }
}

Il s’agit ici d’indiquer à Terraform que l’on souhaite utiliser la version 1.0 ou plus de l’outil, avec le provider aws (version 3.27 ou version mineure supérieure).

En lançant terraform init il sera alors installé et prêt à l’usage.

On définit ensuite des informations pour initialiser le provider : le profil AWS (défini dans la configuration de l’outil en ligne de commande d’AWS) à utiliser, la région dans laquelle on veut travailler par défaut… et quelques étiquettes (tags) à appliquer par défaut aux ressources.

Les plus attentifs ont pu remarquer la syntaxe var.xxxx pour faire appel à une variable.

Définition

On commence donc par les définir :

variable "project_name" {
  description = "Nom du projet"
  type        = string
  default     = "tutoriel"

  validation {
    condition     = length(var.project_name) <= 12 && length(regexall("[^a-zA-Z0-9-]", var.project_name)) == 0
    error_message = "La variable 'project_name' doit faire moins de 12 caractères, et contenir uniquement des lettres, chiffres et tirets."
  }
}

variable "environment" {
  description = "Nom de l'environment actuel"
  type        = string
  default     = "test"

  validation {
    condition     = length(var.environment) <= 12 && length(regexall("[^a-zA-Z0-9-]", var.environment)) == 0
    error_message = "La variable 'environment' doit faire moins de 12 caractères, et contenir uniquement des lettres, chiffres et tirets."
  }
}

variable "aws_region" {
  description = "Région AWS du déploiement"
  type        = string
  default     = "eu-west-3" # eu-west-3 pour Paris
}

variable "aws_profile" {
  description = "Nom du compte AWS CLI (~/.aws/credentials)"
  type        = string
  default     = "default" # Pensez à renseigner le nom de votre compte pour la CLI AWS
}

Les blocs variable permettent donc d’indiquer que l’on souhaite définir une nouvelle variable dont le nom est dans les guillemets qui suivent, avec une description, un type et une éventuelle valeur par défaut (default).

On peut également y inclure un bloc validation pour vérifier le format de la variable en question, par exemple sa longueur, les caractères contenus, ou une sous-chaîne… On indique alors une condition ainsi qu’un message d’erreur (error_message). Plus d’infos sur la validation de variables.

Injection

On peut alors créer un fichier test.tfvars pour y définir les valeurs correspondantes spécifiques à cet environnement :

project_name = "tutoaws"
environment  = "tests"

aws_region     = "eu-west-3" # Pas obligé de re-définir si on veut garder la valeur par défaut
aws_profile    = "mon-compte-aws"
aws_account_id = 1234567890

Pour utiliser ce fichier pensez à l’indiquer à Terraform : terraform plan -var-file="./test.tfvars" ou terraform apply -var-file="./test.tfvars".

Un peu sur le même principe, le mot-clé local permet de calculer une valeur et de l’utiliser comme une variable.

On peut par exemple calculer un préfixe pour les noms des ressources :

locals {
  prefix = "${var.project_name}-${var.environment}"
}

On peut alors l’utiliser directement, par exemple en important une paire de clés de chiffrement :

resource "aws_key_pair" "main" {
  key_name   = local.prefix
  public_key = var.ssh_public_key
}

Il faut donc s’assurer d’avoir une clé tutoaws-tests sur le compte AWS et d’avoir extrait la partie publique (qui commence par ssh-rsa ) pour la mettre dans une nouvelle variable :

variable "ssh_public_key" {
  description = "Clé publique pour la connexion SSH aux instances EC2 (normalement installé dans ~/.ssh/tutoaws-tests.pem)"
  default     = ""

  validation {
    condition     = length(var.ssh_public_key) >= 380 && substr(var.ssh_public_key, 0, 8) == "ssh-rsa "
    error_message = "La variable 'ssh_public_key' dit faire au moins 380 caractères et commencer par 'ssh-rsa '."
  }
}

Si la clé SSH en question a déjà été créée par AWS, vous pouvez demander à Terraform de l’importer pour éviter qu’il ne tente d’en créer une nouvelle qui pourrait rentrer en conflit :

terraform import -var-file="./test.tfvars" aws_key_pair.main tutoaws-tests

Ici aws_key_pair.main correspond à la ressource Terraform à importer, et tutoaws-tests au nom de la clé sur la console AWS. Terraform saura maintenant que la clé existe déjà, vous évitant ainsi des erreurs à l’application de la configuration.

Jusqu’ici rien de bien difficile, on a créé une simple clé de chiffrement. Et si on voulait créer plusieurs ressources… avec des dépendances entre elles ?

Eh bien on peut faire référence à un attribut d’une ressource comme on utiliserait une variable !

Prenons le cas d’une instance EC2 (un genre de VPS) qui doit faire partie d’un groupe de sécurité :

resource "aws_security_group" "default" {
  name        = "${local.prefix}-default"
  description = "Groupe de sécurité par défaut"

  egress { # On autorise toutes les connexions sortantes
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }
  ingress { # On autorise les connexions SSH entrantes
    description = "SSH"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] # Vous pouvez indiquer votre IP ici pour restreindre l'accès
  }
}

resource "aws_instance" "test" {
  instance_type   = "t2.micro"
  ami             = var.ec2_instance_ami
  
  security_groups = [aws_security_group.default.id] # Sera déterminé une fois le groupe en question créé
  
  key_name = aws_key_pair.main.key_name # On autorise notre clé SSH
  
  tags = {
    Name = "${local.prefix}-instance"
  }
}

En n’oubliant pas de définir notre variable :

variable "ec2_instance_ami" {
  description = "Identifiant de l'image AMI des instances MongoDB"
  type        = string
  default     = "ami-01f14919ba412de34"
  # NOTE: on peut ajouter une validation ici… 😉
}

Une fois votre configuration appliquée, il peut être intéressant de récupérer des valeurs, notamment celles qui sont générées, pour pouvoir retrouver facilement certaines informations.

On peut alors utiliser un bloc output :

output "environment" {
  description = "Nom de l'environnement actif"
  value       = var.environment
}

output "ssh_key_arn" {
  description = "ARN de la clé SSH"
  value       = ssh_public_key.arn
}

output "security_group_arn" {
  description = "Identifiant du groupe de sécurité"
  value       = aws_security_group.default.arn
}

terraform apply -var-file="./test.tfvars"

Et voilà, vous êtes prêts à pratiquer l'infra-as-code ou IaC !

Enfin… vous êtes pas obligés non plus, mais ça peut être pratique de supprimer toutes ses ressources si c’était juste pour tester, histoire de ne pas payer pour rien :

terraform destroy -var-file="./test.tfvars"