Module 8 — HCP Terraform

Durée indicative du cours : 1 h 30
Durée indicative de l’atelier : atelier du jour 4, partagé avec le module 7
Durée totale (cours + atelier) : le jour 4 réunit les modules 7 à 9 et l’atelier du jour

Ce module couvre les objectifs 8a à 8d. HCP Terraform exécute le workflow du fil à distance. Les deux séries d’ateliers s’y retrouvent. Ce n’est pas un cloud d’infrastructure. C’est le service qui lance plan et apply pour l’équipe.

Deux sens du mot workspace

Un workspace de la CLI Terraform est un state nommé pour la même configuration, sur la machine ou dans un backend. Vous le changez avec terraform workspace select. terraform.workspace donne son nom dans une expression.

Un workspace HCP Terraform est un espace de travail du produit. Il a sa configuration, ses variables, son state et son historique de runs. Ce n’est pas le même objet. L’examen les distingue.

Créer l’infrastructure depuis HCP Terraform

Un run est un passage du workflow dans HCP Terraform : plan, puis apply si le plan est accepté. Le run peut être lancé depuis l’interface, depuis un dépôt connecté, ou depuis la CLI.

Le bloc cloud relie la configuration à une organisation et à un workspace.

terraform {
  cloud {
    organization = "lab-equipe"

    workspaces {
      name = "environnement"
    }
  }
}

terraform login ouvre une session vers HCP Terraform et enregistre un jeton local. terraform init utilise ensuite le bloc cloud comme backend distant. Le state quitte le dossier de travail. C’est la pratique commune du backend distant dans ce cours.

terraform plan et terraform apply déclenchent alors un run distant, sauf réglage contraire du workspace. Le plan s’affiche dans le produit. L’équipe le relit avant l’apply.

Pour un workspace déjà créé dans l’interface, le même bloc suffit. Pour migrer un state local existant, terraform init -migrate-state copie le carnet vers le workspace.

Projects et organisation du travail

Un project regroupe des workspaces. Vous y rangez l’environnement du fil, et plus tard les autres environnements de l’équipe, sans mélanger leurs states.

Les pièces que l’examen associe à cette organisation :

Les variables du workspace, pour les entrées de ce run. Une variable sensible y est stockée côté produit, pas dans le dépôt.
Les variable sets, pour partager des variables entre plusieurs workspaces du project.
Les run triggers, pour enchaîner un run quand un autre workspace a fini. La fiche peut ainsi être relue par un second workspace qui dépend d’elle.
La version de Terraform du workspace, distincte de celle de votre poste. L’équipe fige la version avec laquelle les runs s’exécutent.

Collaboration et gouvernance

HCP Terraform ajoute, autour du run, des fonctions que la CLI seule ne porte pas.

Les équipes et les droits, pour décider qui planifie et qui applique.
Le registre privé de modules, pour publier le module fiche à l’équipe.
La détection de dérive, pour relancer une lecture du réel et signaler un écart.
Les politiques, souvent en OPA ou Sentinel selon le réglage de l’organisation, pour refuser un plan qui ne respecte pas une règle.
Les change requests, pour relire un plan avant l’apply quand l’équipe l’exige.
Health et l’explorateur, pour voir l’état des workspaces et des ressources suivies.

Vous devez pouvoir dire à quoi sert chacune. Le jour 4, vous en ouvrez assez pour créer un project, un workspace, et un run du fil. Le réglage fin des politiques se comprend sur ce run, il ne fait pas un second cours.

L’authentification du provider vers une cible distante peut utiliser des identifiants dynamiques du workspace, au lieu d’un secret longue durée dans les variables. C’est le geste de gouvernance à citer quand la série d’ateliers parle à une cible qui demande un compte.

Ce que vous faites sur le fil

Créer un compte HashiCorp et une organisation.
Créer un project, puis un workspace environnement.
Ajouter le bloc cloud à la configuration du fil.
terraform login, puis terraform init -migrate-state si un state local existe.
Lancer un plan distant et le lire dans HCP Terraform avant d’appliquer.
Retrouver le state dans le workspace, plus dans le seul dossier du poste.

Ce que l’examen veut pour ce module

Objectif	Vous devez pouvoir l’expliquer
8a	Un run HCP Terraform exécute plan et apply. Le bloc `cloud` et `terraform login` relient la CLI
8b	Équipes, registre privé, dérive, politiques, variable sets et change requests servent la collaboration et la gouvernance
8c	Un project groupe des workspaces. Chaque workspace a son state, ses variables et ses runs
8d	On migre un state, on fixe la version de Terraform du workspace, et on connecte le dépôt ou la CLI

Points à retenir

Workspace CLI et workspace HCP Terraform ne sont pas le même objet.
HCP Terraform est le backend distant commun aux deux séries.
Le state distant se migre avec init -migrate-state.
Une politique refuse un plan. Elle ne remplace pas une validation dans le code. Les deux se complètent.

Suite

Poursuivre avec le module 9 — Révision de l’examen.