Cliquer sur une console cloud convient à un serveur. Cela tombe en panne lorsque vous avez besoin de la même configuration en préparation et en production, ou lorsque quelqu’un demande qui a modifié une règle de pare-feu en mars dernier. Ce Tutoriel Terraform pour débutants vous montre une meilleure méthode : décrivez votre infrastructure dans le code et laissez un outil la concrétiser.

La plupart des didacticiels commencent par un compte cloud, ce qui ajoute un risque de facturation avant que vous ayez appris quoi que ce soit. Nous commençons par le fournisseur Terraform local, qui crée simplement des fichiers sur votre ordinateur, donc les erreurs ne coûtent rien. Ces exemples et l’exemple de sortie sont des illustrations standard que nous n’avons pas exécutées pour cet article, et la formulation exacte varie selon la version.

Qu’est-ce que Terraform ?

Terraform est un outil d’infrastructure en tant que code (IaC) de HashiCorp. Vous écrivez des fichiers de configuration en HCL, le langage de configuration HashiCorp, décrivant le résultat final souhaité. Terraform détermine ensuite ce qu’il faut créer, modifier ou supprimer pour y arriver.

Il communique avec les plateformes via des plugins appelés providers. Il existe des fournisseurs pour AWS, Azure, Google Cloud, Kubernetes, GitHub, Cloudflare et bien d’autres, vous pouvez donc utiliser un seul flux de travail pour tous.

Une chose à savoir : en 2023, HashiCorp a migré Terraform vers la Business Source License. La communauté a ensuite créé OpenTofu, un fork open source qui utilise des commandes et une configuration très similaires. Ce que vous apprenez ici s’applique en grande partie aux deux.

Pourquoi l’infrastructure en tant que code ?

Terraform est également déclaratif. Vous dites “il devrait y avoir trois serveurs”, et non “créez un serveur trois fois”. S’il en existe déjà deux, il en ajoute un. Un script qui répète simplement ses étapes pourrait finir par en créer trois autres.

Installer Terraform

Installez-le en suivant les instructions officielles de HashiCorp pour votre système d’exploitation, puis confirmez qu’il fonctionne :

terraform -version

Créez un dossier vide pour le projet. Terraform lit chaque .tf fichier du dossier actuel, donc un dossier équivaut à une configuration.

Votre première configuration

Créez un fichier nommé main.tf :

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

resource "local_file" "greeting" {
  filename = "${path.module}/hello.txt"
  content  = "Hello from Terraform\n"
}

Regardez le bloc resource, car presque tout ce que vous écrivez suit cette forme. local_file est le type de ressource et greeting est votre propre nom dans la configuration. Ensemble, ils forment son adresse : local_file.greeting. Les arguments à l’intérieur décrivent ce que vous voulez.

Le workflow : initialiser, planifier, appliquer

initialisation de la terraformation

Cela prépare le dossier et télécharge les fournisseurs que vous avez demandés. Exécutez-le une fois au début, et à nouveau chaque fois que vous ajoutez un fournisseur ou un module. Il crée également un fichier .terraform.lock.hcl qui enregistre les versions exactes du fournisseur. Validez ce fichier sur Git.

terraform init

plan de terraformation

Celui-ci compare votre code avec ce qui existe et affiche les modifications prévues, sans rien toucher :

terraform plan

# local_file.greeting will be created
+ resource "local_file" "greeting" {
    + content  = "Hello from Terraform\n"
    + filename = "./hello.txt"
  }

Plan: 1 to add, 0 to change, 0 to destroy.

Apprenez les symboles, car vous lirez beaucoup de plans :

terraformer appliquer

Celui-ci montre à nouveau le plan, demande confirmation et apporte les modifications :

terraform apply

Tapez yes et hello.txt apparaît. Maintenant, exécutez à nouveau terraform plan. Il ne devrait signaler aucun changement, car la réalité correspond déjà à votre code. Cette propriété, dont l’exécution répétée n’entraîne aucun changement supplémentaire, est appelée idempotence.

Changer et détruire

Modifiez la ligne content et exécutez terraform plan. Terraform repère la différence et propose un changement. Pour cette ressource, il remplace le fichier. Faites attention aux remplacements sur une infrastructure réelle, car recréer une base de données pourrait entraîner une perte de données.

Ensuite, supprimez hello.txt à la main et planifiez à nouveau. Terraform remarque qu’il manque et propose de le recréer. Une différence entre votre code et la réalité est appelée drift, et la détecter est l’un des principaux avantages de l’outil.

Pour supprimer tout ce que gère cette configuration, exécutez :

terraform destroy

Variables et sorties

Les valeurs codées en dur vous empêchent de réutiliser le code. Les variables d’entrée rendent une configuration flexible et les sorties renvoient des valeurs utiles :

