Module 6 — Commandes avancées du workflow

Durée indicative du cours : 1h00
Durée indicative de l’atelier : — (atelier à venir, souvent couplé au module 5)
Durée totale (cours + atelier) : ~1h30–2h00

Objectif du module

Vous maîtrisez déjà init / plan / apply / destroy (Basics module 3).
Ce module ajoute les commandes et flags que l’on croise en prod, en reprise d’incident, et à l’examen TA-004 : ciblage, refresh, import, qualité de code (fmt, validate).

Carte mentale du jour 2

flowchart LR
  subgraph m4 [Module 4]
    P[Providers / auth]
  end
  subgraph m5 [Module 5]
    S[State distant / drift]
  end
  subgraph m6 [Module 6]
    C[CLI avancée]
  end
  P --> S --> C

Les modules 5 et 6 se complètent : le 5 explique quoi faire au state ; le 6 montre comment le CLI s’utilise au quotidien.

`terraform fmt` et `terraform validate`

Formatage

terraform fmt
terraform fmt -recursive
terraform fmt -check   # utile en CI : échoue si non formaté

fmt réécrit le style HCL (indentation, alignements).
Ce n’est pas un linter métier : c’est de la lisibilité et de la cohérence d’équipe.

Validation

terraform validate

validate vérifie la syntaxe et la cohérence interne de la config après un init réussi.
Il ne remplace pas un plan : il ne parle pas forcément à Azure pour calculer un écart complet.

Commande	Répond à
`fmt`	« Le style est-il homogène ? »
`validate`	« La config est-elle bien formée ? »
`plan`	« Que changerait-on dans le cloud ? »

Pipeline

En CI : fmt -check → validate → plan (avec credentials).
L’apply reste souvent manuel ou protégé (environnement, approbation).

Refresh et `-refresh-only`

Rappel du module 5 et de Basics :

terraform apply -refresh-only
terraform plan -refresh=false   # cas rare : plan sans refresh (perf / offline partiel)

Utilisez -refresh-only quand le cloud a bougé et que vous voulez mettre à jour le carnet sans appliquer tout le .tf.
Ce n’est pas un substitut à l’import.

Cibler une ressource : `-target`

terraform plan -target=azurerm_resource_group.main
terraform apply -target=azurerm_resource_group.main

-target limite le graphe aux ressources visées (et leurs dépendances nécessaires).
C’est un outil de secours ou de démarrage progressif, pas une architecture.

Anti-pattern

Enchaîner des apply -target au quotidien crée des états partiels difficiles à raisonner.
Preferez un plan complet dès que possible. HashiCorp le documente comme usage exceptionnel.

Quand c’est légitime :

débloquer une ressource bloquante pendant un incident ;
créer d’abord le resource group / le backend avant le reste ;
lab pédagogique pour isoler un effet.

Import en pratique (CLI et config)

CLI

terraform import azurerm_storage_account.lab \
  /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<name>

Bloc `import` (config)

Les versions récentes de Terraform permettent de déclarer l’import dans le HCL :

import {
  to = azurerm_resource_group.main
  id = "/subscriptions/.../resourceGroups/rg-demo-lab"
}

resource "azurerm_resource_group" "main" {
  name     = "rg-demo-lab"
  location = "switzerlandnorth"
}

Avantage : l’intention d’import est revue comme le reste du code (PR).
Après un import réussi, on retire souvent le bloc import une fois le state aligné (selon pratique d’équipe).

Checklist import

Ressource écrite (ou générée) dans le HCL avec la bonne adresse.
ID cloud exact.
terraform import ou apply du plan d’import.
terraform plan → comprendre chaque diff restant.
Ajuster attributs (tags, SKU, noms) jusqu’à un plan acceptable.

Lien module 5

L’import répond au cas « orphelin hors state ».
Pour le drift d’une ressource déjà gérée, ce n’est en général pas la première réponse.

Autres commandes utiles

Commande / flag	Rôle
`terraform state list` / `show` / `mv` / `rm`	Inspecter et refactorer le state (module 5)
`terraform output` / `-raw` / `-json`	Lire les sorties (approfondi module 9)
`terraform console`	Évaluer des expressions HCL (très utile module 8 et 10)
`terraform providers`	Voir providers requis / lock
`terraform force-unlock`	Lever un state lock orphelin (prudence)
`terraform workspace …`	Basculer d’espace d’état (module 5)

Scénario fil rouge — reprise contrôlée

Imaginez une équipe lab :

Un storage a été créé à la main pour un POC.
Un collègue a changé des tags sur un RG déjà géré.
Vous devez intégrer le storage et décider pour les tags.

Démarche type :

Étape	Action
1	`state list` + `plan` : voir drift du RG
2	Décider : code ou portail pour les tags → `apply` ou edit HCL
3	Écrire `azurerm_storage_account` + `import`
4	`plan` jusqu’à écarts compris / nuls
5	`fmt` + `validate` avant merge

Examen TA-004

Attendez-vous à des questions sur l’ordre init → plan → apply, le rôle de fmt / validate, l’effet de -target, et la différence import vs refresh.

À enrichir

Tableau « message d’erreur CLI → cause probable », exercices chrono métrés type examen, et atelier unifié modules 5–6.

Suite

Fin du jour 2 côté théorie providers / state / CLI.
Poursuivre au jour 3 avec le module 7 — Modules et design du dépôt.