Set-OPS-Public/docs/vm-lifecycle.md

# 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
```