Set-OPS-Public/wiki/Infra-as-Code-et-idempotence.md

Infra as Code & idempotence

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

---

① Le concept (générique)

Infra as Code (IaC) : décrire l'infrastructure dans du code (versionné, revu, reproductible) plutôt qu'à la main. Le serveur devient le résultat d'un fichier, pas d'une suite de clics oubliés.

Déclaratif vs impératif :

• impératif = « fais ceci, puis cela » (une recette d'étapes) ;
• déclaratif = « voici l'état voulu » (le moteur trouve comment y arriver).

Idempotence : appliquer la même description N fois donne le même résultat. La 1ʳᵉ exécution change des choses ; les suivantes ne changent rien (changed=0). C'est ce qui rend l'IaC sûre à rejouer.

Modèle plan → apply : on décrit (plan), on prévisualise (dry-run), on applique. Tout est en contrôle de version (git), donc auditable et réversible.

---

② Comment Set-OPS le fait

• Ansible = le moteur déclaratif (des rôles décrivant l'état voulu, idempotents).
• Le plan (serveurs.yml, applications.yml, bases-donnees.yml) décrit quoi déployer.
• make instancier génère l'inventaire statique depuis le plan.
• make deployer applique les rôles ; le Vérifier (dry-run) prévisualise d'abord.
• Tout vit dans git (ce dépôt) — reproductible, revu, réversible.

L'idempotence ne se décrète pas : elle se mesure

Cette page a longtemps affirmé que redéployer un rôle donnait changed=0. C'était vrai rôle par rôle — et faux à l'échelle de la flotte, ce que personne n'avait vérifié. Le 2026-08-09, après une reconstruction complète, on a compté :

924  taches « changed »   rejeu depuis zero (tout est neuf : normal)
 17  taches « changed »   second passage    (la flotte devrait etre convergente)
  0  taches « changed »   apres correction

Les 17 n'étaient pas du bruit. Elles cachaient deux pannes qui ne se signalaient d'aucune autre façon :

Ce qu'on voyait	Ce que c'était
13× « démarrer node_exporter »	le service était mort — tué par SIGHUP à chaque renouvellement de certificat, donc toutes les 24 h, sur les quatorze hôtes
2× « déployer app.ini »	le dépôt faisait tourner le secret JWT de la forge à chaque déploiement, invalidant ses jetons

La leçon dépasse Ansible : un compteur de changements est un instrument de diagnostic. Tant qu'il indiquait 17, aucun de ces deux défauts n'était visible — ils se noyaient dans un fond qu'on avait pris l'habitude d'ignorer. Ramené à zéro, le moindre changed sur une flotte non modifiée devient un signal.

Vérifier le zéro, aussi. Un zéro peut vouloir dire « rien à faire » ou « plus rien ne travaille ». On a compté les tâches exécutées : 2266 au passage à vide contre 2152 au rejeu. Plus de tâches, aucune modification — donc convergence, pas silence.

---

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
Ansible	Terraform · Puppet · Chef · SaltStack · OpenTofu
plan → dry-run → apply	terraform plan/apply, tout workflow IaC
idempotence	propriété fondamentale de toute IaC sérieuse

Tu as appris le déclaratif, l'idempotence, plan→apply, l'infra versionnée — pas « Ansible ».

---

④ À toi de jouer

1. Sens l'idempotence. Redéploie un rôle déjà en place (ex. via la GUI ou make deployer HOTE=…) : la 2ᵉ fois, changed=0. Rien à faire = rien n'est touché.
2. Le flux déclaratif. Édite le plan (un serveur dans la GUI), ⚙ Appliquer le plan (instancier), puis Vérifier (dry-run) : tu prévisualises avant d'appliquer.
3. La réversibilité. git diff / git checkout sur le plan : l'état est du code, donc annulable.
4. Casse & répare. Modifie à la main un fichier géré par un rôle (ex. un .conf), puis redéploie : Ansible rétablit l'état voulu (le code gagne sur la dérive manuelle). Tu sens que la source de vérité, c'est le code.

---

Pour aller plus loin (dépôt)

• Le flux : make instancier → make instancier-appliquer → make deployer (ou la GUI).
• Le plan : instance/plan/ ; les rôles : roles/ ; l'autorité : AGENTS.md.
• Relations déclaratives entre entités : unité Liaisons (bindings).