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>
202 lines
4.7 KiB
Markdown
202 lines
4.7 KiB
Markdown
# 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
|
|
|
|
```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 Chezlepro.
|
|
|
|
## 2. Goldenisation
|
|
|
|
La goldenisation est faite par :
|
|
|
|
```bash
|
|
make preparer-modele
|
|
```
|
|
|
|
Ce playbook ajoute le socle Chezlepro 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
|
|
serveurs_debian -> playbooks/groupes/serveurs_debian.yml
|
|
serveurs_durcis -> playbooks/groupes/serveurs_durcis.yml
|
|
```
|
|
|
|
L'appartenance aux groupes devient la déclaration d'intention :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```bash
|
|
make deployer-groupe GROUPE=serveurs_debian
|
|
```
|
|
|
|
## 7. Hardening commun
|
|
|
|
Le groupe `serveurs_durcis` maintient les couches de sécurité communes :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```text
|
|
playbooks/groupes/serveurs_debian.yml
|
|
playbooks/groupes/serveurs_durcis.yml
|
|
verifier-hote
|
|
```
|
|
|
|
Pour converger un groupe complet :
|
|
|
|
```bash
|
|
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 :
|
|
|
|
```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
|
|
```
|