07

🏗️ Infrastructure as Code

Terraform, Ansible & Automation

"Créer un serveur manuellement, c'est de l'artisanat local et fragile. L'écrire sous forme de code, c'est de l'ingénierie reproductible. L'IaC permet de cloner un datacenter entier en une ligne de commande."

📐 Analogie : L'Architecte vs Le Maçon

ClickOps (Manuel) : Vous dites au maçon "Pose une brique ici, puis une autre là". Si le mur tombe, il faut tout redire.
IaC (Terraform) : Vous donnez le plan 3D (Code) au robot. Il construit tout seul. Si le mur tombe, il le reconstruit à l'identique.

⚠️ Rappel : Idempotence et State

L'idempotence garantit que l'exécution d'un script 100 fois aboutira exactement au même résultat final (sans créer 100 copies du serveur). L'IaC y parvient grâce à son fichier d'état (State, ex: terraform.tfstate) qui mémorise la réalité de l'infrastructure, servant de point de vérité absolu pour calculer le Delta des modifications.

📖 IaC : Des "Pets" aux "Cattle"

Le plus grand changement apporté par l'IaC est le changement de paradigme "Pets vs Cattle" (Animaux de compagnie vs Bétail) :

  • Pets (Hier) : On donne un nom à nos serveurs (ex: "Zeus"). On les soigne manuellement. S'ils meurent, c'est la tragédie.
  • Cattle (Aujourd'hui) : Les serveurs n'ont plus de noms individuels, mais des numéros (ex: web-01, web-02). S'ils ont un problème, on les supprime et on les recrée via le code.

L'Infrastructure as Code permet une Reproductibilité Totale et évite le "Snowflake Server" (serveur configuré à la main que personne n'ose toucher).

💡 Le saviez-vous ? L'essor de Terraform

En 2014, Mitchell Hashimoto (fondateur de HashiCorp) lance Terraform. Avant, chaque Cloud Provider avait son propre outil (CloudFormation pour AWS, ARM pour Azure). Terraform a réussi l'impossible : créer un langage Cloud Agnostic (HCL) qui peut parler à tous les Clouds via des "Providers".

C'est aujourd'hui l'outil d'IaC le plus utilisé au monde.

🔄 A. Cycle de vie IaC

📝
Write
.tf / .yaml
→
🔍
Plan
Dry-run
→
🚀
Apply
Create/Update
→
💥
Destroy
Cleanup
Git Repo .tf files playbooks.yml Terraform Provision Infra Ansible Config OS/Apps Cloud (AWS/GCP) VM1 VM2 RDS DB API Calls SSH

Schéma interactif : Terraform construit l'infrastructure (serveurs, réseaux) via API, puis Ansible la configure (logiciels) via SSH.

🛠️ B. Outils IaC

📊 Provisioning vs Configuration

🏗️ Terraform (Déclaratif)

  • Provisioning : Créer des ressources (VPC, VM, DB).
  • State Management : Sait ce qu'il a créé (le fichier State).
  • Idempotent : Ne recrée pas si la ressource existe déjà.
  • Cycle de vie : Idéal pour "Infrastructure immutable".

