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

# Cycle de vie des VM

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