Daniel Allaire
aab1bcc83a
README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index). Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis. QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires. Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous- dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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/exploitation/gabarit-debian13-justification.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/conception/integrations-vm.md
|
|
```
|