Daniel Allaire eab4975ab1 doc : la machine d'epreuve jetable — une doctrine qui n'avait pas son instrument

L'exploitant a decouvert par hasard, en creusant l'intrant « pont reseau », qu'on
peut fabriquer une VM HORS DU PLAN. Verification : `cloner-vm` n'etait mentionne
qu'UNE fois dans tout le depot, comme note de plomberie. L'usage n'etait nulle
part.

Or le depot porte deja la regle « eprouver l'outil avant d'ecrire le role qui
l'enveloppe » — elle a evite les bugs de premier deploiement de rspamd et tranche
le pivot Stalwart -> Postfix/Dovecot. L'instrument de cette regle n'etait pas
nomme.

DOCUMENTER LA DISCIPLINE, PAS SEULEMENT LA CAPACITE. Une telle VM est NUE :
l'inventaire ne la contient pas, `make raser` ne la detruira JAMAIS (il derive du
plan), aucun DNS, certificat, sauvegarde, pare-feu ni nftables, et son VMID n'est
garde par aucune preuve. Elle ne disparait que si on la detruit soi-meme — un VMID
oublie squatte le cluster sans que rien ne le signale, exactement comme un pont
disparu a survecu dix jours dans une declaration ce matin.

Ecrit pour trois lecteurs : le GESTE dans vm-lifecycle.md §4bis, la CAPACITE dans
pouvoirs-set-ops.md (qui evalue le moteur), le REFLEXE dans la discipline de
carte-set-ops.md (qui modifie le moteur).

Decouvrir une capacite de son propre outil par accident est le signe qu'elle
manquait a la documentation, pas au code.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-13 11:47:12 -04:00

6.6 KiB

Raw Blame History

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.

4bis. Une VM HORS PLAN, pour éprouver

make creer-vm HOTE=idm-01 dérive tout de l'inventaire — VMID, IP, VLAN, pont, stockage. C'est la voie normale, celle qu'emprunte flotte-creer.

Sous elle vit une couche qui ne consulte aucun plan :

make cloner-vm HOTE=essai-nginx VMID=99123 PONT_PROXMOX=t17appl \
     ADRESSE_IP=10.17.21.99 CIDR=24 PASSERELLE=10.17.21.1

Une Debian issue du gabarit doré, sur le réseau que vous choisissez, en deux minutes. Elle n'apparaît nulle part dans le plan.

À quoi ça sert. À honorer une règle du dépôt : éprouver l'outil avant d'écrire le rôle qui l'enveloppe. Avant de mettre un binaire en boîte — vérifier ses options réelles, sa configuration, ce qu'il fait au premier démarrage — on veut une machine vraie, jetable, qui ne salit rien. C'est ce que fournit cloner-vm. Le gabarit modeleSetOPS a lui-même été recapturé ainsi.

Elle est NUE, et c'est à la fois l'intérêt et le danger. Le moteur ne la connaît pas :

l'inventaire ne la contient pas

make raser ne la détruira jamais — il dérive du plan

DNS, certificat, sauvegarde aucun

pare-feu Proxmox, nftables aucune politique

son VMID gardé par aucune preuve contre une collision

Elle ne disparaît donc que si vous la détruisez :
ansible-playbook playbooks/proxmox/supprimer_vm_debian.yml -e vmid=99123
Choisissez un VMID hors des plages dérivées (les tenants occupent <VLAN><hôte><séq>, neuf chiffres) et notez-le. Un VMID oublié squatte le cluster sans que rien ne le signale — c'est exactement ainsi qu'un pont disparu a survécu dix jours dans une déclaration, en août 2026.


l'inventaire	ne la contient pas
`make raser`	ne la détruira jamais — il dérive du plan
DNS, certificat, sauvegarde	aucun
pare-feu Proxmox, nftables	aucune politique
son VMID	gardé par aucune preuve contre une collision

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

6.6 KiB Raw Blame History