Aller au contenu

Module 11 — Terraform Cloud / HCP Terraform

Durée indicative du cours : 1h15
Durée indicative de l’atelier : — (compte HashiCorp + workspace lab à venir)
Durée totale (cours + atelier) : ~2h00

Objectif du module

Jusqu’ici, l’équipe peut déjà travailler avec un backend distant Azure Storage et des pipelines ADO (modules 4–5).
Terraform Cloud (aujourd’hui souvent présenté sous la bannière HCP Terraform) ajoute une couche produit : workspaces managés, exécution distante, variables d’espace de travail, intégration VCS, et gouvernance.

Ce module est une amorce : assez pour enchaîner une démo et situer l’examen ; à enrichir avec captures et lab guidé.

Deux produits, un même mot : « workspace »

Workspaces CLI Workspaces TFC / HCP
Où Machine / backend (Azure Storage, etc.) Produit HashiCorp (UI / API)
Commande terraform workspace Création UI / API / CLI TFC
Référence HCL terraform.workspace Variables d’espace de travail, runs distants
Usage typique Lab, états nommés légers Équipes, VCS, droits, files d’attente

Piège oral / examen

Une question sur les « workspaces » peut viser l’un ou l’autre.
Relisez l’énoncé : CLI locale vs collaboration cloud.

Rappel CLI : module 5 et module 8.

À quoi sert Terraform Cloud ?

Problèmes que le produit adresse :

  • state distant hébergé sans gérer soi-même le storage (option) ;
  • runs plan / apply sur des runners HashiCorp (ou agents) ;
  • variables (y compris sensibles) par workspace ;
  • liaison VCS (PR → plan) ;
  • file d’attente et verrous pour éviter les applies concurrents ;
  • piste d’audit et collaboration multi-équipes.
flowchart LR
  Dev[Développeur / PR] --> VCS[Git]
  VCS --> TFC[Workspace TFC]
  TFC --> Plan[Plan distant]
  Plan --> Apply[Apply approuvé]
  Apply --> Cloud[Azure]
  TFC --- State[State hébergé]

Concepts de base (à connaître)

Concept Idée
Organization Conteneur d’équipe / facturation
Project Regroupement de workspaces dans une organisation (droits, navigation) — objectif TA-004 (8c)
Workspace Un espace = en pratique un state + config + variables + historique de runs
Run Exécution (plan, apply, policy check…)
Variables Terraform vars / env vars ; marquage sensitive
VCS connection Branche, working directory, triggers PR
Remote execution Le plan tourne dans HCP Terraform, pas seulement sur le laptop

Modes d’exécution (aperçu)

  • Remote : TFC exécute plan/apply.
  • Local : le CLI local exécute, TFC peut surtout stocker le state.
  • Agent : runners dans votre réseau (scénarios entreprise).

À enrichir

Tableau comparatif remote vs local vs agent ; captures UI organisation / workspace ; limites free tier au moment de la session.

Variables d’espace de travail vs tfvars

Source Rôle
*.tfvars / -var-file Valeurs dans le repo ou la CI « classique »
Variables TFC Injectées dans le run distant ; secrets hors Git
Variables d’environnement TFC Auth provider (ARM_*), flags

Lien avec le design multi-env du module 7 : un workspace HCP Terraform par environnement est un motif courant (dev / uat / prd), distinct des workspaces CLI.

Projects HCP Terraform

Objectif examen TA-004 (8c) : savoir organiser workspaces et projects, pas seulement créer un workspace isolé.

Dans HCP Terraform, la hiérarchie usuelle est :

Organization
  └── Project (ex. « plateforme-azure », « formation-lab »)
        └── Workspace (ex. « associate-lab-dev »)
        └── Workspace (ex. « associate-lab-prd »)
Niveau Rôle pédagogique
Organization Compte / équipe globale, facturation, politiques larges
Project Regrouper des workspaces liés (même produit, même cours, même équipe) et y attacher des droits cohérents
Workspace Un state, une config, des variables, des runs

Pourquoi les projects comptent en session :

  • Eviter une liste plate de dizaines de workspaces sans structure.
  • Donner des droits « tout le projet formation » plutôt qu’workspace par workspace.
  • Aligner le vocabulaire examen (workspaces et projects) avec ce que voit l’UI actuelle.

Message examen TA-004

Workspace CLI (terraform workspace) ≠ workspace HCP.
Sur HCP, un project regroupe des workspaces ; ce n’est pas un troisième type de state CLI.

À enrichir

Capture UI : Organization → Project → Workspace ; exercice créer un project « casestudit-lab » puis deux workspaces dev/prd.

Workflow typique (esquisse lab)

  1. Créer une organisation (ou rejoindre celle de formation).
  2. Créer un workspace lié au repo lab (working directory = racine Terraform).
  3. Renseigner les variables (ARM_CLIENT_ID, … ou OIDC selon setup).
  4. Déclencher un run (UI ou push).
  5. Relire le plan ; appliquer si la politique de la formation le permet.
  6. Comparer mentalement avec terraform plan local + backend Azure.

Auth Azure

Le détail WIF / App Registration reste au module 4.
Ici, on montre où brancher les variables dans TFC, pas on re-crée tout Entra.

Gouvernance — ouverture (ex-module collaboration)

Aperçu seulement (à développer ou scinder plus tard) :

  • droits d’équipe / équipes sur les workspaces ;
  • Sentinel / policy as code (overview examen) ;
  • coûts et run tasks ;
  • rappel pipeline ADO + WIF comme alternative ou complément.

À enrichir

Section dédiée Sentinel (syntaxe minimale, mock), matrice RBAС TFC, et comparaison « TFC alone » vs « ADO + backend Azure ».

Ce que l’examen TA-004 attend (cible)

  • Différence backend local / distant / HCP Terraform.
  • Rôle des workspaces HCP (pas seulement CLI).
  • Organisation via projects (regroupement + droits) — objectif 8c.
  • Variables sensibles côté produit.
  • Avantages collaboration (état partagé, runs, VCS).
  • Vocabulaire actuel : HCP Terraform (ex-Terraform Cloud).

Suite

Poursuivre avec le module 12 — Révision et préparation examen.