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>
203 lines
4.8 KiB
Markdown
203 lines
4.8 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.
|
|
|
|
## 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
|
|
```
|