Daniel Allaire
85fed974a4
Le wiki datait du 3 aout. Verifie avant d'y toucher : toutes les cibles make citees existent, aucune commande morte. La-preuve.md annoncait P01-P21 ; le harnais est a P33. Les trois nouvelles ajoutees, et surtout la page dit maintenant ce que ces preuves NE FONT PAS : elles sont statiques, elles lisent le depot, et c'est dans cet angle mort qu'une AC est restee expiree huit heures sous un harnais vert. Infra-as-Code-et-idempotence.md enseignait l'idempotence comme acquise. Vrai role par role, faux a l'echelle de la flotte. La page enseigne desormais depuis les chiffres (924 -> 17 -> 0), raconte ce que les 17 cachaient, et explique pourquoi il faut verifier le zero lui-meme. Nouvelle unite « Verifier le deploye » : la difference entre valider du code et verifier un systeme, avec les trois regles qui separent un devis utile d'un devis decoratif. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
93 lines
4.4 KiB
Markdown
93 lines
4.4 KiB
Markdown
# 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)**.
|