Set-OPS/docs/nomenclature-vm.md

Nomenclature des VM

La nomenclature doit rendre lisible la fonction opérationnelle d'une VM sans l'enfermer dans un seul service. (« fonction » est le terme du plan ; « domaine » est réservé au DNS.)

Un hôte peut porter plusieurs groupes Ansible et plusieurs applications. Le nom de VM représente donc une capacité ou une fonction, pas forcément un produit unique.

Noms de VM

Format recommandé :

<fonction>-<NN>

Exemples :

infra-pki-01
infra-edge-01
infra-mail-01
infra-dns-01
idm-01
data-01
obs-01
mon-01
forge-01
collab-01
web-frontal-01
web-dorsal-01

La couche applicative web suit le même format. Le tier est porté par la fonction, au singulier puisqu'il nomme une instance :

web-frontal-01    présentation web (UI, rendu, assets), groupe serveurs_web_frontaux
web-frontal-02
web-dorsal-01     application web (API, traitement), groupe serveurs_web_dorsaux

Les anciens noms de test web-01 et web-02 sont retirés. Ils ne doivent pas être réutilisés comme noms de production : préférer web-frontal-NN et web-dorsal-NN.

Regroupements recommandés

Hôte	Groupes prévus
infra-pki-01	serveurs_step_ca
infra-edge-01	serveurs_nginx
infra-mail-01	serveurs_sendmail
infra-dns-01	serveurs_powerdns
idm-01	serveurs_openldap, serveurs_keycloak
data-01	serveurs_postgresql, serveurs_redis
obs-01	serveurs_prometheus, serveurs_loki, serveurs_grafana
mon-01	serveurs_icinga
forge-01	serveurs_forgejo
collab-01	serveurs_nextcloud, serveurs_collabora
web-frontal-01, web-frontal-02	serveurs_web_frontaux
web-dorsal-01	serveurs_web_dorsaux

Les groupes restent fins et composables. La cohabitation se fait en associant plusieurs groupes au même hôte.

Plages VMID

Plage	Usage
91xxx	fondations transversales : PKI, reverse proxy, SMTP
92xxx	identité : LDAP, SSO
93xxx	données et cache : PostgreSQL, Redis
94xxx	observabilité et supervision
95xxx	applications internes
99xxx	modèles, essais initiaux ou exceptions documentées

Plan d'adressage interne

Réseau interne unique : 10.1.0.0/16. Segmentation par fonction, un /24 et un VLAN par catégorie, 3ᵉ octet = VLAN (L2 alignée sur L3).

Catégorie	VLAN	Sous-réseau	Passerelle
1 — Fondations / infra	11	10.1.11.0/24	10.1.11.1
2 — Identité	12	10.1.12.0/24	10.1.12.1
3 — Données	13	10.1.13.0/24	10.1.13.1
4 — Observabilité	14	10.1.14.0/24	10.1.14.1
5 — Applications	15	10.1.15.0/24	10.1.15.1

Adresse d'hôte (4ᵉ octet) : service × 10 + NN. .1 = passerelle ; .2–.9 réservés. Exemple : web-dorsal-01 (catégorie 5, service 4, NN 01) → 10.1.15.41.

Tout se dérive de la fonction de l'hôte, et la source unique machine-lisible est docs/nomenclature.yml :

hostname = <fonction>-<NN>
VMID     = 9 · catégorie · service · NN
VLAN     = catégorie.vlan
IP       = 10.1.<vlan>.(service × 10 + NN)

make inventaire-ui lit ce registre et propose automatiquement VMID, VLAN, IP et passerelle quand on nomme un hôte. La sécurité entre zones se fera par règles inter-zones (nftables / edge), pas par l'adressage.

Contrainte : NN de 01 à 09 par fonction (l'octet hôte reste dans le bloc du service). Au-delà, ouvrir une nouvelle fonction/service dans docs/nomenclature.yml.

La segmentation 10.1.0.0/16 remplace l'ancienne plage d'essais 192.168.12.x.

Variables de provisioning d'hôte

Le plan est la source de vérité du provisioning. Le placement et le dimensionnement d'une VM vivent dans docs/serveurs.yml (vue Serveurs du GUI) ; VMID / IP / VLAN / passerelle sont dérivés de la fonction. Ces variables d'hôte sont alors générées dans l'inventaire (ne pas les éditer à la main) :

Variable	Sens	Type
ansible_host	adresse IP	str
proxmox_cidr	masque réseau en bits (0-32)	int
proxmox_passerelle	passerelle	str
proxmox_vlan	tag VLAN (1-4094)	int
proxmox_pont	pont réseau Proxmox (ex. vmbr0)	str
proxmox_dns	serveurs DNS Cloud-Init (séparés par virgule)	str
proxmox_vmid	identifiant VM Proxmox	int
proxmox_noeud	nœud Proxmox cible	str
proxmox_stockage	stockage du disque	str
proxmox_disque_taille	taille disque (ex. 32G)	str
proxmox_memoire	mémoire en Mo	int
proxmox_coeurs	nombre de cœurs	int

Ces valeurs sont générées dans l'inventaire depuis docs/serveurs.yml + la nomenclature (make instancier-appliquer). Une valeur vide n'est pas écrite, pour garder l'inventaire propre.

État d'un hôte (planifié / actif)

Chaque VM porte un etat dans docs/serveurs.yml :

• planifie — prévue mais non encore déployée → groupe hotes_planifies à la génération ;
• actif — réellement joignable par Ansible → groupe hotes_actifs.

L'état se change dans la vue Serveurs du GUI (ou docs/serveurs.yml), puis on régénère l'inventaire :

make instancier-appliquer

Les déploiements groupés limitent automatiquement l'exécution à <groupe demandé> & hotes_actifs, ce qui permet de décrire l'écosystème complet (hôtes planifiés inclus) sans tenter de configurer une VM qui n'existe pas encore.

Les anciennes commandes make hote-planifier / hote-ajouter éditaient hosts.yml directement ; l'inventaire étant désormais généré, elles sont supplantées par le plan (docs/serveurs.yml).