Terraform Infrastructure as Code

Mise à jour : 07/10/2024

Terraform, développé par HashiCorp et lancé en 2014, a révolutionné le concept d’Infrastructure as Code (IAC). Son émergence a été motivée par la complexité croissante des architectures informatiques et la nécessité d’une gestion plus agile et efficace des ressources dans le cloud.

Avant Terraform, la gestion de l’infrastructure était souvent fragmentée et dépendante de multiples outils spécifiques à chaque fournisseur de cloud ou à chaque technologie. Cette approche cloisonnée générait des défis significatifs en termes de portabilité et d’efficacité opérationnelle. Les administrateurs systèmes faisaient face à des processus manuels sujets aux erreurs, entraînant des déploiements lents et des inconsistances.

La documentation présentée ici est également applicable à OpenTofu, un fork open source de Terraform. Ce fork a été créé en réponse au changement de licence de Terraform par HashiCorp en 2023, qui est passé de la licence open-source Mozilla Public License (MPL 2.0) à la Business Source License (BSL). Ce changement a été perçu par une partie de la communauté comme une restriction de la liberté d’utilisation, ce qui a conduit à la création d’OpenTofu pour garantir une continuité dans l’utilisation de Terraform sous une licence open-source. Par conséquent, les concepts, les commandes et les pratiques documentés ici s’appliquent également à OpenTofu.

Pour les commandes, il suffit de remplacer terraform par tofu :

tofu apply

Terraform qu’est-ce que c’est ?

Mitchell Hashimoto et Armon Dadgar, les fondateurs de HashiCorp, ont perçu ces défis comme une opportunité pour créer un outil unifié qui simplifierait la gestion de l’infrastructure. Terraform a été conçu pour permettre aux utilisateurs de définir et de provisionner l’infrastructure à l’aide d’un langage de configuration simple et déclaratif. Cette approche visait à rendre les configurations reproductibles et à faciliter la gestion de versions, un élément indispensable.

L’Évolution de Terraform

L’histoire de Terraform est une histoire de croissance, d’adaptation et d’innovation constantes depuis sa première introduction par HashiCorp en 2014. Dans ce chapitre, nous explorerons en détail l’évolution de Terraform, en mettant en lumière les principales étapes de son développement.

Versions et Mises à Jour Majeures

Terraform a connu de nombreuses versions au fil des ans, chacune introduisant de nouvelles fonctionnalités et améliorations significatives. Parmi les versions les plus notables :

Terraform 0.6 : Cette version a introduit le support des modules, permettant aux utilisateurs de réutiliser et de partager des morceaux de code d’infrastructure. Cela a favorisé la création d’une bibliothèque de modules Terraform, facilitant la mise en place de bonnes pratiques et la réduction de la duplication de code.
Terraform 0.12 : L’une des mises à jour les plus importantes, Terraform 0.12 a amélioré la syntaxe HCL (HashiCorp Configuration Language) et a introduit des fonctionnalités telles que les boucles, les conditions et les expressions plus puissantes. Cela a rendu les fichiers de configuration Terraform plus lisibles et plus flexibles.
Terraform 0.13 : Cette version a amélioré la gestion des modules et a introduit le concept de “providers” pour une meilleure extensibilité. Elle a également contribué à rendre Terraform plus efficace et plus évolutif.
Terraform 1.0 : Cette version 1.0 de Terraform a marqué une étape importante dans l’histoire de cet outil d’infrastructure en tant que code (IaC). Elle a été annoncée par HashiCorp en juin 2021 et a apporté une stabilité et une maturité significatives à Terraform.
Terraform 1.6 : En 2023, Terraform a changé sa licence de l’open-source Mozilla Public License (MPL 2.0) à la Business Source License (BSL). Ce changement a été initié pour mieux protéger la propriété intellectuelle d’HashiCorp tout en maintenant l’accès gratuit à l’utilisation et aux modifications du logiciel pour la majorité des cas d’utilisation. Toutefois, cela impose des restrictions sur l’utilisation commerciale du produit.

La Contribution de la Communauté

L’une des forces de Terraform réside dans sa communauté open source dynamique. Des milliers de contributeurs du monde entier ont participé à son développement en créant des modules, en signalant des problèmes, en proposant des améliorations et en partageant leurs connaissances. La communauté a joué un rôle essentiel dans l’expansion de l’écosystème Terraform, en ajoutant de nouveaux fournisseurs de cloud, en créant des modules réutilisables et en aidant les nouveaux utilisateurs à maîtriser l’outil.

HCL le langage de Terraform

Dans le cas de Terraform, le langage utilisé pour définir l’infrastructure est connu sous le nom de HashiCorp Configuration Langage (HCL).

