Set-OPS-Public/docs/conception/nomenclature-vm.md

Nomenclature des VM

Pour qui : le mainteneur qui nomme une 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
edge-mta-01
idm-01
data-sql-01
obs-01
mon-01
forge-01
collab-01
web-frontal-01
web-dorsal-01
ops-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 serveur_web_frontal
web-frontal-02
web-dorsal-01     application web (API, traitement), groupe serveur_web_dorsal

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	serveur_step_ca
infra-edge-01	serveur_nginx
infra-mail-01	serveur_dovecot (mail-store)
edge-mta-01	serveur_postfix, serveur_rspamd (ce qui parle à l'extérieur)
infra-dns-01	serveur_powerdns, serveur_resolveur
idm-01	serveur_openldap, serveur_keycloak
data-sql-01	serveur_postgresql, serveur_redis
obs-01	serveur_prometheus, serveur_loki, serveur_grafana
mon-01	serveur_icinga, serveur_icingaweb2, serveur_oauth2_proxy
ops-01	serveur_ops, serveur_ops_tenant (le runner de l'écosystème)
forge-01	serveur_forgejo
collab-01	serveur_nextcloud, serveur_collabora
web-frontal-01, web-frontal-02	serveur_web_frontal
web-dorsal-01	serveur_web_dorsal

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

VMID et adressage : tout dérive du seed index

Cette section décrivait le modèle d'avant le multi-instance, et rien n'y était plus vrai : un réseau unique 10.0.0.0/16, des VLAN 11 à 15, des plages de VMID à cinq chiffres (91xxx…99xxx). Il n'y a plus de plages à réserver, et il n'y a plus un réseau : chaque écosystème dérive le sien.

Une instance reçoit un seul champ d'adressage : index, dans instance/plan/nomenclature.yml. Tout le reste s'en déduit — et la preuve P20 interdit de stocker un adressage quelconque (supernet, sous_reseau, passerelle, vlan).

supernet      = 10.<index>.0.0/16
zone (3 oct.) = 10.<index>.(15 + catégorie)
sous-réseau   = 10.<index>.(15 + catégorie).0/24
passerelle    = 10.<index>.(15 + catégorie).1      ← premier hôte du /24
VLAN          = 1000 + index × 10 + zone           ← unique sur tout le trunk convergé
VMID          = <VLAN><hôte sur 3 chiffres><rang sur 2>   ← neuf chiffres, miroir de l'IP
adresse IP    = 10.<index>.(15 + catégorie).<hôte>

Le VMID est l'adresse, relue : 117602101 se lit 1176 (VLAN) · 021 (hôte) · 01 (rang). On retrouve la VM depuis son adresse, et l'inverse, sans registre.

Exemple, l'écosystème de référence (index: 17) : supernet 10.17.0.0/16, zones 10.17.16.0/24 à 10.17.21.0/24, VLAN 1171 à 1176. infra-edge-01 y vaut 10.17.16.11, et son VMID 117101101 se relit 1171 · 011 · 01.

(L'index se lit directement dans le second octet — c'est ce qui permet de reconnaître le tenant d'une adresse à l'œil. valider_index le borne, et la même borne protège un second plafond : à l'index 255, le VLAN vaut 3550 + zone, sous les 4094 du 802.1Q.)

Changer index redérive tout le réseau de l'écosystème. C'est ce qui rend un tenant portable d'un site à l'autre, et c'est pourquoi rien ne doit être écrit à la main. La preuve P21 refuse que deux instances fédérées partagent un index. Détail complet : multi-instances.md.

make inventaire-ui lit ce registre et propose VMID, VLAN, IP et passerelle quand on nomme un hôte. La sécurité entre zones ne repose pas sur l'adressage mais sur le registre des flux (nftables de l'hôte, pare-feu de l'hyperviseur, frontière) — flux-conception.md.

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 instance/plan/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 instance/plan/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 instance/plan/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 instance/plan/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 (instance/plan/serveurs.yml).