# 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é : ```text - ``` Exemples : ```text 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 : ```text 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`). ```text supernet = 10..0.0/16 zone (3 oct.) = 10..(15 + catégorie) sous-réseau = 10..(15 + catégorie).0/24 passerelle = 10..(15 + catégorie).1 ← premier hôte du /24 VLAN = 1000 + index × 10 + zone ← unique sur tout le trunk convergé VMID = ← neuf chiffres, miroir de l'IP adresse IP = 10..(15 + catégorie). ``` 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`](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`](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 : ```bash make instancier-appliquer ``` Les déploiements groupés limitent automatiquement l'exécution à ` & 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`).