L’objectif principal de Terraform est de déclarer des ressources, qui représentent des objets d’infrastructure. Toutes les autres fonctionnalités de son langage permettent de rendre la définition des ressources plus flexible et pratique.

Les concepts importants

Le registre Terraform ou registry

La Terraform Registry ↗ est une plateforme en ligne qui permet de partager, découvrir et utiliser des providers et des modules Terraform créés par la communauté ou par des entreprises. Les fournisseurs étendent les capacités de Terraform en ajoutant des ressources spécifiques à des plateformes comme AWS, Azure, Google Cloud, Outscale ou d’autres services. Les modules, quant à eux, regroupent du code Terraform réutilisable pour des configurations d’infrastructure spécifiques, facilitant la gestion et le déploiement de l’infrastructure à grande échelle.

C’est une ressource puissante pour les équipes souhaitant adopter l’infrastructure as code (IaC) tout en accélérant leur développement grâce à des ressources prêtes à l’emploi.

Les providers Terraform

Les providers dans Terraform sont des plugins qui permettent à Terraform d’interagir avec diverses plateformes d’infrastructure, services cloud et API. Ils sont essentiels, car ils traduisent les commandes et configurations Terraform en actions sur les infrastructures physiques ou virtuelles, comme la création d’une machine virtuelle ou la gestion de bases de données.

Chaque provider est associé à une plateforme spécifique, telle que AWS, Azure, GCP, ou Outscale et expose des ressources et data sources que vous pouvez gérer via Terraform. Par exemple, le provider Outscale vous permet de créer et de gérer des ressources sur le cloud Outscale.

Exemples de providers courants :

AWS : Gère les ressources AWS comme EC2, S3, etc.
Google Cloud : Gère les ressources GCP comme Compute Engine et Cloud Storage.
AzureRM : Gère les ressources Azure.
Outscale : Gère les ressources dans le cloud Outscale, comme les machines virtuelles et les réseaux.

Exemple d’utilisation d’un provider :

Dans un fichier de configuration Terraform, vous devez d’abord spécifier le provider que vous utilisez avant de définir les ressources à gérer :

terraform {
  required_providers {
    outscale = {
      source  = "outscale/outscale"
      version = "0.12.0"
    }
  }
}

provider "outscale" {
  access_key = "your_access_key"
  secret_key = "your_secret_key"
  region     = "eu-west-2"
}

Dans cet exemple, le provider Outscale est configuré pour interagir avec les API du cloud Outscale, permettant ainsi de gérer les ressources dans cette infrastructure. Les providers sont le lien entre Terraform et les services sous-jacents, rendant possible l’automatisation des tâches d’infrastructure à travers différents environnements cloud.

Les ressources Terraform

Les ressources dans Terraform sont des composants spécifiques de votre infrastructure, tels que des machines virtuelles, des réseaux, ou des bases de données. Chaque ressource possède un bloc de configuration qui définit les attributs nécessaires à sa création. Voici quelques exemples courants de ressources dans Terraform :

outscale_vm : Pour créer une machine virtuelle sur Outscale.
aws_instance : Pour créer une machine virtuelle (VM) sur AWS.
azurerm_virtual_network : Pour gérer les réseaux virtuels dans Azure.
google_compute_instance : Pour créer une instance de calcul sur Google Cloud.

Voici un exemple de configuration pour créer une machine virtuelle (VM) sur Outscale avec Terraform :

resource "outscale_vm" "example_vm" {
  image_id        = "ami-12345678"
  vm_type         = "tinav5.c1r1p2"
  keypair_name    = "my-keypair"
  subnet_id       = "subnet-12345678"
  state           = "running"
  security_group_ids = ["sg-12345678"]
}

Dans cet exemple, la ressource outscale_vm permet de créer une VM avec des attributs comme l’identifiant de l’image, le type de machine, la clé SSH, et l’ID du sous-réseau où sera déployée la VM.

Les data sources Terraform

Les data sources dans Terraform permettent d’accéder à des informations externes ou à des ressources existantes sans les créer ni les modifier. Elles sont utilisées pour récupérer des données sur des éléments déjà présents dans une infrastructure, comme des machines virtuelles, des images, ou des réseaux, et les utiliser dans une configuration Terraform.

Une data source est une façon d’extraire des informations d’un environnement cloud ou d’un système tiers. Contrairement aux ressources, qui créent des éléments dans l’infrastructure, les data sources se contentent de récupérer des données que vous pouvez utiliser dans d’autres configurations Terraform.

Les data sources sont utiles pour plusieurs raisons :

