# Terraform Guide

> Guide Terraform pour l'Infrastructure as Code — modules, state management, workspaces et bonnes pratiques. À utiliser quand l'utilisateur écrit du Terraform, conçoit des modules ou gère de l'infrastructure cloud. Se déclenche aussi avec "terraform", "infrastructure as code", "terraform plan", "terraform apply", "module terraform", "tfstate", "HCL". Use when this capability is needed.

- Skill: `tomevault-io/terraform-guide-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/terraform-guide-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/terraform-guide-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/terraform-guide-2

---


# Guide Terraform

## Workflow

1. **Concevoir** : identifier les ressources, organiser en modules.
2. **Écrire** : fichiers HCL avec variables, outputs et data sources.
3. **Planifier** : `terraform plan` pour prévisualiser les changements.
4. **Appliquer** : `terraform apply` avec review et approbation.
5. **Maintenir** : state management, drift detection, mises à jour.

## Structure d'un projet

```
infrastructure/
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   ├── staging/
│   └── production/
├── modules/
│   ├── networking/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── database/
│   └── app-service/
└── shared/
    └── providers.tf
```

## Module réutilisable

```hcl
# modules/app-service/main.tf
variable "app_name" {
  type        = string
  description = "Nom de l'application"
}

variable "environment" {
  type        = string
  description = "Environnement (dev, staging, production)"
  validation {
    condition     = contains(["dev", "staging", "production"], var.environment)
    error_message = "L'environnement doit être dev, staging ou production."
  }
}

variable "sku" {
  type    = string
  default = "B1"
}

resource "azurerm_service_plan" "main" {
  name                = "plan-${var.app_name}-${var.environment}"
  location            = var.location
  resource_group_name = var.resource_group_name
  os_type             = "Linux"
  sku_name            = var.sku

  tags = local.common_tags
}

resource "azurerm_linux_web_app" "main" {
  name                = "app-${var.app_name}-${var.environment}"
  location            = var.location
  resource_group_name = var.resource_group_name
  service_plan_id     = azurerm_service_plan.main.id

  site_config {
    always_on = var.environment == "production"

    application_stack {
      dotnet_version = "8.0"
    }
  }

  app_settings = var.app_settings

  tags = local.common_tags
}

output "app_url" {
  value = "https://${azurerm_linux_web_app.main.default_hostname}"
}

locals {
  common_tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
    Application = var.app_name
  }
}
```

## State Management

### Backend distant (recommandé)

```hcl
# backend.tf
terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform-state"
    storage_account_name = "stterraformstate"
    container_name       = "tfstate"
    key                  = "myapp.dev.tfstate"
  }
}
```

### Commandes utiles

```bash
terraform init              # Initialiser le backend et les providers
terraform plan -out=plan.tf # Planifier et sauvegarder
terraform apply plan.tf     # Appliquer le plan sauvegardé
terraform state list        # Lister les ressources dans le state
terraform state show        # Afficher une ressource spécifique
terraform import            # Importer une ressource existante
```

## Bonnes pratiques

### À faire
- Utiliser des **modules** pour le code réutilisable
- Séparer les **environnements** dans des dossiers distincts
- Stocker le state dans un **backend distant** avec locking
- Utiliser `terraform plan` avant chaque `apply`
- Taguer toutes les ressources avec `ManagedBy = "terraform"`
- Valider les variables avec des blocs `validation`

### À éviter
- Stocker le state en local ou dans Git
- Hard-coder des valeurs — utiliser des variables
- Créer des modules trop granulaires ou trop monolithiques
- Ignorer le drift entre le state et la réalité
- Appliquer sans plan préalable

## Règles
- Le state Terraform ne doit **jamais** être commité dans Git.
- Chaque environnement a son propre state file.
- Les modules doivent avoir des `variables.tf` et `outputs.tf` documentés.
- Toujours utiliser `-out` avec `terraform plan` pour des applies déterministes.

---
> Source: [khalilbenaz/claude-skills-collection](https://github.com/khalilbenaz/claude-skills-collection) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-16 -->

