Daniel Allaire
716be304c5
Complète les 14 unités d'apprentissage au moule à 4 temps : Reverse-proxy, Courriel, Bases de données, Cache, Métriques & journaux, Supervision & impact, Virtualisation, Sécurité & durcissement, Infra as Code & idempotence, Liaisons (bindings, avec l'analogie NetScaler). Navigation complétée. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
68 lines
3.1 KiB
Markdown
68 lines
3.1 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.
|
|
|
|
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)**.
|