Convention de nommage¶

Schéma¶

Depuis le 2026-07-04, toute la flotte (à l'exception ponctuelle des nœuds FreeIPA, cf. plus bas) suit le schéma :

IND<SEGMENT><NNN>

Majuscules, sans tiret.
<SEGMENT> : code du segment réseau NSX d'appartenance (pas le rôle applicatif) — voir segments.tf du projet NSX.
<NNN> : numéro séquentiel sur 3 chiffres, attribué dans l'ordre des IP au sein du segment.

Le FQDN complet est <nom>.infra.indio.

Table des codes segment¶

Code	Segment	CIDR
`SERV`	seg-service	10.100.2.128/26
`DATA`	seg-data	10.100.2.192/27
`SUPV`	seg-supervision	10.100.2.224/28
`IDEN`	seg-identite	10.100.2.240/28
`SOC`	seg-soc	10.100.20.128/25
`PRXY`	seg-proxy (DMZ)	10.100.10.0/29
`PRXD`	seg-proxy-dns (DMZ)	10.100.10.8/29
`SAUV`	seg-sauvegarde	10.100.3.16/28
`ADMN` / `SOCA` / `STOR`	seg-admin / seg-soc-admin / seg-storage	— (pas de VM statique)

Table vivante

Le détail des VM par numéro évolue au fil des décommissionnements/reconstructions (voir Historique des décommissionnements). NetBox est la source de vérité à jour ; ne pas attribuer un nouveau numéro sans vérifier l'état live (vCenter + NetBox).

Découpage visuel du schéma (mêmes codes/CIDR que la table ci-dessus) :

flowchart LR
    NAME["IND〈SEGMENT〉〈NNN〉<br/>FQDN : nom.infra.indio"]

    NAME --> SERV["SERV<br/>seg-service<br/>10.100.2.128/26"]
    NAME --> DATA["DATA<br/>seg-data<br/>10.100.2.192/27"]
    NAME --> SUPV["SUPV<br/>seg-supervision<br/>10.100.2.224/28"]
    NAME --> IDEN["IDEN<br/>seg-identite<br/>10.100.2.240/28"]
    NAME --> SOC["SOC<br/>seg-soc<br/>10.100.20.128/25"]
    NAME --> PRXY["PRXY<br/>seg-proxy (DMZ)<br/>10.100.10.0/29"]
    NAME --> PRXD["PRXD<br/>seg-proxy-dns (DMZ)<br/>10.100.10.8/29"]
    NAME --> SAUV["SAUV<br/>seg-sauvegarde<br/>10.100.3.16/28"]
    NAME --> AUTRES["ADMN / SOCA / STOR<br/>seg-admin / seg-soc-admin / seg-storage<br/>pas de VM statique"]

Exemples réels (vérifiés dans le code Terraform et/ou l'état vivant, 2026-07-19) :

SERV → INDSERV002/003/004 (cluster HAProxy).
DATA → INDDATA001/002 (PostgreSQL primaire/standby, voir PostgreSQL).
SUPV → INDSUPV001/002/004 (Zabbix) et INDSUPV003 (Grafana, voir Zabbix / Grafana) — bon exemple concret de numérotation non séquentielle par rôle : le 003 s'est glissé entre les VM Zabbix au fil des déploiements successifs, illustration directe de l'avertissement « Table vivante » ci-dessus.
IDEN → INDIDEN001 (bastion Guacamole) puis INDIDEN008/009 (contrôleurs de domaine AD actuels, voir Durcissement AD) — la séquence a largement sauté au-delà de 002/003 au fil des reconstructions du realm.
SOC → INDSOC001 (syslog-ng).
PRXY / PRXD → INDPRXY001/002 (Squid) et INDPRXD001/002 (unbound), ce dépôt (voir Proxy Squid & DNS).

Écart constaté : seg-sauvegarde (SAUV) sans VM déployée

Le projet /root/veeam déclare une ressource vsphere_virtual_machine.veeam_repo (nom par défaut encore veeam-repo01, jamais renommé au schéma INDSAUV001), mais cette ressource n'apparaît pas dans son terraform.tfstate — seules les data sources (cluster, datastore, réseau, template) y figurent, preuve qu'elle n'a jamais été réellement appliquée. seg-sauvegarde reste donc à ce jour sans VM statique malgré la place réservée dans la table ci-dessus (gateway .30, cf. NSX) : ne pas supposer INDSAUV001 existant sans vérifier vCenter/NetBox.

Règles d'attribution du numéro `NNN`¶

Segment partiellement occupé → continuer la séquence existante, ne jamais réutiliser un numéro libéré par une VM détruite.
Segment entièrement vidé → repartir à 001 (comportement appliqué sur demande explicite ; à défaut de préférence exprimée, ne pas le supposer par défaut).

Rangement vCenter¶

Les VM sont classées dans des dossiers vCenter par segment NSX (/Datacenter/vm/seg-xxx). Chaque projet Terraform déclare vsphere_folder = "seg-xxx" en chemin relatif (le provider vSphere préfixe lui-même /Datacenter/vm/).

Exception fonctionnelle : les VM SOC/SIEM (ELK, n8n) sont rangées dans seg-soc côté vCenter même quand leur segment réseau NSX réel diffère — rangement cosmétique uniquement, sans impact sur les règles DFW/IP.

Exception FreeIPA : hostname minuscule¶

ipa-server-install/ipa-client-install refusent tout hostname contenant une majuscule. Pour tout hôte FreeIPA (serveur ou client), le hostname OS doit rester strictement minuscule (ex. indiden004.infra.indio) même si le nom d'affichage vCenter/NetBox reste en majuscule (INDIDEN004). Les rôles Ansible concernés écrivent explicitement {{ inventory_hostname | lower }}.infra.indio dans /etc/hosts pour éviter tout mismatch de résolution.

Points d'attention pour un renommage de VM¶

Un renommage de VM existante (changement de segment, correction de nommage) touche plusieurs systèmes dans cet ordre :

Hostname OS (ansible -m hostname / hostnamectl).
vCenter (govc object.rename).
NetBox (nom + dns_name de l'IP — NetBox met automatiquement dns_name en minuscule, les data sources Terraform qui filtrent dessus doivent envelopper la valeur avec lower(...)).
Code Terraform (var.nodes).

Deux pièges Terraform récurrents sur une VM gérée en for_each keyé par nom :

Changer le nom sans terraform state mv d'abord provoque un destroy+create (perte de la VM).
Le bloc clone[0].customize (qui contient host_name) force une recréation s'il diffère de l'état : l'ajouter à lifecycle.ignore_changes avant d'appliquer un renommage.