Daniel Allaire
eab4975ab1
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>
246 lines
6.6 KiB
Markdown
246 lines
6.6 KiB
Markdown
# 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
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```bash
|
|
make preparer-modele
|
|
```
|
|
|
|
Ce playbook ajoute le socle commun au template :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
docs/modeles_vm/debian13-proxmox.md
|
|
```
|
|
|
|
## 3. Validation et cleanup
|
|
|
|
Après la préparation :
|
|
|
|
```bash
|
|
make verifier-modele
|
|
```
|
|
|
|
Le cleanup final est séparé et protégé :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```text
|
|
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.
|
|
|
|
## 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 :
|
|
|
|
```text
|
|
serveur_debian -> playbooks/groupes/serveur_debian.yml
|
|
serveur_durci -> playbooks/groupes/serveur_durci.yml
|
|
```
|
|
|
|
L'appartenance aux groupes devient la déclaration d'intention :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```bash
|
|
make deployer-groupe GROUPE=serveur_debian
|
|
```
|
|
|
|
## 7. Hardening commun
|
|
|
|
Le groupe `serveur_durci` maintient les couches de sécurité communes :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```text
|
|
playbooks/groupes/serveur_debian.yml
|
|
playbooks/groupes/serveur_durci.yml
|
|
verifier-hote
|
|
```
|
|
|
|
Pour converger un groupe complet :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
DNS interne
|
|
PKI interne
|
|
identité
|
|
supervision
|
|
métriques
|
|
visualisation
|
|
```
|
|
|
|
Elles sont documentées dans :
|
|
|
|
```text
|
|
docs/integrations-vm.md
|
|
```
|