Récupérer des informations dynamiques ou existantes (par exemple, une image AMI spécifique).
Réutiliser des ressources qui ont été créées manuellement ou par d’autres outils.
Faciliter la configuration et la gestion des dépendances dans une infrastructure complexe.

Prenons un exemple avec une data source qui récupère une image existante (AMI) sur Outscale :

data "outscale_images" "my_image" {
  filter {
    name   = "image_name"
    values = ["ubuntu_2204"]
  }
}

resource "outscale_vm" "example_vm" {
  image_id        = data.outscale_images.my_image.images[0].image_id
  vm_type         = "tinav5.c1r1p2"
  keypair_name    = "my-keypair"
  subnet_id       = "subnet-12345678"
}

Dans cet exemple :

La data source outscale_images récupère une image Ubuntu 22.04 existante.
La ressource outscale_vm utilise l’ID de cette image pour créer une machine virtuelle basée sur cette AMI sans avoir besoin de spécifier manuellement son ID.

Le state de Terraform

La gestion de l’état est un aspect important du workflow de Terraform. L’état de l’infrastructure est stocké dans un fichier d’état, généralement stocké localement ou de manière centralisée via un backend distant. Il est important de gérer cet état avec soin pour assurer la cohérence de l’infrastructure et éviter les conflits.

Par défaut cet état est stocké dans un fichier local nommé terraform.tfstate, mais il peut également être stocké à distance, mais pas dans votre repository git, car il peut contenir des secrets.

Terraform utilise cet état pour créer des plans et apporter des modifications à votre infrastructure. Avant toute opération, Terraform effectue un rafraîchissement pour mettre à jour l’état avec celle de l’infrastructure réelle.

Le workflow de Terraform

Worflow Terraform

Le workflow de Terraform reposent sur cinq étapes clés : Write, Init, Plan, Apply et Destroy et sur l’enregistrement du state:

Write: Vous commencez à écrire votre configuration.
Init: Vous initialisez votre configuration pour installer les dépendances nécessaires.
Plan: Vous auditez les changements et validez simplement si vous les acceptez.
Apply: Vous appliquez les changements à l’infrastructure réelle.
Destroy: Vous décommissionnez toute votre infrastructure.

Ensuite, vous modifiez votre code, vous rebouclez par plan, apply et ainsi de suite. La phase de destroy n’intervenant que lorsque vous n’avez plus besoin de ces ressources.

Installer et configurer Terraform

Terraform est un outil polyvalent qui peut être installé sur différentes plateformes, notamment Linux, macOS et Windows. Dans cette section, nous allons examiner comment installer Terraform en utilisant les dépôts officiels d’HashiCorp pour chaque plateforme.

Pour Linux

Pour les distributions Linux, HashiCorp fournit un dépôt officiel permettant d’installer Terraform avec des gestionnaires de paquets tels que apt (pour Ubuntu/Debian) et dnf (pour CentOS/RHEL).

Pour Ubuntu/Debian

sudo apt update && sudo apt install -y gnupg software-properties-common curl
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

Pour RHEL family: Centos, Oracle Linux, Alma Linux, Rocky Linux

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform

Pour MacOs

Pour macOS, vous pouvez utiliser le gestionnaire de paquets Homebrew pour installer Terraform. Assurez-vous que vous avez Homebrew installé. Si ce n’est pas le cas, installez-le depuis https://brew.sh ↗.

Dans une fenêtre Terminal :

brew install terraform

Pour Windows

Sur Windows, vous pouvez utiliser le gestionnaire de paquets Chocolatey pour installer Terraform. Assurez-vous que vous avez Chocolatey installé. Si ce n’est pas le cas, installez-le depuis https://chocolatey.org ↗.

Ouvrez une invite de commandes ou PowerShell en tant qu’administrateur.

choco install terraform

Après avoir suivi ces étapes d’installation, vous pouvez vérifier que Terraform est correctement installé en exécutant la commande terraform version. Elle affichera la version de Terraform installée sur votre système.

La CLI terraform

La CLI de Terraform possède les commandes suivantes :

init : La commande init va initialiser le répertoire de travail et vérifier que les plugins utilisés sont correctement installés.
plan : La commande plan permet de créer un plan d’exécution. Terraform va indiquer quelles actions il doit effectuer pour arriver au résultat décrit dans le fichier de configuration.
apply : L’infrastructure voulue est mise en place.
console : Cette commande permet de faire du débogage, avant de créer un plan ou de l’appliquer.
destroy : L’infrastructure est détruite

Structure d’un projet Terraform

Pour un projet très simple, vous pouvez regrouper tout dans un seul fichier main.tf. Cependant, je vous conseille d’adopter une structure pour vous y retrouver facilement dans tous vos projets, voici la structure que j’ai adoptée :

