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