« Mon infrastructure est montée et documentée, c’est suffisant. »
Documentée dans ta tête, ou dans des notes ? Si un serveur tombe, si tu changes de fournisseur, ou si tu veux un environnement de test identique, tu dois tout refaire à la main — et rien ne garantit que ce sera pareil. L’Infrastructure as Code transforme ton infra en code versionné, reproductible et exécutable.
À la fin de ce module, tu sauras…
- Nommer les limites concrètes de l’infrastructure manuelle
- Définir l’Infrastructure as Code et ses bénéfices
- Distinguer approche déclarative et impérative
- Situer les rôles de Terraform (provisioning) et Ansible (configuration)
01Compte ce que tu as fait à la main
L’inventaire de ton infrastructure manuelle
Depuis la Phase 0, liste tout ce que tu as créé en cliquant ou en tapant des commandes, VM par VM :
| VM | Créée comment | Configurée comment |
|---|---|---|
| opnsense, debian-gui | clics dans Proxmox | installation manuelle |
| jenkins, harbor, mgmt | clics dans Proxmox | apt, scripts, à la main |
| master-k3s, worker-k3s | clics dans Proxmox | installation K3s manuelle |
Comprends les 4 problèmes du manuel
1. Non reproductible : refaire à la main donne un résultat légèrement différent à chaque fois. 2. Non versionné : aucun historique, aucun « retour arrière » de l’infra. 3. Non documenté fidèlement : la vraie config vit dans les machines, pas dans tes notes. 4. Le “drift” : avec le temps, des modifications manuelles s’accumulent et personne ne sait plus l’état réel. L’IaC résout les quatre d’un coup.
02L’idée de l’Infrastructure as Code
Comprends le même chemin qu’avec le code applicatif
Tu as déjà fait ce voyage : en Phase 4, ton code est passé « du vrac sur une VM » à Git. En Phase 6, ton déploiement est passé « du manuel » au pipeline. L’IaC applique exactement la même logique à l’infrastructure elle-même : ce qui était gestuel et fragile devient textuel et fiable. C’est la dernière frontière du « as code ».
03Déclaratif, pas impératif
| Impératif (script bash) | Déclaratif (IaC) |
|---|---|
| « crée une VM, puis installe X, puis… » | « je veux 3 VMs avec ces specs » |
| tu décris les étapes | tu décris l’état voulu |
| rejouer = risque de casser | rejouer = converge vers l’état voulu |
| tu gères les différences | l’outil calcule les différences |
Comprends pourquoi le déclaratif gagne
Avec un script impératif, tu dois prévoir chaque cas (« et si la VM existe déjà ? »). Avec le déclaratif, tu décris la cible, et l’outil compare l’existant à la cible pour ne faire que le nécessaire. C’est la même idée que le Deployment Kubernetes : tu déclares « 3 replicas », pas « démarre un pod, puis un autre… ». Terraform applique ce principe à l’infrastructure entière — et c’est ce qui le rend sûr à rejouer.
04Deux outils, deux rôles
| Terraform | Ansible | |
|---|---|---|
| Rôle | Provisioning : créer l’infra | Configuration : régler l’intérieur |
| Question | « quelles machines existent ? » | « que contient chaque machine ? » |
| Dans ton projet | créer les VMs sur Proxmox | installer Docker, K3s… dedans |
| Modèle | déclaratif, avec état | procédural, idempotent |
Comprends la frontière, et pourquoi deux outils
Image mentale : Terraform bâtit les maisons vides (les VMs, le réseau, le stockage) ; Ansible les meuble (paquets, fichiers de config, services). On pourrait tout faire avec un seul outil, mais chacun excelle dans son domaine : Terraform pour le cycle de vie des ressources (créer/modifier/détruire avec un état), Ansible pour appliquer une configuration reproductible à l’intérieur. Cette séparation est un standard de l’industrie — indépendante de Proxmox.
✓Ce que tu retiens
L’infrastructure manuelle est non reproductible, non versionnée, sujette au drift. L’IaC la transforme en code déclaratif : tu décris l’état voulu, l’outil converge vers lui. Deux outils se partagent le travail : Terraform provisionne l’infra (les machines), Ansible la configure (l’intérieur). C’est la même démarche « as code » que tu as déjà appliquée au code et au déploiement.
Cartographie ton infra « à refaire »
À faire
- Dresse la liste complète de tes VMs, avec pour chacune : specs (CPU/RAM/disque), réseau, et logiciels installés.
- Pour une VM, écris la séquence impérative qu’il faudrait pour la recréer entièrement.
- Réécris la même intention en une phrase déclarative (« je veux… »).
- Classe chaque tâche de recréation en deux colonnes : « provisioning » (Terraform) ou « configuration » (Ansible).
- Documente dans BookStack : les 4 problèmes du manuel et la frontière Terraform / Ansible.
?Auto-évaluation
1. Qu’est-ce que le “drift” en infrastructure ?
L’écart qui se creuse entre l’état réel de l’infra et ce qu’on croit avoir, à cause de modifications manuelles accumulées et non tracées.
2. Quelle est la différence entre déclaratif et impératif ?
Impératif : on décrit les étapes. Déclaratif : on décrit l’état voulu, et l’outil calcule les changements nécessaires pour y converger.
3. Quelle est la frontière entre Terraform et Ansible ?
Terraform provisionne l’infrastructure (créer les machines, le réseau) ; Ansible configure l’intérieur des machines (paquets, services, fichiers).