Nomenclature réalignée selon le gros bon sens ;-)
This commit is contained in:
Dan Allaire
parent
0029f80823
commit
51862096bb
2 changed files with 704 additions and 242 deletions
|
|
@ -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
|
||||
|
||||
```
|
||||
<service>.<contexte>.<membre>.alliance-boreale.ca
|
||||
```
|
||||
|
||||
* `<contexte>` = infra | pivot | t<tenant-id>
|
||||
* `<membre>` = 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 :
|
||||
|
||||
```
|
||||
<membre>-infra-<type>-prod-<instance>
|
||||
```
|
||||
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.
|
||||
704
docs/00_Nomenclature_v4.md
Normal file
704
docs/00_Nomenclature_v4.md
Normal file
|
|
@ -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** : `<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)**
|
||||
Loading…
Reference in a new issue