# 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)**