alliance-boreale/docs/constitution/00_Nomenclature_v2.md

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
2. Principes Directeurs
3. Architecture Réseau de Référence
4. Nomenclature VMID (Proxmox)
5. Plan d'Adressage IP
6. Nomenclature VMs (Noms)
7. Nomenclature DNS
8. Tables de Correspondance
9. Procédures Opérationnelles
10. Exemples Complets
11. Migration et Adoption
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 : <membre>-infra-<type>-<env>-<instance> Où :

• <membre> = ID court du membre (czp, nul, tli, etc.)
• infra = Marqueur infrastructure (fixe)
• <type> = Type de service (dns-master, ansible-ctrl, etc.)
• <env> = Environnement (prod, stg, dev, test)
• <instance> = 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 : <membre>-t<tenant-id>-<type>-<env>-<instance> Où :

• <membre> = ID court du membre
• t<tenant-id> = Tenant (t001, t002, t003...)
• <type> = Type de service (web, db, api, backend, cache, worker...)
• <env> = Environnement (prod, stg, dev)
• <instance> = 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 : <service>.infra.<membre>.alliance-boreale.ca Où :

• <service> = Nom du service (dns-master, ansible, git...)
• infra = Marqueur infrastructure (fixe)
• <membre> = 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 : <service>.t<tenant-id>.<membre>.alliance-boreale.ca Où :

• <service> = Nom du service (web, db, api...)
• t<tenant-id> = Tenant (t001, t002...)
• <membre> = 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: <membre>-infra-<type>-<env>-<instance>
   Exemple: czp-infra-dns-slave3-prod-01
   

4. Créer l'entrée DNS

   Format: <service>.infra.<membre>.alliance-boreale.ca
   Exemple: dns-slave3.infra.czp.alliance-boreale.ca → 10.0.2.12
   

5. Créer la VM dans Proxmox

   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: <membre>-t<tenant-id>-<type>-<env>-<instance>
   Exemple: czp-t003-web-prod-01
   

5. Créer l'entrée DNS

   Format: <service>.t<tenant-id>.<membre>.alliance-boreale.ca
   Exemple: web.t003.czp.alliance-boreale.ca → 10.0.10.20
   

6. Créer la VM dans Proxmox

   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

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

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.

Services DNS exposés entre membres :

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 :

#!/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 :

#!/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 <env> 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) :

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 :

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