Daniel Allaire
8f6de3ebe2
Registres (source unique): - docs/nomenclature.yml: domaines, VMID, plan d'adressage 10.1.0.0/16 segmente. - docs/bases-donnees.yml: bases applicatives (1 appli -> 1 base -> 1 owner -> 1 DSN). Roles de service: - Reseau/edge/PKI/mail: nginx, step_ca, sendmail. - Donnees/identite: postgresql (consommateur du registre BD), redis, openldap, keycloak. - Observabilite: prometheus, loki, grafana. - Supervision: icinga (coeur; Icinga Web 2 differe). Forge: forgejo. Integrations clientes: - clients_metriques, clients_journaux, clients_pki, clients_ldap, clients_smtp. Inventaire et outillage: - make inventaire-ui: refonte (cartes, theme sombre, onglets, vue Chaine VM->groupes-> playbooks->roles), saisie du provisioning, auto-proposition depuis la nomenclature, deploiement securise (verifier/deployer, jeton anti-CSRF, verrou, mot de passe vault), robustesse reseau (connexions fermees, favicon). - Makefile: cible verifier-deploiement; detection d'un group_vars de production chiffre. - Scission serveurs_web -> serveurs_web_frontaux/dorsaux; migration de l'adressage vers 10.1.x; retrait des hotes de test; planification des hotes; requirements.yml. Chaque role valide en --syntax-check et ansible-lint (profil production). Secrets references depuis Ansible Vault (jamais en clair); roles non testes live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
146 lines
5.4 KiB
Markdown
146 lines
5.4 KiB
Markdown
# Nomenclature des VM
|
||
|
||
La nomenclature doit rendre lisible le domaine opérationnel d'une VM sans l'enfermer dans un seul service.
|
||
|
||
Un hôte peut porter plusieurs groupes Ansible. Le nom de VM doit donc représenter une capacité ou un domaine, pas forcément un produit unique.
|
||
|
||
## Noms de VM
|
||
|
||
Format recommandé :
|
||
|
||
```text
|
||
<domaine>-<numero>
|
||
```
|
||
|
||
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 le domaine, au singulier puisqu'il nomme une instance :
|
||
|
||
```text
|
||
web-frontal-01 présentation web (UI, rendu, assets), groupe serveurs_web_frontaux
|
||
web-frontal-02
|
||
web-dorsal-01 application web (API, traitement), groupe serveurs_web_dorsaux
|
||
```
|
||
|
||
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` | `serveurs_step_ca` |
|
||
| `infra-edge-01` | `serveurs_nginx` |
|
||
| `infra-mail-01` | `serveurs_sendmail` |
|
||
| `infra-dns-01` | `serveurs_powerdns` |
|
||
| `idm-01` | `serveurs_openldap`, `serveurs_keycloak` |
|
||
| `data-01` | `serveurs_postgresql`, `serveurs_redis` |
|
||
| `obs-01` | `serveurs_prometheus`, `serveurs_loki`, `serveurs_grafana` |
|
||
| `mon-01` | `serveurs_icinga` |
|
||
| `forge-01` | `serveurs_forgejo` |
|
||
| `collab-01` | `serveurs_nextcloud`, `serveurs_collabora` |
|
||
| `web-frontal-01`, `web-frontal-02` | `serveurs_web_frontaux` |
|
||
| `web-dorsal-01` | `serveurs_web_dorsaux` |
|
||
|
||
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.1.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.1.11.0/24` | `10.1.11.1` |
|
||
| 2 — Identité | 12 | `10.1.12.0/24` | `10.1.12.1` |
|
||
| 3 — Données | 13 | `10.1.13.0/24` | `10.1.13.1` |
|
||
| 4 — Observabilité | 14 | `10.1.14.0/24` | `10.1.14.1` |
|
||
| 5 — Applications | 15 | `10.1.15.0/24` | `10.1.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.1.15.41`.
|
||
|
||
Tout se dérive du domaine de l'hôte, et la source unique machine-lisible est **`docs/nomenclature.yml`** :
|
||
|
||
```text
|
||
hostname = <domaine>-<NN>
|
||
VMID = 9 · catégorie · service · NN
|
||
VLAN = catégorie.vlan
|
||
IP = 10.1.<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 domaine (l'octet hôte reste dans le bloc du service). Au-delà, ouvrir un nouveau domaine/service dans `docs/nomenclature.yml`.
|
||
|
||
La segmentation `10.1.0.0/16` remplace l'ancienne plage d'essais `192.168.12.x`.
|
||
|
||
## Variables de provisioning d'hôte
|
||
|
||
L'inventaire est la source de vérité du provisioning d'une VM. Ces variables d'hôte sont saisissables via `make inventaire-ui` (ou à la main) et décrivent l'instanciation attendue :
|
||
|
||
| 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 renseignées dans l'inventaire ; leur consommation automatique par `make creer-vm` (au lieu des arguments en ligne de commande) est l'étape d'intégration suivante. Une valeur vide n'est pas écrite, pour garder l'inventaire propre.
|
||
|
||
## Hôtes planifiés
|
||
|
||
Les hôtes prévus mais non encore déployés sont placés dans `hotes_planifies`.
|
||
|
||
Les hôtes réellement joignables par Ansible sont placés dans `hotes_actifs`.
|
||
|
||
Planifier un hôte :
|
||
|
||
```bash
|
||
make hote-planifier HOTE=obs-01 VMID=94101 GROUPES="serveurs_debian serveurs_durcis serveurs_prometheus serveurs_loki"
|
||
```
|
||
|
||
Activer un hôte existant ou déjà cloné :
|
||
|
||
```bash
|
||
make hote-ajouter HOTE=obs-01 VMID=94101 ADRESSE_IP=192.168.12.141 GROUPES="serveurs_debian serveurs_durcis serveurs_prometheus serveurs_loki"
|
||
```
|
||
|
||
Les déploiements groupés limitent automatiquement l'exécution à :
|
||
|
||
```text
|
||
<groupe demandé> & hotes_actifs
|
||
```
|
||
|
||
Cela permet de renseigner l'inventaire complet sans tenter de configurer une VM qui n'existe pas encore.
|