Daniel Allaire
ba8cbe87bf
Catalogue : section "Etat d'implementation des roles" (implementes / echafaudages / roles-categories inertes) ; colonnes "Role futur" -> "Role". vm-lifecycle S8 : flux deploiement aligne sur le plan (au lieu de hote-ajouter, supplante). Refs inventories/lab laissees (golden template). Verifie : make verifier exit 0, ansible-lint 0 echec. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.8 KiB
Cycle de vie des VM Chezlepro
Ce document décrit le cycle normal d'une VM Debian Chezlepro, depuis l'installation minimale jusqu'à la conformité continue par Ansible.
Vue d'ensemble
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 :
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 Chezlepro.
2. Goldenisation
La goldenisation est faite par :
make preparer-modele
Ce playbook ajoute le socle Chezlepro commun au template :
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 :
docs/modeles_vm/debian13-proxmox.md
3. Validation et cleanup
Après la préparation :
make verifier-modele
Le cleanup final est séparé et protégé :
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 :
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 :
serveur_debian -> playbooks/groupes/serveur_debian.yml
serveur_durci -> playbooks/groupes/serveur_durci.yml
L'appartenance aux groupes devient la déclaration d'intention :
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 :
make deployer-groupe GROUPE=serveur_debian
7. Hardening commun
Le groupe serveur_durci maintient les couches de sécurité communes :
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 :
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 :
playbooks/groupes/serveur_debian.yml
playbooks/groupes/serveur_durci.yml
verifier-hote
Pour converger un groupe complet :
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/lab/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 :
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 :
DNS interne
PKI interne
identité
supervision
métriques
visualisation
Elles sont documentées dans :
docs/integrations-vm.md