2026-07-07 03:08:09 -04:00
---
# Couches de déploiement — l'ordre de reconstruction de l'écosystème.
#
# Registre central (comme docs/dependances-groupes.yml). L'orchestrateur
# (scripts/orchestrer.py → make site) trie les groupes déployables par COUCHE
# (clé primaire, ordre ci-dessous), puis AFFINE l'ordre INTRA-couche avec le
# graphe des dépendances (dependances-groupes.yml, ex. dovecot avant postfix).
#
# Règle : chaque groupe déployable (= un playbooks/groupes/<groupe>.yml
# opérationnel) DOIT figurer dans exactement une couche. Le générateur refuse
# sinon (garde anti-dérive : un nouveau rôle non classé casse la génération).
#
# Règle de cohérence : un prérequis (dependances-groupes.yml) doit vivre dans
# une couche <= celle du groupe qui en dépend. Une arête « en arrière » (un
# groupe qui requiert un groupe d'une couche PLUS TARDIVE) = mauvaise
# classification → le générateur refuse.
#
# L'ordre des couches ci-dessous EST l'ordre de déploiement.
couches :
- nom : socle
raison : "Base du système : /etc/hosts (résolution interne au bootstrap), paquets, durcissement. Tout en dépend."
groupes :
- serveur_debian
- serveur_durci
- nom : pki_racine
raison : "L'autorité de certification interne (step_ca) : la racine de confiance de tous les flux TLS est-ouest."
groupes :
- serveur_step_ca
- nom : pki_client
raison : "Émission des certificats et pose de la racine (root_ca 0644) sur chaque nœud. Prérequis de TOUT service qui sert ou vérifie du TLS."
groupes :
- client_pki
- nom : services
raison : "Les services d'infrastructure dont dépendent les applications : bases, annuaire, DNS, cache, métriques, journaux, edge, courriel."
groupes :
- serveur_postgresql
- serveur_openldap
- serveur_powerdns
2026-08-24 16:59:34 -04:00
# Le resolveur du tenant vient APRES son autoritatif : il le prend en stub-zone,
# et sa validation exige que la zone souveraine reponde deja.
- serveur_resolveur
2026-07-07 03:08:09 -04:00
- serveur_redis
- serveur_prometheus
- serveur_loki
- serveur_nginx
- serveur_rspamd
- serveur_dovecot
- serveur_postfix
- serveur_backup
2026-08-23 14:41:56 -04:00
# La source d'artefacts vient AVANT ceux qui installent des paquets — c'est tout
# son objet. Placee plus tard, elle serait remplie apres avoir servi.
- serveur_artefacts
2026-08-24 23:11:32 -04:00
# LA RACINE DE LA CHAINE DE CACHES, et elle appartient au SITE, pas au tenant :
# VM du tenant -> cache du tenant -> cache du SITE -> Debian
# Classee ici pour que son ordre soit dit, mais elle ne se deploie pas dans le meme
# mouvement : elle vit dans l'underlay de l'hebergeur et se joint par
# `scripts/site_inventaire.py`. Un tenant ne la deploie jamais — il la CONSOMME.
- serveur_cache_site
forge du site : le marqueur manquant — le genome n etait ouvert a personne
MEME PATRON QUE serveur_artefacts + serveur_cache_site : un installateur, un
marqueur. Le site rend DEUX services a ses locataires pendant leur jeunesse, les
PAQUETS et le GENOME. Le premier etait declare, le second ne l etait pas — alors
que D-81 fait de cette forge l autorite dont tout ecosysteme se reproduit.
Mesure sur ops-01, premiere machine de la reconstruction de Chezlepro :
cache du SITE 10.0.33.21:3142 : OK
forge du SITE 10.0.33.11:443 : BLOQUE
Le plan du tenant declarait pourtant lire son genome a cette adresse. UNE
DEPENDANCE DECLAREE CHEZ LE CONSOMMATEUR, SANS FLUX CHEZ LE FOURNISSEUR — et rien
ne le signalait : la garde de matrice de resoudre_flux ne verifie que les paires
role->role, jamais un pair symbolique comme voisins_site.
POURQUOI UN ROLE A PART : ajouter cet ingress a serveur_forgejo aurait ouvert LA
FORGE DE CHAQUE TENANT a ses voisins. La responsabilite appartient a une machine
precise, pas au logiciel qu elle fait tourner.
Il verifie que la forge ECOUTE vraiment : sans ca il attribuerait l autorite du
genome a un port muet, et l ecosysteme venu s y reproduire attendrait sans savoir
pourquoi — ce qui est exactement arrive, quinze minutes durant.
TROIS GARDES ONT TRAVAILLE : le catalogue a refuse un role qu il ne nomme pas, la
carte a corrige ses deux chiffres, et P49 a exige la regeneration du registre.
P33 a impose partage: true — le marqueur emprunte l ecoute de serveur_forgejo.
Frontiere : 4 objets crees, 0 retire. Verifie depuis ops-01 : 443 OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-08-28 16:15:42 -04:00
# La forge du genome, meme nature : elle vit dans l'underlay de
# l'hebergeur et un tenant la CONSOMME sans jamais la deployer.
- serveur_forge_site
2026-07-07 03:08:09 -04:00
- nom : apps
raison : "Les applications métier, qui consomment les services (base, SSO, courriel, edge)."
groupes :
- serveur_keycloak
- serveur_oauth2_proxy
- serveur_forgejo
- serveur_icinga
- serveur_icingaweb2
- serveur_grafana
- serveur_collabora
- serveur_nextcloud
- serveur_web_frontal
- serveur_web_dorsal
serveur_ops : la difference entre une archive et une matrice
Un ecosysteme pouvait DETENIR son genome sans savoir l'executer. Le poste
d'exploitation porte Ansible epingle, le genome clone depuis SA PROPRE forge, et
une cle SSH qui n'appartient qu'a lui. Il n'emporte ni la voute ni son mot de
passe : la structure se reconstruit depuis la forge, les secrets depuis la
sauvegarde. Deux sources qu'un meme incident n'atteint pas ensemble.
Une machine neuve traverse tout le moteur sans rien heriter, et revele ce qu'un
etat anterieur masquait. Deux defauts silencieux en sont sortis.
setops_plan_dir pointait le lien `instance` en dur : neuf roles lisaient donc le
plan d'une AUTRE instance. Le plancher de patient 0 portait les FQDN de
Chezlepro, et son edge publiait server_name forge.chezlepro.internal. La
variable suit desormais l'inventaire reellement charge.
Trois instances sur quatre declaraient les SAN d'exposition de leur edge ; la
quatrieme et le modele public ne les avaient pas. La forge de patient 0 etait
donc publiee derriere le certificat auto-signe de Debian, sans que rien ne le
signale -- `git clone` fut le premier a refuser, a juste titre. P42 le reclame
maintenant pour tout ecosysteme qui declare un edge.
Le harnais a ecrit la moitie de ce role : 5 echecs sur la piece neuve, aucun
n'empechait le code de tourner, tous la rendaient invisible a la carte, au
graphe et au lecteur. 42 preuves, 0 echec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 11:58:10 -04:00
# Le poste d'exploitation vient APRES la forge : il clone le genome depuis
# elle. Le placer plus tot le laisserait sans source.
- serveur_ops
runner : `serveur_ops_tenant` — le runner d'un tenant recoit enfin sa voute
La doctrine des runners decrit trois portees depuis le 2026-08-22 :
calculer plan -> inventaire aucune voute serveur_ops
configurer roles sur ses machines voute du TENANT <- revendiquee, jamais recue
materialiser creer/detruire des VM voute du SITE serveur_ops_site
La deuxieme ligne etait un trou. RIEN ne deposait jamais la voute d'un tenant sur
son runner. Un runner pouvait deriver son inventaire et ne rien pouvoir en faire :
chaque role qui demande un secret echouait sur son assertion, et l'echec ne disait
pas qu'il manquait un FICHIER, seulement que les valeurs etaient vides.
Decouvert en preparant la reconstruction de Chezlepro. Le runner du SITE peut
materialiser ses quinze machines ; il ne peut pas les configurer, parce que
Chezlepro a sa PROPRE autorite de certification — donc `client_pki` y reclame un
secret de Chezlepro. Le runner du site ne l'a pas, et NE DOIT PAS l'avoir : c'est
la ligne qui rend l'hebergement mutualise defendable.
`serveur_ops_tenant` est le symetrique exact de `serveur_ops_site` : un MARQUEUR,
pas un installateur. Il depose la voute `decrypt: false`, puis RELIT l'en-tete du
fichier depose — une voute dechiffree par accident est une fuite silencieuse. Le
dossier d'inventaire (`principal` ou `production`) se DECOUVRE sur la machine
plutot que d'etre ecrit.
Pourquoi un role a part et non une option de `serveur_ops` : donner sa voute a un
runner est un POUVOIR, pas un reglage. Le declarer au plan force a repondre a
« cette machine a-t-elle le droit de configurer cet ecosysteme ? » — une option
activee par defaut y repondrait a notre place.
CHEZLEPRO LISAIT ENCORE SON GENOME CHEZ PATIENT 0.
Trouve au passage, et bloquant pour la reconstruction : `serveur_ops_forge_amont`
pointait sur `10.29.16.11` — la forge de patient 0, l'amont d'avant que le site
ait la sienne. D-81 a tranche depuis. Laisse tel quel, Chezlepro se serait
reconstruit depuis un moteur perime, sur un reseau que le decoupage en zones a de
toute facon deplace.
Corrige vers la forge du site, PAR SON IP — `forge.genese.internal` appartient a
la zone souveraine du site, et un tenant ne resout que la sienne ; le certificat
SERVI porte bien `IP Address:10.0.33.11`. La racine de l'AC du site est desormais
versionnee a cote de la carte de la fabric a laquelle elle appartient, et son
chemin se DERIVE du symlink `underlay.yml` : il vaut depuis le poste comme depuis
un runner.
Le role est inscrit dans les quatre registres qui l'exigeaient — couches de
deploiement, graphe des dependances, catalogue des services, carte d'orientation.
Ce sont les preuves P08, P38 et P48 qui l'ont reclame, chacune a son tour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 15:30:51 -04:00
# Le runner de TENANT vient APRES le poste : il suppose les depots clones et le lien
# `instance` pose. Il n'ajoute qu'un pouvoir -- celui de CONFIGURER cet ecosysteme,
# par sa voute deposee chiffree.
- serveur_ops_tenant
2026-08-24 15:30:03 -04:00
# Le runner de SITE vient APRES le runner de tenant : il suppose les depots
# clones. Il n'ajoute qu'un pouvoir -- celui de materialiser sur la fabric.
- serveur_ops_site
2026-07-07 03:08:09 -04:00
- nom : agents
raison : "Les intégrations clientes qui expédient vers les services centraux (métriques, journaux, courriel, sauvegardes, résolution locale). Déployées en dernier, quand leurs cibles sont debout."
groupes :
- client_metrique
- client_journal
- client_smtp
- client_backup
2026-08-24 16:59:34 -04:00
- client_resolveur
2026-08-23 14:41:56 -04:00
- client_artefacts
