Daniel Allaire
b775b7f99d
Suppression de toute trace Chezlepro de l'outil (roles, scripts, docs publiques, exemples, LICENSE). Prouve par scan exhaustif : git grep vide pour chezlepro, asgard/TrueNAS, supernet reel 10.1.x. Corrige 5 defauts de genericite fonctionnels (motd, app.ini Forgejo, organisation openldap, nom AC step-ca, et IP reelles codees en dur dans les defaults de roles -> plage d'exemple 10.0.x). LICENSE -> Alliance Boreale. Fichiers mainteneur + CHANGELOG conserves (par decision). La separation moteur/instance tient : OPS-Chezlepro surcharge deja ses vraies valeurs de topologie. Verifie : make verifier exit 0 (4 tests). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
138 lines
5.7 KiB
Markdown
138 lines
5.7 KiB
Markdown
# 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é :
|
||
|
||
```text
|
||
<fonction>-<NN>
|
||
```
|
||
|
||
Exemples :
|
||
|
||
```text
|
||
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 :
|
||
|
||
```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_sendmail` |
|
||
| `infra-dns-01` | `serveur_powerdns` |
|
||
| `idm-01` | `serveur_openldap`, `serveur_keycloak` |
|
||
| `data-01` | `serveur_postgresql`, `serveur_redis` |
|
||
| `obs-01` | `serveur_prometheus`, `serveur_loki`, `serveur_grafana` |
|
||
| `mon-01` | `serveur_icinga` |
|
||
| `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.
|
||
|
||
## 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.0.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.0.11.0/24` | `10.0.11.1` |
|
||
| 2 — Identité | 12 | `10.0.12.0/24` | `10.0.12.1` |
|
||
| 3 — Données | 13 | `10.0.13.0/24` | `10.0.13.1` |
|
||
| 4 — Observabilité | 14 | `10.0.14.0/24` | `10.0.14.1` |
|
||
| 5 — Applications | 15 | `10.0.15.0/24` | `10.0.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.0.15.41`.
|
||
|
||
Tout se dérive de la fonction de l'hôte, et la source unique machine-lisible est **`instance/plan/nomenclature.yml`** :
|
||
|
||
```text
|
||
hostname = <fonction>-<NN>
|
||
VMID = 9 · catégorie · service · NN
|
||
VLAN = catégorie.vlan
|
||
IP = 10.0.<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 `instance/plan/nomenclature.yml`.
|
||
|
||
La segmentation `10.0.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 `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`).
|