Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
146 lines
6.6 KiB
Markdown
146 lines
6.6 KiB
Markdown
# 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
|
||
<fonction>-<NN>
|
||
```
|
||
|
||
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.<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`](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 à `<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`).
|