diff --git a/docs/00_Nomenclature_biomimetique_autopoietique_v3.md b/docs/00_Nomenclature_biomimetique_autopoietique_v3.md deleted file mode 100644 index a7adb10..0000000 --- a/docs/00_Nomenclature_biomimetique_autopoietique_v3.md +++ /dev/null @@ -1,242 +0,0 @@ -# đŸŒČ Nomenclature BorĂ©ale v3 — Bio-MimĂ©tiste & AutopoĂŻĂ©tique - -**Version :** 3.0 -**Date :** 25 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-1 ; C3 = gouvernance/supervision ; C4 = forge/mutualisation ; C5 = pivot ; C6–C8 = tenants. - ---- - -## đŸŒ± PrĂ©ambule — Avis de RĂ©alignement CRB-1 - -> **AB-Avis de RĂ©alignement 25-10-2025 / Cycle de RĂ©alignement BorĂ©al #1** -> Adoption du modĂšle biomimĂ©tique & autopoĂŻĂ©tique comme racine unique de la nomenclature. -> IntĂ©gration du principe **adjacent-only**, de la sĂ©paration **fĂ©dĂ©rĂ© / tenant**, et de la portabilitĂ© intĂ©grale des tenants. -> Ce document remplace la version 2 et devient la **rĂ©fĂ©rence vivante** pour tous les artefacts, registres et pipelines. - ---- - -## 🧬 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 :** - -``` -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 partagent un espace d’adressage cohĂ©rent (10.0.0.0/8). - -### 4.2 RĂ©partition logique des espaces - -``` -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) -172.16.0.0/12 → Espace fĂ©dĂ©ratif inter-membres -``` - -### 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 - -### 5.1 Forme gĂ©nĂ©rale - -``` -...alliance-boreale.ca -``` - -* `` = infra | pivot | t -* `` = ID court (czp, nul, tli
) -* Les tenants utilisent le prĂ©fixe `tXXX`. - -**Exemples :** - -``` -dns-master.infra.czp.alliance-boreale.ca → 10.0.2.10 -keycloak.gov.czp.alliance-boreale.ca → 10.0.3.20 -forgejo.forge.czp.alliance-boreale.ca → 10.0.1.20 -fastapi.pivot.czp.alliance-boreale.ca → 10.0.4.10 -web.t001.czp.alliance-boreale.ca → 10.0.10.1 -db.t001.czp.alliance-boreale.ca → 10.0.10.2 -``` - ---- - -## đŸȘ¶ 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. -3. **DĂ©terminer l’adresse IP** Ă  partir du plan. -4. **Nommer la VM** suivant la syntaxe : - - ``` - -infra--prod- - ``` -5. **CrĂ©er l’entrĂ©e DNS**. -6. **Documenter** dans l’inventaire Ansible et le registre. - -### 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). - ---- - -## 🌐 7. Tables de Correspondance (Extrait) - -| VMID | Couche | Nom VM | IP | DNS | Fonction | -| ----- | :----: | ------------------------------- | --------- | -------------------------- | -------------------------- | -| 02001 | C2 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | DNS maĂźtre | -| 03010 | C3 | czp-infra-idp-keycloak-prod-01 | 10.0.3.20 | keycloak.gov.czp.ab.ca | IdentitĂ© fĂ©dĂ©rĂ©e | -| 04021 | C4 | czp-infra-forgejo-git-prod-01 | 10.0.1.20 | forgejo.forge.czp.ab.ca | Forge mutualisĂ©e | -| 05011 | C5 | czp-infra-fastapi-pivot-prod-01 | 10.0.4.10 | fastapi.pivot.czp.ab.ca | Portail & API | -| 10011 | C6 | czp-t001-backend-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | Backend tenant 001 | -| 10021 | C6 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | Base de donnĂ©es tenant 001 | - ---- - -## 📜 8. ΔLog — ItĂ©ration CRB-1 (25-10-2025) - -* **Refonte totale** de la nomenclature v2 → v3. -* Adoption du modĂšle biomimĂ©tique/autopoĂŻĂ©tique. -* Ajout du principe **adjacent-only**. -* Reclassement des services : - - * Ansible → C3, Forgejo → C4, FastAPI → C5. -* Ajout de la mĂ©taphore organique (flux ascendants/descendants). -* Simplification du plan d’adressage. -* Nouvelles tables de correspondance. -* Introduction de la notion d’**ensemencement** (plutĂŽt que crĂ©ation). - ---- - -## 🌌 9. Signature BorĂ©ale - -> *Sous la voĂ»te numĂ©rique, chaque bit est une graine.* -> *Chaque grappe de VM est un organe, chaque tenant une espĂšce.* -> *La forĂȘt se rĂ©gĂ©nĂšre, la fĂ©dĂ©ration veille, la conscience apprend.* -> *Ainsi pousse l’Alliance BorĂ©ale, autopoĂŻĂ©tique et libre.* - ---- - -**Fin du document — RĂ©fĂ©rence vivante v3 (2025-10-25)** -📁 ce fichier sert de base Ă  la Nomenclature, aux pipelines et au Label de Prestige. diff --git a/docs/00_Nomenclature_v4.md b/docs/00_Nomenclature_v4.md new file mode 100644 index 0000000..e874397 --- /dev/null +++ b/docs/00_Nomenclature_v4.md @@ -0,0 +1,704 @@ +# đŸŒČ 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** : `..` (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) + +``` +.. +``` + +**OĂč :** +* `` = nom du service (ns1, git, sso, pivot, etc.) +* `` = infra | tenants | public (optionnel) +* `` = 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 : + +``` +---- +``` + +**OĂč :** +* `` = slug court (clp, nul, tli) +* `` = infra | tenant +* `` = dns-master, keycloak, forgejo, backend, db, etc. +* `` = prod | staging | dev +* `` = 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) : + + ``` + -infra--prod- + ``` + +5. **CrĂ©er l'entrĂ©e DNS** (Section 5.3) : + + ``` + .infra. + ``` + +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É** : `...alliance-boreale.ca` + - ✅ **NOUVEAU** : `..` + - ✅ Exemples concrets : `ns1.infra.chezlepro.ca` au lieu de `dns-master.infra.czp.alliance-boreale.ca` + - ✅ Convention VM : `----` + +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)**