704 lines
24 KiB
Markdown
704 lines
24 KiB
Markdown
# 🌲 Nomenclature Boréale v4 — Bio-Mimétiste & Autopoïétique
|
||
|
||
**Version :** 4.0
|
||
**Date :** 31 octobre 2025
|
||
**Statut :** Référence vivante (SSOT)
|
||
**Objet :** Établir la nomenclature organique des identifiants, adresses et noms au sein de l'écosystème boréal, selon le modèle à 8 couches bio-mimétiste et autopoïétique.
|
||
**Compatibilité :** Conforme au réalignement CRB-2 ; principe de **souveraineté DNS totale** des membres fédérés.
|
||
|
||
---
|
||
|
||
## 🌱 Préambule — Avis de Réalignement CRB-2
|
||
|
||
> **AB-Avis de Réalignement 31-10-2025 / Cycle de Réalignement Boréal #2**
|
||
>
|
||
> **Correction architecturale majeure : Souveraineté DNS des membres fédérés.**
|
||
>
|
||
> ### Changement fondamental
|
||
>
|
||
> **AVANT (v3)** : Supposait une zone DNS parent `alliance-boreale.ca` déléguant des sous-zones aux membres.
|
||
>
|
||
> **MAINTENANT (v4)** : **Chaque membre fédéré possède et contrôle 100% son propre domaine.**
|
||
>
|
||
> L'Alliance Boréale n'est **pas un membre fédéré**, mais un **concept organisationnel** et potentiellement un **tenant** hébergé par un membre.
|
||
>
|
||
> ### Implications
|
||
>
|
||
> 1. **DNS** : Pas de zone parent commune. Résilience par AXFR croisés (solidarité mutuelle).
|
||
> 2. **Découverte** : Services inter-membres via Registraire YAML (Document 14).
|
||
> 3. **Nommage** : `<service>.<contexte>.<domaine-membre>` (ex: `git.infra.chezlepro.ca`)
|
||
> 4. **Réseau** : `10.0.0.0/8` = infrastructure interne d'UN membre (pas partagé entre membres).
|
||
> 5. **Fédération** : `172.16.0.0/12` = optionnel VPN mesh inter-membres (Phase 2+).
|
||
>
|
||
> Ce document corrige les Sections 4.2, 5 et 7, et ajoute la Section 5 bis (Fédération DNS Souveraine).
|
||
|
||
---
|
||
|
||
## 🧬 1. Règle d'appartenance et portabilité
|
||
|
||
### 1.1 Règle par couche
|
||
|
||
* **C1–C4 = Fédération :** les racines et le métabolisme commun (datacenters, réseau, forge, artefacts).
|
||
* **C5 = Pivot :** la membrane d'échange, régulatrice des flux entre fédéré et tenant.
|
||
* **C6–C8 = Tenants :** la canopée cognitive, où se déploient les services, produits et connaissances.
|
||
|
||
### 1.2 Principe de portabilité
|
||
|
||
Tout tenant (C6-C8) doit pouvoir migrer sans perte vers un autre membre fédéré.
|
||
Garanties minimales :
|
||
|
||
1. **Descripteur YAML** complet (identités TTTII, DNS, inventaire, secrets référencés).
|
||
2. **Interopérabilité ouverte :** formats standard, exports intégraux testables.
|
||
3. **IaC & pipelines reproductibles :** Terraform/Ansible/CI signés.
|
||
4. **Identité & DNS fédérés :** SSO OpenID/SAML, délégation documentée.
|
||
5. **Observabilité scindée :** métriques infra chez le fédéré, applicatives chez le tenant, exportables.
|
||
|
||
---
|
||
|
||
## 🌳 2. Architecture vivante de référence
|
||
|
||
La nomenclature n'est pas un tableau : c'est un **organisme de cohérence**.
|
||
Les VMIDs, IPs et noms DNS forment la sève qui relie chaque organe du système.
|
||
|
||
### 2.1 Topologie organique de la fédération
|
||
|
||
```
|
||
[ C8 Conscience ]
|
||
▲
|
||
[ C7 Produits / Expériences ]
|
||
▲
|
||
[ C6 Services Tenant ]
|
||
▲
|
||
[ C5 Pivot / Membrane ]
|
||
▲
|
||
[ C4 Forge / Métabolisme commun ]
|
||
▲
|
||
[ C3 Gouvernance / Supervision ]
|
||
▲
|
||
[ C2 Réseau / DNS / PKI ]
|
||
▲
|
||
[ C1 Physique / Énergie / Sécurité ]
|
||
```
|
||
|
||
Chaque flèche représente une interface **adjacente et perméable** ; aucun flux ne traverse plusieurs couches directement.
|
||
|
||
---
|
||
|
||
## ⚙️ 3. Langage des identifiants et des services
|
||
|
||
La nomenclature décrit comment chaque élément s'inscrit dans le corps boréal.
|
||
|
||
### 3.1 Structure VMID (organes numériques)
|
||
|
||
**Format :**
|
||
|
||
```
|
||
0CTTII → Infrastructure fédérée (Couches 1–4)
|
||
TTTII → Tenants (Couches 6–8)
|
||
```
|
||
|
||
* `C` = Couche (1–4)
|
||
* `TT` = Type de service (00-99)
|
||
* `II` = Instance (01-99)
|
||
* `TTT` = Tenant ID (001-999)
|
||
|
||
**Plages principales :**
|
||
|
||
```
|
||
01000-01999 → C1 Physique
|
||
02000-02999 → C2 Réseau
|
||
03000-03999 → C3 Gouvernance / Supervision
|
||
04000-04999 → C4 Forge / Mutualisation
|
||
05000-05999 → C5 Pivot / Médiation
|
||
10000-99999 → C6-C8 Tenants
|
||
```
|
||
|
||
**Exemples :**
|
||
|
||
```
|
||
02001 → C2 : DNS Master (PowerDNS)
|
||
03010 → C3 : Keycloak (IdP)
|
||
04021 → C4 : Forgejo Git
|
||
05011 → C5 : FastAPI Admin / Portail
|
||
10011 → C6 : Backend tenant 001
|
||
10021 → C6 : DB tenant 001
|
||
```
|
||
|
||
---
|
||
|
||
## 🌐 4. Plan d'Adressage et Réseau
|
||
|
||
### 4.1 Invariants
|
||
|
||
* Tous les flux passent par leurs **couches adjacentes**.
|
||
* Les tenants ne parlent jamais directement au DNS fédéré (C2) : ils utilisent le résolveur du pivot (C5).
|
||
* Les services fédérés d'un membre partagent un espace d'adressage cohérent (10.0.0.0/8).
|
||
|
||
### 4.2 Répartition logique des espaces ⚠️ **CORRIGÉ CRB-2**
|
||
|
||
#### Adressage INTERNE (au sein d'un membre fédéré)
|
||
|
||
```
|
||
10.0.0.0/8 → Infrastructure interne d'UN membre fédéré
|
||
|
||
Répartition par couche :
|
||
10.0.0.0/24 → Management (C1)
|
||
10.0.1.0/24 → Forge & Mutualisation (C4)
|
||
10.0.2.0/24 → Réseau & DNS (C2)
|
||
10.0.3.0/24 → Gouvernance & Supervision (C3)
|
||
10.0.4.0/24 → Pivot Opérationnel (C5)
|
||
10.0.10.0/23 → Tenants (C6-C8)
|
||
```
|
||
|
||
**⚠️ IMPORTANT** : Cet espace est **propre à chaque membre**. Chezlepro utilise `10.0.0.0/8`, Nuage Libre utilise également `10.0.0.0/8` **indépendamment**. Pas de conflit car réseaux isolés.
|
||
|
||
#### Interconnexion INTER-MEMBRES (optionnel, futur)
|
||
|
||
```
|
||
172.16.0.0/12 → VPN mesh entre membres (WireGuard/Nebula)
|
||
|
||
Usage :
|
||
- Optionnel en Phase 1
|
||
- Un membre peut fonctionner 100% isolé
|
||
- Connexion au mesh fédératif = décision collective ultérieure
|
||
|
||
Allocation :
|
||
- Par membre, selon accord collectif
|
||
- Exemple : Chezlepro = 172.16.1.0/24
|
||
Nuage Libre = 172.16.2.0/24
|
||
```
|
||
|
||
#### Internet Public
|
||
|
||
```
|
||
IPs publiques → Services exposés (DNS, sites web, email, etc.)
|
||
|
||
Gestion :
|
||
- Chaque membre gère ses propres IPs publiques
|
||
- Pas de pool commun "Alliance Boréale"
|
||
- Enregistrement dans Registraire YAML (Document 14)
|
||
```
|
||
|
||
### 4.3 Flux autorisés (adjacent-only)
|
||
|
||
| Source | Destination | Sens | Description |
|
||
| ------ | ----------- | ---- | ---------------------------- |
|
||
| C1 | C2 | ↓ | Transport et synchronisation |
|
||
| C2 | C3 | ↓ | Télémetrie et topologie |
|
||
| C3 | C4 | ↓ | Politiques et clés |
|
||
| C4 | C5 | ↓ | Artefacts et secrets |
|
||
| C5 | C6 | ↓ | Déploiements et templates |
|
||
| C6 | C7 | ↓ | Services métiers |
|
||
| C7 | C8 | ↓ | Données d'usage |
|
||
| C8 | C7 | ↑ | Décisions et analyses |
|
||
| C7 | C6 | ↑ | Retours et métriques |
|
||
| C6 | C5 | ↑ | Logs et besoins |
|
||
| C5 | C4 | ↑ | Feedbacks |
|
||
| C4 | C3 | ↑ | Preuves et conformité |
|
||
| C3 | C2 | ↑ | Alertes et politiques réseau |
|
||
| C2 | C1 | ↑ | Charge et besoins physiques |
|
||
|
||
---
|
||
|
||
## 🧩 5. Noms de Machines et DNS ⚠️ **REFONTE COMPLÈTE CRB-2**
|
||
|
||
### 5.1 Principe de Souveraineté DNS
|
||
|
||
**Règle fondamentale** : Chaque membre fédéré possède et contrôle **100% son propre domaine**.
|
||
|
||
**L'Alliance Boréale n'opère AUCUNE zone DNS parent.**
|
||
|
||
### 5.2 Forme générale (CORRIGÉE)
|
||
|
||
```
|
||
<service>.<contexte>.<domaine-membre>
|
||
```
|
||
|
||
**Où :**
|
||
* `<service>` = nom du service (ns1, git, sso, pivot, etc.)
|
||
* `<contexte>` = infra | tenants | public (optionnel)
|
||
* `<domaine-membre>` = domaine souverain du membre (ex: chezlepro.ca)
|
||
|
||
### 5.3 Contextes de nommage
|
||
|
||
#### **infra** : Services fédérés (C1-C5)
|
||
|
||
Services d'infrastructure du membre, non exposés directement aux tenants.
|
||
|
||
```
|
||
ns1.infra.chezlepro.ca → DNS Master (C2)
|
||
ns2.infra.chezlepro.ca → DNS Slave (C2)
|
||
sso.infra.chezlepro.ca → Keycloak (C3)
|
||
git.infra.chezlepro.ca → Forgejo (C4)
|
||
pivot.infra.chezlepro.ca → FastAPI Admin (C5)
|
||
vault.infra.chezlepro.ca → Secrets (C4)
|
||
```
|
||
|
||
#### **tenants** : Tenants hébergés (C6-C8)
|
||
|
||
Services appartenant aux clients/projets hébergés.
|
||
|
||
```
|
||
client-x.tenants.chezlepro.ca → Tenant d'un client
|
||
mon-app.tenants.chezlepro.ca → Projet personnel
|
||
alliance-boreale.tenants.chezlepro.ca → L'Alliance comme tenant
|
||
```
|
||
|
||
#### **public** (optionnel) : Services à la racine
|
||
|
||
Services exposés publiquement, sans sous-domaine `infra`.
|
||
|
||
```
|
||
git.chezlepro.ca → Forge publique (alias vers git.infra.chezlepro.ca)
|
||
matrix.chezlepro.ca → Serveur Matrix public
|
||
mail.chezlepro.ca → MX email
|
||
www.chezlepro.ca → Site web corporate
|
||
```
|
||
|
||
### 5.4 Exemples concrets par membre
|
||
|
||
#### Chezlepro Inc. (slug: clp, domaine: chezlepro.ca)
|
||
|
||
```
|
||
# Infrastructure fédérée
|
||
ns1.infra.chezlepro.ca → 10.0.2.10 (VMID 02001)
|
||
ns2.infra.chezlepro.ca → 10.0.2.11 (VMID 02002)
|
||
sso.infra.chezlepro.ca → 10.0.3.20 (VMID 03010)
|
||
git.infra.chezlepro.ca → 10.0.1.20 (VMID 04021)
|
||
pivot.infra.chezlepro.ca → 10.0.4.10 (VMID 05011)
|
||
|
||
# Tenants
|
||
client-abc.tenants.chezlepro.ca → 10.0.10.10 (VMID 10101)
|
||
alliance-boreale.tenants.chezlepro.ca → 10.0.10.20 (VMID 10201)
|
||
|
||
# Public (optionnel)
|
||
git.chezlepro.ca → CNAME vers git.infra.chezlepro.ca
|
||
```
|
||
|
||
#### Nuage Libre (slug: nul, domaine: nuagelibre.ca)
|
||
|
||
```
|
||
# Infrastructure fédérée
|
||
ns1.infra.nuagelibre.ca
|
||
ns2.infra.nuagelibre.ca
|
||
sso.infra.nuagelibre.ca
|
||
git.infra.nuagelibre.ca
|
||
pivot.infra.nuagelibre.ca
|
||
|
||
# Tenants
|
||
startup-y.tenants.nuagelibre.ca
|
||
```
|
||
|
||
### 5.5 Convention de nommage des VMs
|
||
|
||
Format standardisé pour faciliter l'inventaire Ansible :
|
||
|
||
```
|
||
<membre>-<layer>-<service>-<env>-<instance>
|
||
```
|
||
|
||
**Où :**
|
||
* `<membre>` = slug court (clp, nul, tli)
|
||
* `<layer>` = infra | tenant
|
||
* `<service>` = dns-master, keycloak, forgejo, backend, db, etc.
|
||
* `<env>` = prod | staging | dev
|
||
* `<instance>` = 01, 02, 03...
|
||
|
||
**Exemples :**
|
||
|
||
```
|
||
clp-infra-dns-master-prod-01 → VMID 02001, ns1.infra.chezlepro.ca
|
||
clp-infra-dns-slave-prod-01 → VMID 02002, ns2.infra.chezlepro.ca
|
||
clp-infra-keycloak-prod-01 → VMID 03010, sso.infra.chezlepro.ca
|
||
clp-infra-forgejo-prod-01 → VMID 04021, git.infra.chezlepro.ca
|
||
clp-tenant-backend-prod-01 → VMID 10101, backend.client-x.tenants.chezlepro.ca
|
||
```
|
||
|
||
---
|
||
|
||
## 🌐 5 bis. Fédération DNS Souveraine ⚠️ **NOUVELLE SECTION CRB-2**
|
||
|
||
### Principe de Non-Hiérarchie DNS
|
||
|
||
**L'Alliance Boréale n'opère AUCUNE zone DNS parent.**
|
||
|
||
Contrairement aux modèles traditionnels où une organisation fédératrice gère une zone parent (ex: `.alliance-boreale.ca`) et délègue des sous-zones aux membres, **L'Alliance Boréale adopte un modèle de souveraineté totale**.
|
||
|
||
**Conséquences :**
|
||
- ✅ Chaque membre = maître absolu de son domaine
|
||
- ✅ Aucun SPOF (Single Point of Failure) DNS central
|
||
- ✅ Résilience par solidarité mutuelle (AXFR croisés)
|
||
- ✅ Portabilité : un membre peut quitter sans dépendance DNS
|
||
|
||
### Découverte de Services Inter-Membres
|
||
|
||
#### Option A : Registraire YAML (recommandé Phase 1)
|
||
|
||
Le Registraire (Document 14) contient les métadonnées de chaque membre.
|
||
|
||
**Exemple : `registraire/membres/m001-chezlepro.yml`**
|
||
|
||
```yaml
|
||
member_id: m001
|
||
slug: clp
|
||
status: active
|
||
|
||
identity:
|
||
legal_name: "Chezlepro Inc."
|
||
|
||
domains:
|
||
primary: chezlepro.ca
|
||
|
||
# Services exposés
|
||
services:
|
||
dns:
|
||
- ns1.infra.chezlepro.ca
|
||
- ns2.infra.chezlepro.ca
|
||
sso: sso.infra.chezlepro.ca
|
||
forge: git.infra.chezlepro.ca
|
||
matrix: matrix.chezlepro.ca
|
||
email: mail.chezlepro.ca
|
||
|
||
infrastructure:
|
||
dns:
|
||
primary_ns: ns1.infra.chezlepro.ca
|
||
secondary_ns: ns2.infra.chezlepro.ca
|
||
dnssec_enabled: true
|
||
|
||
public_ips:
|
||
dns_master: 203.0.113.10
|
||
dns_slave: 203.0.113.11
|
||
```
|
||
|
||
**Usage** : Un membre qui veut contacter Forgejo de Chezlepro lit le Registraire et découvre `git.infra.chezlepro.ca`.
|
||
|
||
#### Option B : DNS SRV Records (futur, optionnel)
|
||
|
||
Convention standardisée de records SRV pour découverte automatique.
|
||
|
||
```dns
|
||
; Zone chezlepro.ca
|
||
_git._tcp.federation.chezlepro.ca. SRV 10 0 443 git.infra.chezlepro.ca.
|
||
_matrix._tcp.federation.chezlepro.ca. SRV 10 0 8448 matrix.chezlepro.ca.
|
||
_xmpp-client._tcp.federation.chezlepro.ca. SRV 5 0 5222 xmpp.chezlepro.ca.
|
||
```
|
||
|
||
**Usage** : Un client peut requêter `_git._tcp.federation.chezlepro.ca` pour découvrir le serveur Forgejo.
|
||
|
||
#### Option C : Well-Known URIs (futur, optionnel)
|
||
|
||
```
|
||
https://chezlepro.ca/.well-known/alliance-boreale.json
|
||
```
|
||
|
||
Retourne :
|
||
|
||
```json
|
||
{
|
||
"member_id": "m001",
|
||
"slug": "clp",
|
||
"services": {
|
||
"dns": ["ns1.infra.chezlepro.ca", "ns2.infra.chezlepro.ca"],
|
||
"sso": "sso.infra.chezlepro.ca",
|
||
"forge": "git.infra.chezlepro.ca",
|
||
"matrix": "matrix.chezlepro.ca"
|
||
}
|
||
}
|
||
```
|
||
|
||
### Résilience DNS Mutuelle (Triangle de Solidarité)
|
||
|
||
**Principe** : Chaque membre héberge les DNS secondaires de **2 autres membres** via AXFR croisés.
|
||
|
||
**Avantages :**
|
||
- ✅ Résilience géographique (3 datacenters distincts)
|
||
- ✅ Solidarité technique concrète
|
||
- ✅ Pas de dépendance à un "hub" central
|
||
- ✅ Topologie décentralisée (pas de SPOF)
|
||
|
||
**Exemple : Triangle Chezlepro - Nuage Libre - TechnoLibre**
|
||
|
||
```
|
||
Chezlepro (chezlepro.ca) :
|
||
ns1.infra.chezlepro.ca (MASTER) → chez Chezlepro
|
||
ns2.infra.chezlepro.ca (SLAVE) → chez Nuage Libre
|
||
ns3.infra.chezlepro.ca (SLAVE) → chez TechnoLibre
|
||
|
||
Nuage Libre (nuagelibre.ca) :
|
||
ns1.infra.nuagelibre.ca (MASTER) → chez Nuage Libre
|
||
ns2.infra.nuagelibre.ca (SLAVE) → chez TechnoLibre
|
||
ns3.infra.nuagelibre.ca (SLAVE) → chez Chezlepro
|
||
|
||
TechnoLibre (technolibre.ca) :
|
||
ns1.infra.technolibre.ca (MASTER) → chez TechnoLibre
|
||
ns2.infra.technolibre.ca (SLAVE) → chez Chezlepro
|
||
ns3.infra.technolibre.ca (SLAVE) → chez Nuage Libre
|
||
```
|
||
|
||
**Configuration AXFR** : Voir Document 05 (Opération DNS Fédérée) pour détails techniques (TSIG, ACL, NOTIFY).
|
||
|
||
**Démarrage en solo** : Un membre peut commencer avec uniquement ns1 + ns2 locaux, puis ajouter ns3 externe quand un partenaire est identifié.
|
||
|
||
### Enregistrement au Registraire
|
||
|
||
**Obligatoire** : Chaque membre doit documenter ses DNS dans son fichier Registraire.
|
||
|
||
**Déclencheur** : Lors de l'onboarding (Semaine 3-4, Document 08).
|
||
|
||
**Validation** : Tests publics par pairs (voir Document 05, Section 5).
|
||
|
||
---
|
||
|
||
## 🪶 6. Procédures d'Ensemencement
|
||
|
||
Créer ou migrer une entité dans l'écosystème boréal revient à greffer une cellule dans un organisme.
|
||
|
||
### 6.1 Création d'un service fédéré (C1–C5)
|
||
|
||
1. **Choisir la couche et le type de service.**
|
||
2. **Attribuer le VMID** selon la plage (Section 3.1).
|
||
3. **Déterminer l'adresse IP** à partir du plan (Section 4.2).
|
||
4. **Nommer la VM** suivant la syntaxe (Section 5.5) :
|
||
|
||
```
|
||
<membre>-infra-<type>-prod-<instance>
|
||
```
|
||
|
||
5. **Créer l'entrée DNS** (Section 5.3) :
|
||
|
||
```
|
||
<service>.infra.<domaine-membre>
|
||
```
|
||
|
||
6. **Documenter** dans l'inventaire Ansible et le registre (Document 14).
|
||
|
||
**Exemple complet (DNS Master Chezlepro)** :
|
||
|
||
```yaml
|
||
# Étape 1 : Choix
|
||
Couche: C2 (Réseau)
|
||
Type: DNS Master (PowerDNS)
|
||
|
||
# Étape 2 : VMID
|
||
VMID: 02001 (C2, type 00, instance 01)
|
||
|
||
# Étape 3 : IP
|
||
IP interne: 10.0.2.10
|
||
IP publique: 203.0.113.10 (à fournir par membre)
|
||
|
||
# Étape 4 : Nom VM
|
||
clp-infra-dns-master-prod-01
|
||
|
||
# Étape 5 : DNS
|
||
FQDN: ns1.infra.chezlepro.ca
|
||
|
||
# Étape 6 : Documentation
|
||
Ansible inventory: inventories/production/hosts.yml
|
||
Registraire: registraire/membres/m001-chezlepro.yml
|
||
```
|
||
|
||
### 6.2 Création d'un tenant (C6–C8)
|
||
|
||
1. **Allouer un Tenant ID (tXXX)**.
|
||
2. **Définir le descripteur YAML** (TTTII, DNS, inventaire, secrets référencés).
|
||
3. **Générer le paquet portatif** : YAML + artefacts signés.
|
||
4. **Déployer via le pivot (C5)** ; aucun accès direct C4/C3.
|
||
5. **Vérifier la traçabilité** (ΔLog & preuves signées).
|
||
|
||
**Exemple complet (Tenant 001 "Alliance Boréale" hébergé chez Chezlepro)** :
|
||
|
||
```yaml
|
||
# Étape 1 : Tenant ID
|
||
Tenant ID: 001
|
||
|
||
# Étape 2 : Descripteur YAML
|
||
tenant_id: 001
|
||
slug: alliance-boreale
|
||
owner: L'Alliance Boréale (concept organisationnel)
|
||
hosted_by: m001 (Chezlepro)
|
||
|
||
vmids:
|
||
backend: 10101
|
||
database: 10102
|
||
frontend: 10103
|
||
|
||
dns:
|
||
zone: alliance-boreale.tenants.chezlepro.ca
|
||
records:
|
||
- name: www
|
||
type: A
|
||
value: 10.0.10.10
|
||
- name: api
|
||
type: A
|
||
value: 10.0.10.11
|
||
|
||
# Étape 3 : Paquet portatif
|
||
Artefacts:
|
||
- tenant-001-descriptor.yml (signé)
|
||
- terraform/ (IaC reproductible)
|
||
- ansible/ (playbooks)
|
||
- docker-compose.yml (si applicable)
|
||
|
||
# Étape 4 : Déploiement via pivot
|
||
Endpoint: https://pivot.infra.chezlepro.ca/api/v1/tenants
|
||
Méthode: POST avec JWT (authentifié via Keycloak)
|
||
|
||
# Étape 5 : Traçabilité
|
||
ΔLog: /governance/tenants/2025-10-tenant-001-deployed.md
|
||
Signature: GPG du Cercle Opérationnel
|
||
```
|
||
|
||
---
|
||
|
||
## 🌐 7. Tables de Correspondance ⚠️ **MISE À JOUR CRB-2**
|
||
|
||
### Exemple : Chezlepro Inc. (clp, chezlepro.ca)
|
||
|
||
| VMID | Couche | Nom VM | IP Interne | DNS | Fonction |
|
||
| ----- | :----: | ------------------------------- | ---------- | --------------------------------- | -------------------------- |
|
||
| 02001 | C2 | clp-infra-dns-master-prod-01 | 10.0.2.10 | ns1.infra.chezlepro.ca | DNS Master (PowerDNS) |
|
||
| 02002 | C2 | clp-infra-dns-slave-prod-01 | 10.0.2.11 | ns2.infra.chezlepro.ca | DNS Slave local |
|
||
| 03010 | C3 | clp-infra-keycloak-prod-01 | 10.0.3.20 | sso.infra.chezlepro.ca | IdP (Keycloak) |
|
||
| 04021 | C4 | clp-infra-forgejo-prod-01 | 10.0.1.20 | git.infra.chezlepro.ca | Forge (Forgejo) |
|
||
| 05011 | C5 | clp-infra-fastapi-pivot-prod-01 | 10.0.4.10 | pivot.infra.chezlepro.ca | Portail Admin (FastAPI) |
|
||
| 10101 | C6 | clp-tenant-backend-prod-01 | 10.0.10.10 | www.alliance-boreale.tenants.chezlepro.ca | Backend tenant 001 |
|
||
| 10102 | C6 | clp-tenant-db-postgres-prod-01 | 10.0.10.11 | db.alliance-boreale.tenants.chezlepro.ca | DB tenant 001 |
|
||
|
||
### Exemple : Nuage Libre (nul, nuagelibre.ca)
|
||
|
||
| VMID | Couche | Nom VM | IP Interne | DNS | Fonction |
|
||
| ----- | :----: | ------------------------------- | ---------- | --------------------------------- | -------------------------- |
|
||
| 02001 | C2 | nul-infra-dns-master-prod-01 | 10.0.2.10 | ns1.infra.nuagelibre.ca | DNS Master |
|
||
| 02002 | C2 | nul-infra-dns-slave-prod-01 | 10.0.2.11 | ns2.infra.nuagelibre.ca | DNS Slave local |
|
||
| 03010 | C3 | nul-infra-keycloak-prod-01 | 10.0.3.20 | sso.infra.nuagelibre.ca | IdP |
|
||
| 04021 | C4 | nul-infra-forgejo-prod-01 | 10.0.1.20 | git.infra.nuagelibre.ca | Forge |
|
||
|
||
**Note** : Chaque membre utilise le même plan d'adressage interne (`10.0.0.0/8`) indépendamment. Pas de conflit car réseaux isolés.
|
||
|
||
---
|
||
|
||
## 📜 8. ΔLog — Itération CRB-2 (31-10-2025)
|
||
|
||
### Changements v3.0 → v4.0
|
||
|
||
#### 🔥 **Corrections architecturales majeures**
|
||
|
||
1. **Section 4.2 (Plan d'Adressage)** :
|
||
- ✅ Clarifié : `10.0.0.0/8` = infrastructure interne d'UN membre (pas partagé)
|
||
- ✅ Clarifié : `172.16.0.0/12` = optionnel VPN mesh inter-membres (futur)
|
||
- ✅ Ajouté : Section "Internet Public" (IPs gérées par membre)
|
||
|
||
2. **Section 5 (Noms DNS)** :
|
||
- ❌ **SUPPRIMÉ** : `<service>.<contexte>.<membre>.alliance-boreale.ca`
|
||
- ✅ **NOUVEAU** : `<service>.<contexte>.<domaine-membre>`
|
||
- ✅ Exemples concrets : `ns1.infra.chezlepro.ca` au lieu de `dns-master.infra.czp.alliance-boreale.ca`
|
||
- ✅ Convention VM : `<membre>-<layer>-<service>-<env>-<instance>`
|
||
|
||
3. **Section 5 bis (NOUVELLE)** :
|
||
- ✅ Principe de Non-Hiérarchie DNS
|
||
- ✅ Découverte services (Registraire YAML, SRV records, well-known)
|
||
- ✅ Triangle de solidarité (AXFR croisés)
|
||
|
||
4. **Section 7 (Tables)** :
|
||
- ✅ Exemples mis à jour avec noms DNS corrigés
|
||
- ✅ Ajout colonne "Membre" pour clarté multi-membres
|
||
|
||
#### 📝 **Changements mineurs**
|
||
|
||
- Section 3.1 : Ajout exemple DNS Master (02001)
|
||
- Section 6.1/6.2 : Exemples complets avec nouveau format DNS
|
||
- Préambule CRB-2 : Explication détaillée du réalignement
|
||
|
||
#### 🎯 **Impact sur autres documents**
|
||
|
||
Documents à mettre à jour suite à CRB-2 :
|
||
- ✅ Document 05 (Opération DNS Fédérée) : Déjà aligné (suppose souveraineté)
|
||
- ⚠️ Document 14 (Registraire YAML) : Ajouter section `domains.primary` et `domains.services`
|
||
- ⚠️ Document 08 (Onboarding) : Mettre à jour processus DNS (pas de délégation parent)
|
||
- ⚠️ Tous playbooks Ansible : Variables DNS à corriger
|
||
|
||
#### 🧬 **Préservé de v3**
|
||
|
||
- Structure VMID (Section 3.1) : Inchangée
|
||
- Principe adjacent-only (Section 4.3) : Inchangé
|
||
- Procédures ensemencement (Section 6) : Structure préservée, exemples mis à jour
|
||
- Métaphores organiques : Préservées
|
||
|
||
---
|
||
|
||
## 🌌 9. Signature Boréale
|
||
|
||
> *Sous la voûte numérique, chaque bit est une graine.*
|
||
> *Chaque domaine est une forêt, chaque membre un écosystème.*
|
||
> *La fédération ne commande pas : elle relie par la confiance.*
|
||
> *Les racines DNS s'entrelacent, la canopée respire en autonomie.*
|
||
> *Ainsi pousse l'Alliance Boréale, souveraine et solidaire.*
|
||
|
||
---
|
||
|
||
**Fin du document — Référence vivante v4 (2025-10-31, CRB-2)**
|
||
📁 Ce fichier sert de base à la Nomenclature, aux pipelines, au Label de Prestige, et au Registraire.
|
||
|
||
**Prochaine révision prévue** : CRB-3 (quand nécessaire, pas de calendrier fixe)
|
||
|
||
---
|
||
|
||
## 📎 Annexe A : Migration v3 → v4 (Checklist)
|
||
|
||
### Pour les équipes techniques
|
||
|
||
- [ ] Mettre à jour inventaires Ansible avec nouveaux noms DNS
|
||
- [ ] Corriger playbooks utilisant ancien format `*.alliance-boreale.ca`
|
||
- [ ] Vérifier variables `dns_zone` dans group_vars
|
||
- [ ] Mettre à jour documentation interne (wikis, runbooks)
|
||
- [ ] Tester résolution DNS avec nouveaux FQDNs
|
||
|
||
### Pour le Registraire (Document 14)
|
||
|
||
- [ ] Ajouter champs `domains.primary` dans schéma membre
|
||
- [ ] Ajouter section `domains.services` (DNS, SSO, Forge, etc.)
|
||
- [ ] Migrer fiches membres existantes (m001, m002, etc.)
|
||
- [ ] Valider avec JSON Schema mis à jour
|
||
|
||
### Pour la gouvernance
|
||
|
||
- [ ] Notifier tous cercles du réalignement CRB-2
|
||
- [ ] Archiver v3 (avec étiquette Git `v3.0-deprecated`)
|
||
- [ ] Publier v4 comme référence active
|
||
- [ ] Mettre à jour Charte si nécessaire (références DNS)
|
||
|
||
---
|
||
|
||
## 📎 Annexe B : FAQ CRB-2
|
||
|
||
### Q1 : Pourquoi ce changement maintenant ?
|
||
|
||
**R** : Discussion avec Daniel (fondateur Chezlepro) a révélé incohérence architecturale. Correction nécessaire avant déploiement infrastructure (Phase 1 Ansible).
|
||
|
||
### Q2 : Impact sur travail déjà fait ?
|
||
|
||
**R** : Minimal. Documents 05 (DNS), 14 (Registraire), 08 (Onboarding) déjà alignés avec principe de souveraineté. Seuls inventaires Ansible à corriger (pas encore écrits).
|
||
|
||
### Q3 : Et si je veux garder `*.alliance-boreale.ca` ?
|
||
|
||
**R** : Tu peux acheter `alliance-boreale.ca` et le gérer comme **ton** domaine personnel si tu veux. Mais ce ne sera jamais une "zone parent officielle" de l'Alliance. L'Alliance = concept, pas infrastructure DNS.
|
||
|
||
### Q4 : Comment un nouveau membre découvre les services des autres ?
|
||
|
||
**R** : Via Registraire YAML (Document 14). Chaque membre documente ses services. Optionnellement : DNS SRV records ou API well-known (futur).
|
||
|
||
### Q5 : Triangle de solidarité = obligatoire ?
|
||
|
||
**R** : Non. Un membre peut démarrer avec ns1+ns2 locaux. Triangle = optionnel mais recommandé pour résilience maximale.
|
||
|
||
### Q6 : Peut-on avoir un domaine commercial + un domaine technique ?
|
||
|
||
**R** : Oui ! Exemple :
|
||
- `chezlepro.ca` = domaine commercial (site web, email)
|
||
- `chezlepro.net` = domaine technique (infrastructure interne)
|
||
|
||
Documenter les deux dans Registraire, spécifier lequel est `primary`.
|
||
|
||
---
|
||
|
||
**FIN NOMENCLATURE V4 (CRB-2)**
|