From 8b880c6cc2a5a3193096f52ded2bb990d5e179e7 Mon Sep 17 00:00:00 2001 From: Dan Allaire Date: Sat, 25 Oct 2025 17:52:54 -0400 Subject: [PATCH] =?UTF-8?q?retrait=20du=20glossaire=20obsol=C3=A8te?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/constitution/00_Nomenclature_v2.md | 831 ------------------------ 1 file changed, 831 deletions(-) delete mode 100644 docs/constitution/00_Nomenclature_v2.md diff --git a/docs/constitution/00_Nomenclature_v2.md b/docs/constitution/00_Nomenclature_v2.md deleted file mode 100644 index a287eb9..0000000 --- a/docs/constitution/00_Nomenclature_v2.md +++ /dev/null @@ -1,831 +0,0 @@ -# Standard de Nomenclature v2.0 - - -## Réalignement des couches & Portabilité des tenants - -### Règle d’appartenance par couche -- **C1–C4 = Fédération (membres fédérés, datacenters)** : réseau, calcul, stockage, orchestration **opérés par le membre**. -- **C5 = Supervision (pivot)** : observabilité d’infrastructure **côté fédéré**; observabilité applicative **exposée au tenant**. -- **C6–C8 = Tenants** : services applicatifs, données, gouvernance et intentions propres à chaque **tenant**. - -### Principe de portabilité des tenants -Un **tenant** (couches C6–C8) est **portable** entre membres fédérés, sans lock‑in. Les garanties minimales sont : -1. **Descripteur de tenant** versionné (YAML) couvrant identités **TTTII**, DNS, inventaire, et secrets référencés (voûte). -2. **Interopérabilité & export** basés sur standards ouverts ; **export complet** des données testable. -3. **IaC & pipelines** : (Terraform/Ansible/CI) pour créer/migrer/rejouer un tenant de façon reproductible. -4. **Identité & DNS fédérés** : SSO inter‑membres (OpenID/SAML) et délégation DNS documentée. -5. **Observabilité scindée** : métriques/alertes d’infra chez le fédéré ; métriques/alertes applicatives côté tenant, **exportables**. - -> **Note de gouvernance** — Les couches **inférieures (C1–C4)** appartiennent aux **fédérés et à leur fédération**; -> les couches **supérieures (C6–C8)** appartiennent aux **tenants**. C5 est un **pivot** partagé selon le principe ci‑dessus. - - - -## L'Alliance Boréale -**Version :** 2.0 -**Date :** 21 octobre 2025 -**Statut :** DRAFT - Validation requise par Cercle Technique -**Remplace :** N/A (première version unifiée) -**Auteur :** Daniel Mathieu (Chezlepro) avec assistance Claude -**Licence :** CC-BY-SA 4.0 ---- -## Table des Matières -1. [Introduction](#1-introduction) -2. [Principes Directeurs](#2-principes-directeurs) -3. [Architecture Réseau de Référence](#3-architecture-réseau-de-référence) -4. [Nomenclature VMID (Proxmox)](#4-nomenclature-vmid-proxmox) -5. [Plan d'Adressage IP](#5-plan-dadressage-ip) -6. [Nomenclature VMs (Noms)](#6-nomenclature-vms-noms) -7. [Nomenclature DNS](#7-nomenclature-dns) -8. [Tables de Correspondance](#8-tables-de-correspondance) -9. [Procédures Opérationnelles](#9-procédures-opérationnelles) -10. [Exemples Complets](#10-exemples-complets) -11. [Migration et Adoption](#11-migration-et-adoption) -12. [Annexes](#12-annexes) ---- -## 1. Introduction -### 1.1 Objectif du Document -Ce standard définit la **nomenclature unifiée** pour l'infrastructure de L'Alliance Boréale, couvrant : -- Identifiants de machines virtuelles (VMID) dans Proxmox -- Plan d'adressage IP interne (10.0.0.0/8) -- Noms de VMs lisibles et structurés -- Noms de domaine DNS internes et fédérés -- Correspondance entre tous ces éléments -### 1.2 Portée -Ce standard s'applique à **tous les membres** de L'Alliance Boréale. Chaque membre, opérant derrière son propre NAT/firewall, utilise ce standard dans son espace interne. -### 1.3 Cohérence avec l'Architecture -Ce document est **aligné sur** : -- **Plan d'Adressage IP v3** (03-standards-techniques.md) -- **Architecture à 8 Couches** (Charte Fondatrice) -- **Modèle de fédération décentralisée** (chaque membre autonome) ---- -## 2. Principes Directeurs -### 2.1 Mnémotechnique -Chaque identifiant doit être **immédiatement compréhensible** : -- Le VMID indique la couche et le type de service -- L'adresse IP reflète la fonction -- Le nom DNS est descriptif -### 2.2 Cohérence Totale -**Un seul système** lie : -``` -VMID ←→ IP ←→ Nom VM ←→ DNS -``` -### 2.3 Scalabilité -Le système supporte : -- Jusqu'à **999 tenants** par membre -- Jusqu'à **99 instances** par type de service -- Expansion future sans refonte -### 2.4 Isolation et Autonomie -- Chaque membre utilise **10.0.0.0/8** localement (derrière NAT) -- Pas de conflit entre membres (isolation par firewall) -- VMIDs peuvent être identiques entre membres (Proxmox séparés) ---- -## 3. Architecture Réseau de Référence -### 3.1 Vue Globale -``` -┌─────────────────────────────────────────────────────────────┐ -│ INTERNET PUBLIC │ -│ • Services exposés (web, email, DNS public) │ -└─────────────────────┬───────────────────────────────────────┘ - │ - ┌─────────────┼─────────────┐ - │ │ │ -┌───────▼──────┐ ┌────▼─────┐ ┌────▼─────┐ -│ Chezlepro │ │ Nuage │ │ Techno │ -│ FIREWALL/NAT │ │ Libre │ │ Libre │ -└───────┬──────┘ └────┬─────┘ └────┬─────┘ - │ │ │ - │ 10.0.0.0/8 │ 10.0.0.0/8 │ 10.0.0.0/8 - │ (local) │ (local) │ (local) - │ │ │ -┌───────▼─────────────┴─────────────▼──────────────────────┐ -│ ESPACE FÉDÉRATIF (172.16.0.0/12) │ -│ • Services accessibles entre membres via tunnels │ -│ • DNS secondaire, monitoring, backups │ -└───────────────────────────────────────────────────────────┘ -``` -### 3.2 Plan d'Adressage par Membre -Chaque membre utilise **10.0.0.0/8** selon cette structure : -``` -┌─────────────────────────────────────────────────────────────┐ -│ 10.0.0.0/8 - ESPACE INTERNE (derrière NAT) │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ INFRASTRUCTURE DU FÉDÉRÉ (Couches 1-4) │ -│ │ -│ 10.0.0.0/24 → Management (254 hôtes) │ -│ 10.0.1.0/24 → Platform Services (254 hôtes) │ -│ 10.0.2.0/24 → Public DNS (254 hôtes) │ -│ 10.0.20.0/22 → Reserved Infrastructure (1 024 hôtes) │ -│ │ -├─────────────────────────────────────────────────────────────┤ -│ │ -│ TENANTS (Couches 6-8) │ -│ │ -│ 10.0.10.0/23 → Tenant Infrastructure (512 hôtes) │ -│ 10.0.128.0/17 → Expansion (32 766 hôtes, 50% du /8) │ -│ │ -└─────────────────────────────────────────────────────────────┘ -``` ---- -## 4. Nomenclature VMID (Proxmox) -### 4.1 Principe Général -Le VMID Proxmox est un **identifiant numérique mnémotechnique** qui encode : -- La zone (Infrastructure ou Tenant) -- La couche (1-4 pour infra, tenant ID pour tenants) -- Le type de service -- L'instance -### 4.2 Infrastructure Fédéré (VMID 01000-04999) -**Format : `0CTTII`** -Où : -- `0` = Infrastructure fédéré (préfixe fixe) -- `C` = Couche (1, 2, 3, ou 4) -- `TT` = Type de service (00-99) -- `II` = Instance (01-99) -**Plages par Couche :** -``` -01000-01999 → Couche 1 - Physique (monitoring matériel) -02000-02999 → Couche 2 - Réseau (DNS, VPN, routeurs) -03000-03999 → Couche 3 - Stockage (Ceph, NFS, backups) -04000-04999 → Couche 4 - Orchestration (Ansible, Git, CI/CD) -``` -**Types de Services (TT) :** -#### Couche 2 - Réseau (02000-02999) -``` -00-09 : DNS (PowerDNS) -10-19 : VPN/WireGuard -20-29 : Routeurs virtuels -30-39 : Proxy/HAProxy -40-49 : Load Balancers -``` -#### Couche 3 - Stockage (03000-03999) -``` -00-09 : Ceph Monitors -10-19 : Ceph OSDs (si VMs) -20-29 : NFS Servers -30-39 : Backup Servers (PBS, Borg) -40-49 : Object Storage (MinIO → Confirmer: stockage objet côté Services (6) si non opéré comme infra; sinon rester 3/4) -``` -#### Couche 4 - Orchestration (04000-04999) -``` -00-09 : Ansible Controllers -10-19 : CI/CD Runners -20-29 : Forgejo/GitLab -30-39 : PostgreSQL → Reclassé Couche 6 – Services Platform -40-49 : FastAPI → Reclassé Couche 6 – Services Platform Admin -50-59 : Artifact Repositories -``` -**Exemples :** -``` -02001 = Couche 2, DNS (00), Instance 1 → PowerDNS Master -02002 = Couche 2, DNS (00), Instance 2 → PowerDNS Slave 1 -02101 = Couche 2, VPN (10), Instance 1 → WireGuard Gateway -04001 = Couche 4, Ansible (00), Instance 1 → Ansible Controller -04201 = Couche 4, Git (20), Instance 1 → Forgejo -``` -### 4.3 Tenants (VMID 10000-99999) -**Format : `TTTII`** -Où : -- `TTT` = Tenant ID (001-999) -- `II` = Instance dans le tenant (01-99) -**Plages par Tenant :** -``` -10001-10099 → Tenant 001 (99 VMs max) -20001-20099 → Tenant 002 (99 VMs max) -30001-30099 → Tenant 003 (99 VMs max) -... -99901-99999 → Tenant 999 (99 VMs max) -``` -**Convention Instance (II) :** -``` -01-09 : Web/Frontend -10-19 : Backend/API -20-29 : Bases de données -30-39 : Cache/Queue -40-49 : Workers/Jobs -50-59 : Monitoring tenant -60-69 : Dev/Staging -70-99 : Usage libre -``` -**Exemples :** -``` -10001 = Tenant 001, Instance 01 → Web Frontend -10002 = Tenant 001, Instance 02 → Web Frontend HA -10011 = Tenant 001, Instance 11 → Backend API -10021 = Tenant 001, Instance 21 → PostgreSQL → Reclassé Couche 6 – Services -20001 = Tenant 002, Instance 01 → Web Frontend -20011 = Tenant 002, Instance 11 → Backend -``` -### 4.4 Plages Réservées -``` -00000-00999 : Réservé Proxmox système -01000-04999 : Infrastructure Fédéré (Couches 1-4) -05000-09999 : Réservé extension infrastructure -10000-99999 : Tenants (001-999) -``` ---- -## 5. Plan d'Adressage IP -### 5.1 Infrastructure (10.0.0.0 - 10.0.23.255) -#### 10.0.0.0/24 - Management -``` -10.0.0.1 → Gateway/Firewall principal -10.0.0.10-.50 → Hyperviseurs Proxmox (nodes physiques) -10.0.0.100-.200 → Outils monitoring/admin (Icinga, Grafana) -10.0.0.250-.254 → Réservé administration -``` -#### 10.0.1.0/24 - Platform Services -``` -10.0.1.10 → Ansible Controller (VMID 04001) -10.0.1.20 → Forgejo Git (VMID 04201) -10.0.1.30 → PostgreSQL → Reclassé Couche 6 – Services Platform (VMID 04301) -10.0.1.40 → FastAPI → Reclassé Couche 6 – Services Platform Admin (VMID 04401) -10.0.1.50 → Dashboard React Platform (VMID 04501) -10.0.1.100-.200 → Autres services plateforme -``` -#### 10.0.2.0/24 - Public DNS -``` -10.0.2.10 → PowerDNS Master (VMID 02001) -10.0.2.11 → PowerDNS Slave 1 (VMID 02002) -10.0.2.12 → PowerDNS Slave 2 (VMID 02003) -10.0.2.20 → WireGuard Gateway (VMID 02101) -10.0.2.30 → HAProxy (VMID 02301) -10.0.2.100-.200 → Autres services réseau -``` -#### 10.0.20.0/22 - Reserved Infrastructure -``` -1 024 adresses réservées pour expansion infrastructure future -``` -### 5.2 Tenants (10.0.10.0 - 10.255.255.255) -#### 10.0.10.0/23 - Tenant Infrastructure -``` -512 adresses pour VMs des tenants -Allocation dynamique via IPAM -Gestion par FastAPI → Reclassé Couche 6 – Services Platform -``` -**Stratégie d'Allocation Suggérée :** -``` -10.0.10.0-.99 → Tenant 001 -10.0.10.100-.199 → Tenant 002 -10.0.11.0-.99 → Tenant 003 -... -``` -#### 10.0.128.0/17 - Expansion Massive -``` -32 766 adresses (50% du /8) -Réservé pour croissance future des tenants -``` -### 5.3 Formule de Calcul IP (Infrastructure) -Pour les services d'infrastructure avec VMID `0CTTII` : -**Si C=2 (DNS/Réseau) :** -``` -IP = 10.0.2.(TT*10 + II) -``` -**Exemples :** -``` -VMID 02001 → TT=00, II=01 → 10.0.2.(0*10+1) = 10.0.2.1 (mais on utilise .10) -VMID 02101 → TT=10, II=01 → 10.0.2.(10*10+1) = 10.0.2.101 (mais on utilise .20) -``` -**Note :** La formule est indicative. En pratique, on utilise une allocation manuelle cohérente documentée ci-dessus. ---- -## 6. Nomenclature VMs (Noms) -### 6.1 Infrastructure (Couches 1-4) -**Format : `-infra---`** -Où : -- `` = ID court du membre (czp, nul, tli, etc.) -- `infra` = Marqueur infrastructure (fixe) -- `` = Type de service (dns-master, ansible-ctrl, etc.) -- `` = Environnement (prod, stg, dev, test) -- `` = Numéro (01, 02, 03...) -**Exemples :** -``` -czp-infra-dns-master-prod-01 -czp-infra-dns-slave1-prod-01 -czp-infra-vpn-gateway-prod-01 -czp-infra-ansible-ctrl-prod-01 -czp-infra-git-forgejo-prod-01 -czp-infra-pbs-backup-prod-01 -czp-infra-ceph-mon1-prod-01 -``` -### 6.2 TENANTS (Couches 6-8) -**Format : `-t---`** -Où : -- `` = ID court du membre -- `t` = Tenant (t001, t002, t003...) -- `` = Type de service (web, db, api, backend, cache, worker...) -- `` = Environnement (prod, stg, dev) -- `` = Numéro (01, 02...) -**Exemples :** -``` -czp-t001-web-prod-01 -czp-t001-db-postgres-prod-01 -czp-t001-api-fastapi-prod-01 -czp-t001-backend-prod-01 -czp-t001-cache-redis-prod-01 -czp-t002-web-prod-01 -czp-t002-app-backend-prod-01 -czp-t002-db-mysql-prod-01 -``` -### 6.3 Conventions Types -**Infrastructure :** -``` -dns-master, dns-slave1, dns-slave2 -vpn-gateway, vpn-peer -ansible-ctrl, ci-runner -git-forgejo, git-gitlab -db-platform, api-admin -pbs-backup, borg-backup -ceph-mon, ceph-osd, nfs-server -``` -**Tenants :** -``` -web, web-nginx, web-apache -db-postgres, db-mysql, db-mariadb -api-fastapi, api-django, backend -cache-redis, cache-memcached -queue-rabbitmq, queue-redis -worker, job-processor -monitoring, logging -``` ---- -## 7. Nomenclature DNS -### 7.1 Infrastructure (Services Fédérés) -**Format : `.infra..alliance-boreale.ca`** -Où : -- `` = Nom du service (dns-master, ansible, git...) -- `infra` = Marqueur infrastructure (fixe) -- `` = ID court (czp, nul, tli) -- `alliance-boreale.ca` = Domaine fédéré -**Exemples :** -``` -dns-master.infra.czp.alliance-boreale.ca → 10.0.2.10 -dns-slave1.infra.czp.alliance-boreale.ca → 10.0.2.11 -vpn.infra.czp.alliance-boreale.ca → 10.0.2.20 -ansible.infra.czp.alliance-boreale.ca → 10.0.1.10 -git.infra.czp.alliance-boreale.ca → 10.0.1.20 -backup.infra.czp.alliance-boreale.ca → 10.0.1.30 -``` -### 7.2 Tenants -**Format : `.t..alliance-boreale.ca`** -Où : -- `` = Nom du service (web, db, api...) -- `t` = Tenant (t001, t002...) -- `` = ID court -- `alliance-boreale.ca` = Domaine fédéré -**Exemples :** -``` -web.t001.czp.alliance-boreale.ca → 10.0.10.1 -db.t001.czp.alliance-boreale.ca → 10.0.10.2 -api.t001.czp.alliance-boreale.ca → 10.0.10.3 -web.t002.czp.alliance-boreale.ca → 10.0.10.10 -backend.t002.czp.alliance-boreale.ca → 10.0.10.11 -``` -### 7.3 DNS Publics (Exposés) -Pour les services exposés publiquement : -``` -www.tenant-example.com → IP publique (NAT vers 10.0.10.X) -mail.tenant-example.com → IP publique (NAT vers 10.0.10.Y) -``` -Le DNS interne reste accessible via le domaine `.alliance-boreale.ca` pour la fédération. ---- -## 8. Tables de Correspondance -### 8.1 Infrastructure Complète (Exemple Chezlepro) -| VMID | Nom VM | IP Interne | DNS | Fonction | -|------|--------|------------|-----|----------| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | PowerDNS Maître | -| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | PowerDNS Esclave 1 | -| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | PowerDNS Esclave 2 | -| 02101 | czp-infra-vpn-gateway-prod-01 | 10.0.2.20 | vpn.infra.czp.ab.ca | WireGuard Gateway | -| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | HAProxy Frontend | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Proxmox Backup Server | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Ansible Controller | -| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | Forgejo Git | -| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.30 | db.infra.czp.ab.ca | PostgreSQL → Reclassé Couche 6 – Services Platform | -| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | FastAPI → Reclassé Couche 6 – Services Admin | -### 8.2 Tenants (Exemples) -| VMID | Nom VM | IP Interne | DNS | Fonction | -|------|--------|------------|-----|----------| -| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Web Frontend T001 | -| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Web Frontend T001 HA | -| 10011 | czp-t001-api-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | API Backend T001 | -| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL → Reclassé Couche 6 – Services T001 | -| 20001 | czp-t002-web-prod-01 | 10.0.10.10 | web.t002.czp.ab.ca | Web Frontend T002 | -| 20011 | czp-t002-backend-prod-01 | 10.0.10.11 | backend.t002.czp.ab.ca | Backend T002 | -| 20021 | czp-t002-db-mysql-prod-01 | 10.0.10.12 | db.t002.czp.ab.ca | MySQL T002 | ---- -## 9. Procédures Opérationnelles -### 9.1 Création d'une Nouvelle VM Infrastructure -**Étapes :** -1. **Déterminer le VMID** - ``` - - Identifier la couche (2, 3, ou 4) - - Identifier le type de service - - Choisir l'instance disponible - Exemple: DNS Slave 3 → 02003 - ``` -2. **Calculer l'IP** - ``` - - Consulter la table d'allocation (section 5) - - Exemple: 02003 → 10.0.2.12 - ``` -3. **Construire le nom VM** - ``` - Format: -infra--- - Exemple: czp-infra-dns-slave3-prod-01 - ``` -4. **Créer l'entrée DNS** - ``` - Format: .infra..alliance-boreale.ca - Exemple: dns-slave3.infra.czp.alliance-boreale.ca → 10.0.2.12 - ``` -5. **Créer la VM dans Proxmox** - ```bash - qm create 02003 \ - --name czp-infra-dns-slave3-prod-01 \ - --net0 virtio,bridge=vmbr0,tag=2 \ - --ipconfig0 ip=10.0.2.12/24,gw=10.0.0.1 - ``` -6. **Documenter** - - Ajouter dans le registre des VMs - - Mettre à jour l'inventaire Ansible - - Ajouter dans le monitoring -### 9.2 Création d'une Nouvelle VM Tenant -**Étapes :** -1. **Allouer un Tenant ID** - ``` - - Consulter le registre des tenants - - Exemple: Prochain disponible = 003 → t003 - ``` -2. **Déterminer le VMID** - ``` - Format: TTTII - Exemple: Tenant 003, Web → 30001 - ``` -3. **Allouer une IP** - ``` - - Utiliser IPAM ou allocation manuelle dans 10.0.10.0/23 - - Exemple: 10.0.10.20 - ``` -4. **Construire le nom VM** - ``` - Format: -t--- - Exemple: czp-t003-web-prod-01 - ``` -5. **Créer l'entrée DNS** - ``` - Format: .t..alliance-boreale.ca - Exemple: web.t003.czp.alliance-boreale.ca → 10.0.10.20 - ``` -6. **Créer la VM dans Proxmox** - ```bash - qm create 30001 \ - --name czp-t003-web-prod-01 \ - --net0 virtio,bridge=vmbr0,tag=10 \ - --ipconfig0 ip=10.0.10.20/23,gw=10.0.0.1 - ``` -### 9.3 Migration d'une VM Existante -**Pour renommer selon le nouveau standard :** -1. **Identifier les attributs actuels** - ``` - VMID actuel: 104 - Nom actuel: vm-web-01 - IP actuelle: 10.50.100.5 - ``` -2. **Déterminer les nouveaux attributs** - ``` - Catégorie: Tenant 001 - Type: Web - → VMID: 10001 - → IP: 10.0.10.1 - → Nom: czp-t001-web-prod-01 - → DNS: web.t001.czp.alliance-boreale.ca - ``` -3. **Planifier la migration** - ``` - - Fenêtre de maintenance - - Backup complet - - Plan de rollback - ``` -4. **Exécuter la migration** - ```bash - # Arrêter la VM - qm stop 104 - # Renommer (si VMID change, recréer) - qm set 104 --name czp-t001-web-prod-01 - # Changer l'IP (dans la VM) - # Mettre à jour DNS - # Redémarrer - qm start 104 - # Valider - ``` ---- -## 10. Exemples Complets -### 10.1 Infrastructure Minimale (Bronze) -**Membre : Chezlepro (czp)** -| VMID | Nom | IP | DNS | Description | -|------|-----|-----|-----|-------------| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | DNS Maître | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Orchestration | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Backups | -### 10.2 Infrastructure Complète (Or) -**Membre : Chezlepro (czp)** -| VMID | Nom | IP | DNS | -|------|-----|-----|-----| -| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | -| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | -| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | -| 02101 | czp-infra-vpn-gw-nul-prod-01 | 10.0.2.20 | vpn-nul.infra.czp.ab.ca | -| 02102 | czp-infra-vpn-gw-tli-prod-01 | 10.0.2.21 | vpn-tli.infra.czp.ab.ca | -| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | -| 03001 | czp-infra-ceph-mon1-prod-01 | 10.0.1.50 | ceph-mon1.infra.czp.ab.ca | -| 03002 | czp-infra-ceph-mon2-prod-01 | 10.0.1.51 | ceph-mon2.infra.czp.ab.ca | -| 03003 | czp-infra-ceph-mon3-prod-01 | 10.0.1.52 | ceph-mon3.infra.czp.ab.ca | -| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | -| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | -| 04101 | czp-infra-ci-runner1-prod-01 | 10.0.1.60 | ci-runner1.infra.czp.ab.ca | -| 04102 | czp-infra-ci-runner2-prod-01 | 10.0.1.61 | ci-runner2.infra.czp.ab.ca | -| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | -| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.31 | db.infra.czp.ab.ca | -| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | -| 04501 | czp-infra-dashboard-react-prod-01 | 10.0.1.41 | dashboard.infra.czp.ab.ca | -### 10.3 Tenant Multi-Services -**Tenant 001 - Client "Acme Corp"** -| VMID | Nom | IP | DNS | Description | -|------|-----|-----|-----|-------------| -| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Frontend Nginx | -| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Frontend HA | -| 10011 | czp-t001-api-fastapi-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | Backend API | -| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL → Reclassé Couche 6 – Services 15 | -| 10031 | czp-t001-cache-redis-prod-01 | 10.0.10.5 | cache.t001.czp.ab.ca | Redis Cache | -| 10041 | czp-t001-worker-celery-prod-01 | 10.0.10.6 | worker.t001.czp.ab.ca | Celery Worker | -| 10061 | czp-t001-web-staging-01 | 10.0.10.7 | web-stg.t001.czp.ab.ca | Staging Web | -### 10.4 Architecture Fédérée (3 Membres) -**Services DNS exposés entre membres :** -| Membre | VMID | Nom | IP Interne | DNS Fédéré | IP Fédérée (172.16.x.x) | -|--------|------|-----|------------|------------|-------------------------| -| Chezlepro | 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | 172.16.1.10 | -| Nuage Libre | 02001 | nul-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.nul.ab.ca | 172.16.2.10 | -| TechnoLibre | 02001 | tli-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.tli.ab.ca | 172.16.3.10 | -**Note :** Les VMIDs sont identiques (02001) car chaque membre a son propre Proxmox. Les IPs internes sont identiques (10.0.2.10) car isolées par NAT. Les IPs fédérées (172.16.x.x) sont uniques et routées via tunnels VPN. ---- -## 11. Migration et Adoption -### 11.1 Stratégie de Migration -**Phase 1 : Documentation (Semaine 1-2)** -- [ ] Valider ce standard avec le Cercle Technique -- [ ] Obtenir le consentement de tous les membres actuels -- [ ] Publier dans la documentation officielle -- [ ] Former les administrateurs de chaque membre -**Phase 2 : Nouveaux Déploiements (Semaine 3+)** -- [ ] Toute nouvelle VM doit suivre ce standard -- [ ] Utiliser les templates Ansible/Terraform mis à jour -- [ ] Documenter dans le registre -**Phase 3 : Migration Progressive (Mois 2-6)** -- [ ] Inventorier toutes les VMs existantes -- [ ] Prioriser par criticité (services critiques en dernier) -- [ ] Planifier fenêtres de maintenance -- [ ] Migrer par lots (5-10 VMs à la fois) -- [ ] Valider après chaque lot -**Phase 4 : Consolidation (Mois 7-12)** -- [ ] Vérifier conformité à 100% -- [ ] Mettre à jour toute la documentation -- [ ] Former les nouveaux membres sur ce standard -### 11.2 Outils de Migration -**Script d'Audit :** -```bash -#!/bin/bash -# audit-nomenclature.sh -# Vérifie la conformité des VMs au standard v2.0 -for vmid in $(qm list | awk '{print $1}' | grep -v VMID); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,]*\).*/\1/') - echo "VMID: $vmid | Nom: $name | IP: $ip" - # Vérifier conformité VMID - if [[ ! $vmid =~ ^(0[1-4][0-9]{3}|[1-9][0-9]{4})$ ]]; then - echo " ⚠️ VMID non conforme" - fi - # Vérifier conformité nom - if [[ ! $name =~ ^[a-z]+-((infra)|(t[0-9]{3}))-[a-z0-9-]+-prod-[0-9]{2}$ ]]; then - echo " ⚠️ Nom non conforme" - fi - echo "" -done -``` -**Script de Génération DNS :** -```bash -#!/bin/bash -# generate-dns-records.sh -# Génère les enregistrements DNS à partir de l'inventaire Proxmox -MEMBER="czp" -DOMAIN="alliance-boreale.ca" -echo "; Infrastructure DNS Records" -for vmid in $(qm list | grep "infra" | awk '{print $1}'); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') - service=$(echo $name | cut -d'-' -f3-) - echo "${service}.infra.${MEMBER}.${DOMAIN}. IN A ${ip}" -done -echo "" -echo "; Tenant DNS Records" -for vmid in $(qm list | grep "\-t[0-9]" | awk '{print $1}'); do - name=$(qm config $vmid | grep "name:" | awk '{print $2}') - ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') - tenant=$(echo $name | grep -oP 't\d{3}') - service=$(echo $name | cut -d'-' -f3) - echo "${service}.${tenant}.${MEMBER}.${DOMAIN}. IN A ${ip}" -done -``` -### 11.3 Checklist de Conformité -**Pour chaque VM :** -- [ ] VMID respecte le format (0CTTII ou TTTII) -- [ ] Nom VM respecte le format -- [ ] IP cohérente avec la fonction -- [ ] Enregistrement DNS créé et fonctionnel -- [ ] Documenté dans l'inventaire -- [ ] Tags Proxmox appropriés -- [ ] Monitoring configuré ---- -## 12. Annexes -### 12.1 Glossaire -| Terme | Définition | -|-------|------------| -| **VMID** | Identifiant numérique unique d'une VM dans Proxmox | -| **Fédéré** | Membre de L'Alliance Boréale | -| **Tenant** | Client/organisation hébergé par un membre | -| **Infrastructure Fédéré** | Services propres au membre (couches 1-4) | -| **NAT** | Network Address Translation - isole l'espace 10.0.0.0/8 | -| **Espace Fédératif** | Plage 172.16.0.0/12 routée entre membres via tunnels | -### 12.2 Références -- **Document 03** : Standards Techniques (Plan d'Adressage IP v3) -- **Document 01** : Charte Fondatrice (Architecture 8 Couches) -- **Document 07** : Guide d'Intégration Technique -- **Document 14** : Structure YAML du Registraire -### 12.3 Table de Conversion VMID Legacy → v2.0 -**Si vous avez des VMs avec anciens VMIDs :** -| Fonction | VMID Legacy | VMID v2.0 | Justification | -|----------|-------------|-----------|---------------| -| DNS Master | 100 | 02001 | Couche 2, DNS (00), Instance 1 | -| DNS Slave | 101 | 02002 | Couche 2, DNS (00), Instance 2 | -| Ansible | 200 | 04001 | Couche 4, Ansible (00), Instance 1 | -| PostgreSQL → Reclassé Couche 6 – Services | 150 | 04301 | Couche 4, DB Platform (30), Instance 1 | -| Web Tenant 1 | 1001 | 10001 | Tenant 001, Instance 01 | -| DB Tenant 1 | 1002 | 10021 | Tenant 001, Instance 21 (DB) | -### 12.4 FAQ -**Q : Que faire si j'ai plus de 99 VMs pour un tenant ?** -R : Augmenter le nombre de chiffres pour l'instance (TTTIII au lieu de TTTII), ou subdiviser en sous-tenants (t001a, t001b). -**Q : Puis-je utiliser des VMIDs personnalisés ?** -R : Non pour les nouveaux déploiements. Le standard doit être respecté pour la cohérence fédérale. -**Q : Les VMIDs entre membres peuvent-ils être identiques ?** -R : Oui ! Chaque membre a son propre Proxmox. czp-002 peut avoir VMID 02001, et nul-002 aussi. -**Q : Comment gérer les environnements dev/staging ?** -R : Utiliser le champ `` dans le nom (prod, stg, dev). L'IP peut être dans un sous-réseau dédié (ex: 10.0.100.0/24 pour staging). -**Q : Faut-il migrer toutes les VMs immédiatement ?** -R : Non. Migration progressive recommandée sur 6-12 mois. Nouveaux déploiements doivent être conformes immédiatement. -**Q : Comment documenter les exceptions ?** -R : Dans le registre des VMs avec justification. Exceptions doivent être validées par le Cercle Technique. -### 12.5 Templates de Documentation -**Template Fiche VM (YAML) :** -```yaml -vm: - vmid: 02001 - name: czp-infra-dns-master-prod-01 - member: czp-001 - category: infrastructure - layer: 2 - service_type: dns - network: - ip: 10.0.2.10 - subnet: /24 - gateway: 10.0.0.1 - vlan: 2 - dns: - internal: dns-master.infra.czp.alliance-boreale.ca - federated: dns-master.infra.czp.alliance-boreale.ca - resources: - cpu: 2 - ram: 4096 - disk: 100G - backup: - enabled: true - schedule: daily - retention: 30d - monitoring: - enabled: true - checks: - - dns_query - - process_powerdns - - disk_usage - tags: - - infrastructure - - dns - - critical - - layer-2 -``` -**Template Entrée Inventaire Ansible :** -```yaml -# inventory/hosts.yml -all: - children: - infrastructure: - children: - layer_2_network: - hosts: - dns-master.infra.czp.alliance-boreale.ca: - ansible_host: 10.0.2.10 - vmid: 02001 - layer: 2 - service: dns-master - layer_4_orchestration: - hosts: - ansible.infra.czp.alliance-boreale.ca: - ansible_host: 10.0.1.10 - vmid: 04001 - layer: 4 - service: ansible-controller - tenants: - children: - tenant_001: - hosts: - web.t001.czp.alliance-boreale.ca: - ansible_host: 10.0.10.1 - vmid: 10001 - tenant: 001 - service: web -``` ---- -## 13. Validation et Approbation -### 13.1 Processus de Validation -**Ce document doit être validé par :** -- [ ] **Cercle Technique** - Validation technique de la nomenclature -- [ ] **Expert DevOps/SRE** - Validation Proxmox et automatisation -- [ ] **Expert Réseau** - Validation plan IP et DNS -- [ ] **Tous les membres actuels** - Consentement pour adoption -**Timeline :** -- Semaine 1-2 : Revue et commentaires -- Semaine 3 : Intégration des retours -- Semaine 4 : Vote de consentement -- Semaine 5+ : Publication et déploiement -### 13.2 Critères d'Acceptation -Pour que ce standard soit adopté : -- ✅ Aucun membre n'a d'objection majeure (principe de consentement) -- ✅ Compatibilité confirmée avec infrastructures existantes -- ✅ Outils de migration validés et testés -- ✅ Documentation complète et claire -- ✅ Formation prévue pour tous les administrateurs -### 13.3 Versionnage -**Version actuelle : 2.0 (DRAFT)** -Historique des versions : -- v2.0 (2025-10-21) : Création initiale - Nomenclature unifiée complète -- v2.1 (future) : Ajustements après retours terrain ---- -## 14. Maintenance du Standard -### 14.1 Révisions -Ce document sera révisé : -- **Annuellement** (octobre de chaque année) -- **À la demande** si problème majeur détecté -- **Lors d'évolutions** de l'architecture (nouveau plan IP, etc.) -### 14.2 Propositions de Modification -Pour proposer une modification : -1. Ouvrir une issue dans le dépôt Git de gouvernance -2. Documenter le problème et la solution proposée -3. Discussion au Cercle Technique (1 réunion minimum) -4. Vote de consentement si impact majeur -5. Publication de la nouvelle version -### 14.3 Responsable du Document -**Responsable principal :** Cercle Technique -**Contact :** technique@alliance-boreale.ca -**Dépôt Git :** https://forge.alliance-boreale.ca/standards/nomenclature ---- -## 15. Conclusion -### 15.1 Récapitulatif -Ce Standard de Nomenclature v2.0 établit : -- ✅ Un système unifié VMID ↔ IP ↔ Nom ↔ DNS -- ✅ Une organisation claire Infrastructure vs Tenants -- ✅ Une scalabilité jusqu'à 999 tenants par membre -- ✅ Une cohérence avec le Plan d'Adressage IP v3 -- ✅ Des procédures opérationnelles claires -- ✅ Une stratégie de migration progressive -### 15.2 Bénéfices Attendus -**Pour les Membres :** -- Gestion simplifiée de l'infrastructure -- Onboarding rapide des nouveaux administrateurs -- Automatisation facilitée (Ansible, Terraform) -- Audit et conformité simplifiés -**Pour L'Alliance :** -- Interopérabilité renforcée -- Documentation homogène -- Support technique facilité -- Crédibilité professionnelle -### 15.3 Prochaines Étapes -1. **Validation** : Soumettre au Cercle Technique (semaine du 28 octobre 2025) -2. **Révision** : Intégrer retours (semaine du 4 novembre 2025) -3. **Vote** : Consentement des membres (semaine du 11 novembre 2025) -4. **Publication** : Version finale (15 novembre 2025) -5. **Formation** : Sessions pour administrateurs (décembre 2025) -6. **Déploiement** : Nouveaux projets conformes (janvier 2026) -7. **Migration** : VMs existantes (jan-déc 2026) ---- -**« Une nomenclature claire est le fondement d'une infrastructure maîtrisée. »** ---- -**FIN DU DOCUMENT** -**Standard de Nomenclature v2.0 - L'Alliance Boréale** -**© 2025 L'Alliance Boréale - CC-BY-SA 4.0** -**Document préparé avec l'assistance de Claude (Anthropic)**