Daniel Allaire
58ce3dfea4
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
97 lines
4.2 KiB
YAML
97 lines
4.2 KiB
YAML
---
|
|
# 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
|
|
# 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
|
|
- serveur_redis
|
|
- serveur_prometheus
|
|
- serveur_loki
|
|
- serveur_nginx
|
|
- serveur_rspamd
|
|
- serveur_dovecot
|
|
- serveur_postfix
|
|
- serveur_backup
|
|
# 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
|
|
# 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
|
|
# 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
|
|
- 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
|
|
# Le poste d'exploitation vient APRES la forge : il clone le genome depuis
|
|
# elle. Le placer plus tot le laisserait sans source.
|
|
- serveur_ops
|
|
# 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
|
|
# 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
|
|
|
|
- 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
|
|
- client_resolveur
|
|
- client_artefacts
|