🛠️ Ansible (Impératif/Hybride)

  • Configuration : Installer des logiciels, modifier des fichiers.
  • Stateless : Ne garde pas d'inventaire de l'état passé.
  • Agentless : Fonctionne via SSH (pas d'agent à installer).
  • Mutable : Idéal pour maintenir des serveurs existants.

📊 Cas d'étude : Capital One - L'IaC à l'échelle bancaire

100% Infra dans le Cloud AWS
Thousands Nodes gérés par Terraform
0 Accès manuel en prod

Contexte : En 2015, Capital One décide de fermer tous ses datacenters pour migrer sur AWS. Le défi : garantir la sécurité et la conformité bancaire de manière automatisée.

Transformation :

  1. Terraform First : Interdiction de créer une ressource via la console. Tout passe par une PR Git.
  2. Policy as Code : Utilisation de Sentinel (HashiCorp) pour bloquer automatiquement les infras non-conformes (ex: Bucket S3 public).
  3. Immutable Infrastructure : On ne patche jamais un serveur, on redéploie une nouvelle version de l'infra complète.

Résultat : Réduction drastique des erreurs humaines et audit constant en temps réel.

🔄 À Retenir - Infrastructure as Code

  • Versionnez tout : L'infra est du code, elle vit dans Git.
  • Évitez le Drift : Utilisez des outils comme Driftctl pour détecter les modifs manuelles.
  • Modularité : Ne répétez pas votre code (DRY - Don't Repeat Yourself). Utilisez des modules.
  • Sécurité : Scannez vos manifests IaC avec des outils comme Checkov ou Tfsec.
main.tf (Terraform)
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = { Name = "prod-vpc" }
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
  vpc_security_group_ids = [
    aws_security_group.web.id
  ]
}
playbook.yml (Ansible)
- name: Configure Web Server
  hosts: webservers
  become: yes
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present
    - name: Start Nginx
      service:
        name: nginx
        state: started
        enabled: yes

🧱 C. Advanced Terraform Patterns

📦 Modules (Reusability)
Au lieu de copier-coller 50 fois le code d'un VPC, créez un module.
module "vpc_prod" { source = "./modules/vpc" }
DRY (Don't Repeat Yourself) est roi.
🗂️ Workspaces (Environments)
Gérer Dev, Staging et Prod avec le même code.
terraform workspace select prod
Chaque workspace a son propre fichier d'état (tfstate) isolé.

🔒 D. Remote State & Locking

En équipe, stocker le fichier terraform.tfstate sur son PC est interdit. S'il est perdu, l'infra est orpheline. Si deux devs appliquent en même temps, c'est la corruption.

backend.tf (AWS S3 + DynamoDB)
terraform {
  backend "s3" {
    bucket         = "my-tf-state-bucket"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "tf-state-locks" # Gère le verrouillage
  }
}
Si Jean lance un terraform apply, DynamoDB verrouille le state. Si Alice essaie en même temps, elle reçoit : Error: distinct locking.

🛑 Troubleshooting : Error acquiring the state lock

  • Symptôme : Vous lancez terraform apply et recevez une erreur : Error: Error acquiring the state lock ... Lock Info: ID: 1234....
  • Diagnostic : Quelqu'un (ou un pipeline CI) exécute déjà une commande Terraform sur ce workspace, ou bien une exécution précédente a crashé (perte de connexion) sans relâcher le verrou (lock) dans DynamoDB.
  • Remède : 1. Vérifiez avec votre équipe si un pipeline est en cours.
    2. Si vous êtes absolument certain que c'est un verrou fantôme (crash), forcez le déverrouillage avec prudence : terraform force-unlock <LOCK_ID>.
    Attention : Casser un verrou actif corrompra votre fichier d'état.

🚀 E. Beyond Terraform

☸️

Crossplane

L'IaC dans Kubernetes. Créez une base de données AWS RDS en faisant un kubectl apply -f rds.yaml. K8s réconcilie l'infra cloud en continu.

🌊

Atlantis

GitOps pour Terraform. Le bot Atlantis commente le résultat de terraform plan directement dans votre Pull Request GitHub.

🛡️

Checkov

Scanner de sécurité statique pour IaC. Bloque le déploiement si un Security Group est ouvert sur 0.0.0.0/0.

📊 Cas d'étude : HashiCorp - Dogfooding Extreme

15k+ Applies / jour
99.99% Uptime Platform

Contexte : Comment HashiCorp gère son propre cloud (HCP) ? En utilisant leurs propres outils à l'extrême.

Architecture :

  • Nomad & Consul : Orchestration et Service Mesh (alternative à K8s).
  • Sentinel Policy as Code : Tout est vérifié. Impossible de déployer une ressource sans tag "Owner" ou qui coûte plus de X$ sans approval.
  • Ephemeral Environments : Chaque Pull Request crée un environnement complet éphémère qui est détruit après le merge.

⚠️ Le Danger : Drift

Si quelqu'un modifie l'infra manuellement dans la console AWS, le code et la réalité divergent.

$ terraform plan
~ update SG rule (Drift detected)

✅ Best Practices

  • Remote State : S3/GCS + Locking (DynamoDB)
  • Modules : Réutiliser via modules
  • Review : terraform plan dans PR
  • Immutable : Recréer plutôt que patcher
← Accueil