# variables.tf
variable "environment" {
  type        = string
  description = "Deployment environment"
  default     = "dev"

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Use dev, staging or prod."
  }
}

# main.tf
resource "local_file" "config" {
  filename = "${path.module}/${var.environment}.txt"
  content  = "environment=${var.environment}\n"
}

# outputs.tf
output "config_path" {
  value = local_file.config.filename
}

Définissez les valeurs sur la ligne de commande ou conservez-les dans un fichier appelé terraform.tfvars, qui est chargé automatiquement :

terraform apply -var="environment=staging"

L’utilisation de local_file.config.filename dans la sortie indique également la façon dont les ressources se réfèrent les unes aux autres. Terraform lit ces références pour déterminer le bon ordre dans lequel créer les éléments.

État de Terraform

Après avoir postulé, vous trouverez un fichier appelé terraform.tfstate. Il s’agit de l’enregistrement de Terraform de ce qu’il gère, en mappant votre code à des objets réels. Sans cela, Terraform ne saurait pas que local_file.greeting est ce fichier spécifique.

Trois règles comptent ici :

1. Ne jamais valider l’état dans Git. Il peut contenir des mots de passe et d’autres secrets en texte brut.
2. Ne le modifiez pas à la main. Utilisez des commandes telles que terraform state list et terraform state mv.
3. Utilisez un backend distant pour les projets d’équipe. Un backend partagé stocke l’état de manière centralisée et le verrouille, de sorte que deux personnes ne peuvent pas postuler en même temps.

Voici un backend typique utilisant Amazon S3, avec un bucket que vous créez à l’avance :

terraform {
  backend "s3" {
    bucket       = "my-company-terraform-state"
    key          = "shop/prod/terraform.tfstate"
    region       = "ap-south-1"
    encrypt      = true
    use_lockfile = true
  }
}

Une véritable ressource cloud

Le flux de travail ne change pas lorsque vous passez à un cloud. Voici un bucket S3 sur AWS. Vérifiez d’abord les prix et détruisez tout ce que vous créez en vous entraînant :

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "reports" {
  bucket = "my-unique-reports-bucket-2026"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

Terraform obtient les informations d’identification de votre configuration AWS CLI ou de vos variables d’environnement. N’écrivez jamais de clés d’accès dans un fichier .tf.

Modules

Un module est simplement un dossier de fichiers Terraform que vous pouvez appeler avec différentes entrées. Cela fonctionne un peu comme une fonction, vous permettant de définir un modèle une fois et de le réutiliser :

project/
  main.tf
  modules/
    reports_bucket/
      main.tf
      variables.tf
      outputs.tf

module "staging_reports" {
  source      = "./modules/reports_bucket"
  environment = "staging"
}

module "prod_reports" {
  source      = "./modules/reports_bucket"
  environment = "prod"
}

Le registre public Terraform propose également des modules prêts à l’emploi, mais lisez-les avant de vous y fier et épinglez la version. Ne construisez pas de modules trop tôt. Attendez d’avoir répété un motif au moins deux fois.

Un flux de travail d’équipe sécurisé

1. Créez une branche et modifiez les fichiers .tf. Consultez notre Tutoriel Git pour débutants si vous avez besoin d’un rappel.
2. Exécutez terraform fmt et terraform validate.
3. Ouvrez une pull request, avec le résultat de terraform plan joint pour examen.
4. Après approbation, appliquez ce plan enregistré à partir d’un endroit contrôlé, idéalement un pipeline.

Enregistrer le plan garantit que vous appliquez exactement ce qui a été examiné :

terraform plan -out=tfplan
terraform apply tfplan

Cela s’intègre naturellement dans CI/CD et GitHub Actions. Terraform provisionne généralement le cluster et des outils comme Kubernetes exécutent ensuite des applications par-dessus.

Erreurs courantes

• Postuler sans lire le plan. Un -/+ sur une base de données peut être une surprise très coûteuse.
• Conserver l’état sur un ordinateur portable. Perdez cet ordinateur portable et Terraform perd la trace de votre infrastructure.
• Effectuer des modifications manuelles sur la console. Elles provoquent une dérive et la prochaine application peut les annuler.
• Utilisation de versions non épinglées. Épinglez les versions du fournisseur et du module afin que les mises à niveau aient lieu volontairement.
• Utiliser une énorme configuration. Le fractionnement par environnement ou système limite les dégâts de toute erreur.

Pour conclure

Vous avez maintenant vu les idées derrière presque tous les travaux de Terraform : déclarer les ressources, revoir le plan, l’appliquer et protéger l’État. Entraînez-vous avec le fournisseur local jusqu’à ce que le flux de travail semble naturel, puis gérez une petite ressource réelle dans un compte gratuit. Apportez l’état et les modules distants une fois que plusieurs personnes ou plusieurs environnements sont impliqués.

Questions fréquentes

Continuez à apprendre