Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
253 lines
7.2 KiB
Markdown
253 lines
7.2 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 des couches** — le socle (`serveur_debian`, `serveur_durci`) d'abord, puis le rang de `docs/couches-deploiement.yml`, le même registre que `make site`.
|
|
|
|
> **Ce n'est pas « l'ordre de l'inventaire », et la nuance a coûté un déploiement.** Un tri
|
|
> alphabétique plaçait `client_metrique` avant `serveur_step_ca` : l'intégration réclamait un
|
|
> certificat que l'autorité, pas encore déployée, ne pouvait pas avoir émis. Constaté le
|
|
> 2026-08-06 sur les deux premières VM — dont l'hôte de l'AC lui-même. La couche
|
|
> « intégrations » dit en toutes lettres *déployées en dernier, quand leurs cibles sont
|
|
> debout* ; `make deployer` l'ignorait.
|
|
|
|
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/<inventaire>/group_vars/modeles_vm.yml`.
|
|
|
|
Les variables de conformité servent aux VM déployées dans `instance/inventories/<inventaire>/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
|
|
```
|