Daniel Allaire
db2d6f6bf0
Mesure avant de decider : ~21 Mo de RSS par VM pour 28 a 189 requetes servies. Le gain de cache est negligeable ; ce qu'on recupere, c'est un demon au lieu de cinq et un endroit a regarder au lieu de cinq. Pas sur la frontiere : un resolveur de SITE devrait connaitre la zone interne de chaque tenant, et un tenant dont le resolveur vit chez l'hebergeur ne peut plus s'emanciper avec. La recursion est generique, la zone interne ne l'est pas. L'autoritatif se replie sur 127.0.0.1:5300 -- derive de la colocalisation, pas declare a la main. Son port devient `derive` dans meta/flux.yml : les deux lient 53 mais sur des adresses differentes. Deux pieges. Unbound refuse d'interroger une loopback par defaut : sans lever do-not-query-localhost, toute la zone rendait SERVFAIL. Et le plancher /etc/hosts MASQUAIT la panne -- getent repondait, dig disait SERVFAIL. La tache de validation du role avait raison contre moi. client_unbound n'installant plus Unbound, son nom mentait : client_resolveur. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
85 lines
3.4 KiB
YAML
85 lines
3.4 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
|
|
|
|
- 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 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
|