Daniel Allaire
a5c9a88f00
Apres les paquets (serveur_cache_site) et le genome (serveur_forge_site), les NOMS.
Meme patron : un installateur, un marqueur.
CE QUE CA CORRIGE, mesure sur infra-pki-01, premiere machine a porter l autorite
de Chezlepro :
DNS BLOQUE un tenant resout chez lui, sa requete ne sort pas
443 sortant OK par adresse
apt via le cache OK le mandataire resout a sa place
apt s en sortait ; TOUT LE RESTE ETAIT AVEUGLE AUX NOMS. Versionner la cle de
signature Smallstep a fait passer une tache et l echec s est deplace d un cran : le
depot lui-meme devait etre joint par son nom.
POURQUOI PAS L UNBOUND DE LA FRONTIERE : il tourne sur le boitier sans etre un
service gere, et le plan du site l avait deja ecrit une fois — un processus n est
pas un service. site-dns-01 est deploye par le moteur et verifie par le harnais.
OU VIT LA DERIVATION : dans site_inventaire.py, qui connait le plan du site ET le
registre des tenants. Le role tourne sur une machine qui n a aucune raison de lire
la carte de l hebergeur — la derivation appartient a qui detient les deux sources.
PIEGE DE FILTRE, ATTRAPE EN LE BRANCHANT : _supernets_voisins() EXCLUT l instance
montee (personne n est son propre voisin). Le site sert TOUS ceux qu il heberge — y
compris celui qu on deploie. Reutilise tel quel, il privait de resolution le seul
tenant en cours de montage. On reutilise donc la DECOUVERTE partagee sans son
filtre : deux recensements divergent, deux filtres non.
Le marqueur verifie deux choses : que le resolveur ECOUTE, et que sa liste
d autorisation ADMET reellement les tenants. Sans la seconde, la panne chez le
locataire ressemblerait a un DNS mort alors que c est une ACL.
make verifier : vert. make prouver : CONFORME, 55 OK, 0 echec, 0 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
99 lines
4.3 KiB
YAML
99 lines
4.3 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
|
|
# Le resolveur du site, meme nature : prete aux locataires pendant leur jeunesse.
|
|
- serveur_resolveur_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
|