Daniel Allaire
2b55761fba
La ligne de partage est celle des voutes. serveur_ops calcule et configure -- voute du tenant, SSH chez lui. serveur_ops_site materialise -- voute du SITE, API de l'hyperviseur, jamais de SSH chez un tenant. Un runner par tenant qui materialiserait mettrait la voute du SITE en N exemplaires. Un runner unique qui ferait tout traverserait le default-deny inter-tenant et rendrait l'emancipation impossible. Le role depose la voute CHIFFREE et relit l'en-tete apres avoir ecrit : sans `decrypt: false`, Ansible dechiffre la source quand il detient le mot de passe -- constate le jour meme, 776 octets en clair au lieu de 3465. Controle negatif fait, la garde mord. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
82 lines
3.2 KiB
YAML
82 lines
3.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
|
|
- 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_unbound
|
|
- client_artefacts
|