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>
5.4 KiB
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é :
<domaine>-<numero>
Exemples :
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 :
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 :
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 :
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é :
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 à :
<groupe demandé> & hotes_actifs
Cela permet de renseigner l'inventaire complet sans tenter de configurer une VM qui n'existe pas encore.