Daniel Allaire
665b07ba82
Some checks are pending
verifier / verifier (push) Waiting to run
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>
75 lines
2.8 KiB
YAML
75 lines
2.8 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
|
|
|
|
- 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
|
|
|
|
- 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
|