# 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.

Preuve d'idempotence, vue partout cette session : redéployer un rôle déjà en place →
**`changed=0`**. Et un refactor « neutre » (ex. le binding annuaire) → `changed=0` aussi : *même
état voulu = aucune modification*.

---

## ③ 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)**.