[infra] Squelette Terraform, backend distant et preuve plan/apply en MR #68

New issue

Closed

opened 2026-09-02 09:04:19 +00:00 by gabriel · 0 comments

gabriel commented

2026-09-02 09:04:19 +00:00

Member

Exigence couverte

ENF-09

Épreuve servie

EC04 · Cloud et sécurisation

Charge estimée

0,75 j.h

Ce qu'on veut obtenir

Un répertoire infra/terraform/ qui s'initialise contre le backend distant, applique un plan vide sans erreur, et dont chaque apply laisse une trace vérifiable en relecture, faute de service principal pour un apply automatique.

Critères d'acceptation

versions.tf (Terraform ≥ 1.9, azurerm ~> 4.0), providers.tf, backend.tf pointant sur le conteneur de #67, variables.tf, main.tf, outputs.tf sont en place.
terraform.tfvars.example est commité, terraform.tfvars réel est ignoré.
terraform init réussit contre le backend distant et terraform plan sur un dépôt propre affiche « No changes ».
L'authentification est documentée : az login utilisateur, pas de service principal, tenant 7f4f3591-… verrouillé.
Le modèle de demande de fusion demande, pour toute MR touchant infra/terraform/, la sortie de terraform plan avant fusion puis celle de terraform apply après.
docs/runbooks/terraform-etat.md décrit la manœuvre : plan -out, relecture, apply du plan enregistré.

Comment on le vérifie

Commande   terraform init && terraform validate && terraform plan
Attendu    init contre le backend distant, validate propre, plan « No changes »
Preuve     la sortie complète, et une MR d'exemple montrant le format plan puis apply

Manuel d'exploitation à mettre à jour

infra/terraform/README.md (remplacé), docs/runbooks/terraform-etat.md (complété), modèle de MR

Risque et retour arrière

Mauvaise clé de backend : l'état repart de zéro. Vérifier key = "enervision/terraform.tfstate" avant le premier apply. Dérive possible si quelqu'un applique sans plan : la relecture obligatoire sur les chemins d'infra le rattrape.

Dépendances

Dépend de #67 (bootstrap de l'état distant).

### Exigence couverte ENF-09 ### Épreuve servie EC04 · Cloud et sécurisation ### Charge estimée 0,75 j.h ### Ce qu'on veut obtenir Un répertoire `infra/terraform/` qui s'initialise contre le backend distant, applique un plan vide sans erreur, et dont chaque `apply` laisse une trace vérifiable en relecture, faute de service principal pour un `apply` automatique. ### Critères d'acceptation - [x] `versions.tf` (Terraform ≥ 1.9, `azurerm` ~> 4.0), `providers.tf`, `backend.tf` pointant sur le conteneur de #67, `variables.tf`, `main.tf`, `outputs.tf` sont en place. - [x] `terraform.tfvars.example` est commité, `terraform.tfvars` réel est ignoré. - [x] `terraform init` réussit contre le backend distant et `terraform plan` sur un dépôt propre affiche « No changes ». - [x] L'authentification est documentée : `az login` utilisateur, pas de service principal, tenant `7f4f3591-…` verrouillé. - [x] Le modèle de demande de fusion demande, pour toute MR touchant `infra/terraform/`, la sortie de `terraform plan` avant fusion puis celle de `terraform apply` après. - [x] `docs/runbooks/terraform-etat.md` décrit la manœuvre : `plan -out`, relecture, `apply` du plan enregistré. ### Comment on le vérifie ``` Commande terraform init && terraform validate && terraform plan Attendu init contre le backend distant, validate propre, plan « No changes » Preuve la sortie complète, et une MR d'exemple montrant le format plan puis apply ``` ### Manuel d'exploitation à mettre à jour `infra/terraform/README.md` (remplacé), `docs/runbooks/terraform-etat.md` (complété), modèle de MR ### Risque et retour arrière Mauvaise clé de backend : l'état repart de zéro. Vérifier `key = "enervision/terraform.tfstate"` avant le premier `apply`. Dérive possible si quelqu'un applique sans plan : la relecture obligatoire sur les chemins d'infra le rattrape. ### Dépendances Dépend de #67 (bootstrap de l'état distant).

gabriel self-assigned this

2026-09-02 09:04:19 +00:00

gabriel added the

labels

2026-09-02 09:04:19 +00:00

gabriel referenced this issue

2026-09-02 09:04:44 +00:00