🏗️ Terraform – Infrastructure as Code (IaC) & Cloud

Les 3 Composants Clés

1. 1. Terraform Core (CLI) : Le binaire (terraform) écrit en Go. Il lit les fichiers .tf, construit le graphe de dépendances, et exécute le "plan".
2. 2. Providers (Plugins) : Les "traducteurs". Ce sont des binaires (plugins) qui font le lien entre HCL (le langage) et l'API du service cible (AWS, GCP, Cloudflare, Docker...).
3. 3. State File (Fichier d'État) : Le "cerveau". Un fichier JSON (terraform.tfstate) qui stocke l'état *actuel* de l'infrastructure gérée. (Voir 2.2 & 2.3).

Schéma de flux (terraform apply)

+-----------------------+
| Fichiers .tf (HCL)    |
| (État désiré)         |
+-----------------------+
        |
        ▼
+-----------------------+
| Terraform Core (CLI)  |
| (Génère le "Plan")    |
+-----------------------+
        |           |
 (Compare)          | (Appelle)
        |           ▼
        |     +--------------+
        |     | Provider AWS | (Plugin)
        |     +--------------+
        |           |
        |           ▼ (Appels API)
        |     [Infrastructure Cloud (AWS)]
        |
        ▼
+-----------------------+
| State File (.tfstate) |
| (État actuel)         |
+-----------------------+

Le "Cerveau" de Terraform

Le fichier terraform.tfstate est un JSON généré par terraform apply. C'est la partie la plus importante (et la plus dangereuse) de Terraform.

Rôle : Il agit comme une "base de données" qui mappe votre code (resource "aws_instance" "web") à l'ID de la ressource réelle ("i-123abc456").

Quand vous lancez plan, Terraform compare .tf (désiré) à .tfstate (actuel) pour savoir quoi faire (créer, modifier, détruire).

.gitignore (CRITIQUE)

⚠️ Le .tfstate local contient des secrets (mots de passe BDD, clés API...) en CLAIR.

Il ne doit **JAMAIS** être commité (push) sur Git.

# .gitignore
*.tfstate
*.tfstate.backup
.terraform/
terraform.tfvars

Problème : Si vous le perdez, Terraform "oublie" tout ce qu'il a créé. Si vous travaillez en équipe, comment partager l'état ? (Voir 2.3).

data (Lecture de l'existant)

Problème : Votre VPC a été créé manuellement (ou par un autre projet Terraform). Comment obtenir son ID ?

Solution : Utiliser un bloc data. C'est une requête en "lecture seule" (Read-Only) à l'API du Provider.

Exemple (data)

# (On suppose que le VPC "ideo-vpc" existe déjà)
data "aws_vpc" "existing_vpc" {
  filter {
    name   = "tag:Name"
    values = ["ideo-vpc"]
  }
}

# (On suppose que l'AMI Ubuntu existe)
data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-*"
    values = ["099720109477"] # (ID du Propriétaire Canonical)
  }
}

resource "aws_instance" "web" {
  # Utiliser les données lues
  ami           = data.aws_ami.ubuntu.id
  vpc_id        = data.aws_vpc.existing_vpc.id
  ...
}

Concept (À éviter)

Les "Provisioners" (remote-exec, local-exec) sont une "porte de sortie" pour exécuter des scripts impératifs (ex: Bash) après la création d'une ressource.

⚠️ Anti-Pattern : C'est considéré comme une mauvaise pratique. Terraform est déclaratif (État). Si le script remote-exec échoue, l'état de Terraform est "contaminé" (il ne sait pas ce qui a été fait).

La "Bonne" Façon (Terraform + Ansible)

1. Terraform (main.tf) : Provisionne l'infra (EC2, SG) et génère un inventaire.

resource "aws_instance" "web" { ... }

output "inventory" {
  value = templatefile("inventory.ini.tpl", {
    ip = aws_instance.web.public_ip
  })
}
# (terraform apply -> inventory.ini)

2. Ansible (playbook.yml) : Configure le logiciel (Nginx, Gunicorn, Django) sur l'IP générée.

ansible-playbook -i inventory.ini deploy.yml

Workflow (Essentiel)

# 1. Initialiser (Télécharge les providers)
terraform init

# 2. Formater (Nettoie le code HCL)
terraform fmt

# 3. Valider (Vérifie la syntaxe)
terraform validate

# 4. Planifier (Simulation / Dry-run)
terraform plan
# (Sauver le plan)
terraform plan -out=mon_plan.tfplan

# 5. Appliquer (Créer / Mettre à jour)
terraform apply
terraform apply "mon_plan.tfplan"
# (Appliquer sans demande de confirmation)
terraform apply -auto-approve

# 6. Détruire (Tout supprimer)
terraform destroy

Gestion de l'État (.tfstate)

# Lister les ressources (selon .tfstate)
terraform state list

# Voir une ressource
terraform state show aws_instance.web_server

# (Avancé) Retirer une ressource de l'état
# (Ne détruit pas la ressource, Terraform l'oublie)
terraform state rm aws_instance.web_server

# (Avancé) Importer une ressource (créée manuellement)
# terraform import [ADRESSE_HCL] [ID_CLOUD]
terraform import aws_instance.web_server i-123abc456

# (Avancé) Déplacer une ressource
terraform state mv aws_instance.web aws_instance.old_web