Daniel Allaire
8f6de3ebe2
Registres (source unique): - docs/nomenclature.yml: domaines, VMID, plan d'adressage 10.1.0.0/16 segmente. - docs/bases-donnees.yml: bases applicatives (1 appli -> 1 base -> 1 owner -> 1 DSN). Roles de service: - Reseau/edge/PKI/mail: nginx, step_ca, sendmail. - Donnees/identite: postgresql (consommateur du registre BD), redis, openldap, keycloak. - Observabilite: prometheus, loki, grafana. - Supervision: icinga (coeur; Icinga Web 2 differe). Forge: forgejo. Integrations clientes: - clients_metriques, clients_journaux, clients_pki, clients_ldap, clients_smtp. Inventaire et outillage: - make inventaire-ui: refonte (cartes, theme sombre, onglets, vue Chaine VM->groupes-> playbooks->roles), saisie du provisioning, auto-proposition depuis la nomenclature, deploiement securise (verifier/deployer, jeton anti-CSRF, verrou, mot de passe vault), robustesse reseau (connexions fermees, favicon). - Makefile: cible verifier-deploiement; detection d'un group_vars de production chiffre. - Scission serveurs_web -> serveurs_web_frontaux/dorsaux; migration de l'adressage vers 10.1.x; retrait des hotes de test; planification des hotes; requirements.yml. Chaque role valide en --syntax-check et ansible-lint (profil production). Secrets references depuis Ansible Vault (jamais en clair); roles non testes live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.7 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 :
serveurs_debian -> playbooks/groupes/serveurs_debian.yml
serveurs_durcis -> playbooks/groupes/serveurs_durcis.yml
L'appartenance aux groupes devient la déclaration d'intention :
web-frontal-01 dans serveurs_debian -> applique le socle Debian
web-frontal-01 dans serveurs_durcis -> 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 serveurs_debian maintient les composants de base :
make deployer-groupe GROUPE=serveurs_debian
7. Hardening commun
Le groupe serveurs_durcis maintient les couches de sécurité communes :
make deployer-groupe GROUPE=serveurs_durcis
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
Pour une VM déjà clonée et démarrée :
make hote-ajouter HOTE=web-frontal-01 VMID=95301 ADRESSE_IP=10.1.15.31 GROUPES="serveurs_debian serveurs_durcis"
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/serveurs_debian.yml
playbooks/groupes/serveurs_durcis.yml
verifier-hote
Pour converger un groupe complet :
make deployer-groupe GROUPE=serveurs_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 inventories/lab/group_vars/modeles_vm.yml.
Les variables de conformité servent aux VM déployées dans inventories/production/group_vars/serveurs_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