Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.8 KiB
Cycle de vie des VM
Pour qui : l'exploitant — ce qu'une VM traverse, de l'installation à la conformité continue.
Ce document décrit le cycle normal d'une VM Debian, depuis l'installation minimale jusqu'à la conformité continue par Ansible.
Vue d'ensemble
Debian 13 minimale
→ goldenisation du template
→ cleanup final
→ conversion Proxmox en template
→ clonage
→ identité initiale par cloud-init
→ conformité par groupes Ansible
→ intégrations par rôle
→ conformité continue
1. VM vanille
La VM vanille est une Debian 13 minimale installée manuellement ou par procédure Proxmox.
Elle contient seulement le nécessaire pour être joignable et prise en charge :
Debian 13
SSH
réseau fonctionnel
cloud-init installé
CloudInit Drive Proxmox présent
utilisateur initial injecté par Cloud-Init
clé publique SSH injectée par Cloud-Init
sudo ou accès root possible
aucun rôle applicatif
aucun secret
Cette VM n'est pas encore un golden template.
2. Goldenisation
La goldenisation est faite par :
make preparer-modele
Ce playbook ajoute le socle commun au template :
paquets communs
qemu-guest-agent
cloud-init
compte technique Ansible
chrony
SSH socle
durcissement template-safe
nftables préparé mais désactivé
Les détails et justifications sont dans :
docs/modeles_vm/debian13-proxmox.md
3. Validation et cleanup
Après la préparation :
make verifier-modele
Le cleanup final est séparé et protégé :
make nettoyer-modele CONFIRMER=true
Le cleanup ne doit jamais être lancé sur une VM de production.
4. Clonage
Le clone reçoit son identité initiale par Proxmox et cloud-init :
hostname
utilisateur initial
clé SSH
IP ou DHCP
passerelle
DNS
agrandissement disque
Cloud-init ne remplace pas Ansible pour la configuration réelle du serveur.
5. Groupes opérationnels
Une VM déployée doit être placée dans les groupes d'inventaire qui décrivent l'état voulu.
Les hôtes prévus mais non créés restent dans hotes_planifies.
Les hôtes joignables par Ansible sont dans hotes_actifs.
Chaque groupe opérationnel doit avoir un playbook homonyme :
serveur_debian -> playbooks/groupes/serveur_debian.yml
serveur_durci -> playbooks/groupes/serveur_durci.yml
L'appartenance aux groupes devient la déclaration d'intention :
web-frontal-01 dans serveur_debian -> applique le socle Debian
web-frontal-01 dans serveur_durci -> applique le durcissement commun
Un groupe sans playbook ne doit pas être assigné à une VM de production.
Un playbook de groupe peut être un contrat temporaire sans rôle tant que le service n'est pas encore implémenté. Il doit rester idempotent et explicite.
6. Socle Debian
Le groupe serveur_debian maintient les composants de base :
make deployer-groupe GROUPE=serveur_debian
7. Hardening commun
Le groupe serveur_durci maintient les couches de sécurité communes :
make deployer-groupe GROUPE=serveur_durci
L'accès SSH par mot de passe est désactivé dès le socle. L'activation de nftables doit rester dépendante des règles réseau propres au rôle du serveur.
8. Déploiement par Makefile
L'hôte est d'abord déclaré dans le plan (instance/plan/serveurs.yml) et l'inventaire régénéré (make instancier-appliquer) — hosts.yml est généré, il ne s'édite plus à la main. Pour une VM déjà clonée et démarrée :
make deployer HOTE=web-frontal-01
La cible deployer lit les groupes de l'hôte, cherche les playbooks correspondants dans playbooks/groupes/, puis les applique dans l'ordre de l'inventaire.
Ensuite, elle lance la vérification post-déploiement :
playbooks/groupes/serveur_debian.yml
playbooks/groupes/serveur_durci.yml
verifier-hote
Pour converger un groupe complet :
make deployer-groupe GROUPE=serveur_debian
Cette commande limite le playbook au croisement entre le groupe demandé et hotes_actifs.
9. Variables template et conformité
Les variables du template servent à construire le golden template dans instance/inventories/production/group_vars/modeles_vm.yml.
Les variables de conformité servent aux VM déployées dans instance/inventories/production/group_vars/serveur_debian.yml.
Différence attendue :
template : SSH par clé seulement, pare-feu non activé
conformité VM : même base SSH, règles réseau adaptées aux serveurs finaux
Ne pas durcir une variable de conformité si son application peut couper l'accès sans validation préalable.
10. Intégrations futures
Les intégrations transversales sont ajoutées après socle et durcissement :
DNS interne
PKI interne
identité
supervision
métriques
visualisation
Elles sont documentées dans :
docs/integrations-vm.md