Répertoireproject_directory
- README.md
- main.tf
- variables.tf
- outputs.tf
- resources.tf
- provider.tf
- terraform.tfvars
- Répertoiremodules:
  - Répertoiremodule1:
    README.md
    variables.tf
    main.tf
    outputs.tf

Le fichier main.tf qui est le fichier principal d’un projet terraform
Le fichier provider.tf pour y définir les fournisseurs
Le fichier variables.tf pour les variables principales
Le fichier terraform.tfvars pour les variables secrètes qui ne sera pas stocké dans votre repository git
Le fichier de variables *.auto.tfvars variables qui sont lues automatiquement
Le fichier outputs.tf pour y définir tout ce qui sera affiché
Les fichiers resources.tf pour un petit projet un simple fichier resources.tf suffira pour de plus prend vous pouvez en créer plusieurs avec des noms explicites.
Les modules
Le fichier .gitignore dont voici le contenu :

# Local .terraform directories
**/.terraform/*

# .tfstate files
*.tfstate
*.tfstate.*

# Crash log files
crash.log

# Exclude all .tfvars files, which are likely to contain sentitive data, such as
# password, private keys, and other secrets. These should not be part of version
# control as they are data points which are potentially sensitive and subject
# to change depending on the environment.
#
*.tfvars

# Ignore override files as they are usually used to override resources locally and so
# are not checked in
override.tf
override.tf.json
*_override.tf
*_override.tf.json

# Include override files you do wish to add to version control using negated pattern
#
# !example_override.tf

# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
# example: *tfplan*

# Ignore CLI configuration files
.terraformrc
terraform.rc

L’ordre des blocs et des fichiers dans lesquels ils sont organisés ne sont généralement pas significatifs ; En effet Terraform utilise les relations implicites et explicites entre les ressources pour déterminer dans quel ordre les opérations vont s’exécuter.

Quelques bonnes pratiques

Voici quelques bonnes pratiques essentielles à suivre avec Terraform pour garantir une gestion efficace de votre infrastructure :

Verrouillage des versions des providers

Il est essentiel de spécifier les versions des providers dans ton fichier de configuration pour garantir que ton infrastructure reste stable, même si des mises à jour sont publiées. Cela permet de maîtriser les changements et d’éviter les incompatibilités inattendues. Avant de l’appliquer sur la production teste ces nouvelles versions sur un autre environnement.

Organiser le code par environnement

Il est important de séparer les environnements (développement, test, production) pour éviter les erreurs et garantir une isolation correcte des états Terraform. L’utilisation de workspaces est une excellente approche pour cela.

Modularité du code

Adopter une structure modulaire permet de réutiliser et d’organiser efficacement ton code Terraform. Cela aide à éviter la duplication de code et à simplifier la maintenance. Chaque composant de ton infrastructure, comme les réseaux ou les instances, devrait être encapsulé dans des modules réutilisables.

Gestion centralisée de l’état

Stocker l’état Terraform de manière centralisée (par exemple, dans Terraform Cloud ou dans un backend distant comme Outscale S3) garantit que tous les membres de l’équipe accèdent à un état unique et à jour. Cela est particulièrement utile pour éviter les conflits et les erreurs lors des modifications simultanées.

Protéger les secrets

Lorsque tu gères des infrastructures avec Terraform, il est essentiel de sécuriser les informations sensibles comme les clés API, les identifiants de base de données ou les mots de passe. Pour cela, il est recommandé d’utiliser un outil comme HashiCorp Vault. Cet outil permet de stocker et de gérer les secrets de manière sécurisée et d’y accéder de manière contrôlée depuis tes configurations Terraform.

Voici les bonnes pratiques à suivre pour protéger tes secrets :

Ne stocke jamais de secrets en clair dans ton code ou dans le fichier terraform.tfvars. Utilise des variables marquées comme sensibles.
Intègre HashiCorp Vault pour stocker et récupérer dynamiquement des secrets pendant le provisioning de ton infrastructure. Vault permet de sécuriser les accès et de gérer les rotations automatiques des secrets.
Évite d’ajouter les fichiers contenant des secrets dans ton dépôt Git. Utilise un fichier .gitignore pour exclure les fichiers sensibles.

Pour en savoir plus sur la protection des secrets avec HashiCorp Vault, consulte cet article ici.

En appliquant ces pratiques, tu sécurises ton infrastructure et garantis que les informations sensibles sont protégées à chaque étape du déploiement. Nous reverrons tous ces points dans les chapitres suivants.

La suite

Vous pouvez poursuivre la lecture sur les billets suivants :

Plus d’infos

Site Officiel : terraform.io ↗
Documentation : terraform.io/docs ↗