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>
81 lines
3.9 KiB
YAML
81 lines
3.9 KiB
YAML
---
|
|
# LE POSTE D'EXPLOITATION — la machine depuis laquelle l'écosystème se reconstruit.
|
|
#
|
|
# Jusqu'ici, Set-OPS ne s'exécutait que depuis le poste de son mainteneur. L'écosystème
|
|
# détenait donc la recette (le génome, sur sa forge) sans que personne, chez lui, ne
|
|
# sache la lire à voix haute. `serveur_ops` est la cuisine : ansible, le génome cloné
|
|
# depuis SA PROPRE forge, et de quoi rejouer le moteur.
|
|
#
|
|
# CE QU'IL N'EMPORTE PAS, ET NE DOIT PAS EMPORTER : le mot de passe de la voûte. Il est
|
|
# saisi à l'exécution. Une machine qui détient à la fois le plan, l'accès SSH à la flotte
|
|
# et la clé des secrets n'a plus aucune profondeur : sa compromission est celle de tout
|
|
# l'écosystème. Voir README.md du rôle.
|
|
|
|
serveur_ops_utilisateur: "setops"
|
|
serveur_ops_racine: "/opt/setops"
|
|
serveur_ops_venv: "{{ serveur_ops_racine }}/venv"
|
|
|
|
# Paquets du poste. `make` parce que l'interface opérateur de Set-OPS est un Makefile ;
|
|
# `git` parce que le génome vit dans des dépôts ; `rsync` pour les transferts de fichiers
|
|
# d'Ansible sur les gros arbres.
|
|
serveur_ops_paquets:
|
|
- git
|
|
- make
|
|
- python3-venv
|
|
- python3-pip
|
|
- openssh-client
|
|
- rsync
|
|
- ca-certificates
|
|
|
|
# Ansible est ÉPINGLÉ sur la même famille que le poste du mainteneur (core 2.18) : un
|
|
# écosystème qui se reconstruit avec une version différente de celle qui l'a construit ne
|
|
# reproduit pas la même chose, et l'écart ne se voit qu'au premier échec.
|
|
serveur_ops_ansible: "ansible-core>=2.18,<2.19"
|
|
|
|
# --- D'OÙ VIENT LE GÉNOME ----------------------------------------------------
|
|
#
|
|
# DE SA PROPRE FORGE, pas de l'amont. C'est tout l'objet des miroirs : la forge de
|
|
# l'écosystème détient une copie vivante du génome, resynchronisée toutes les huit
|
|
# heures. Le poste d'exploitation lit CETTE copie — l'écosystème se reconstruit donc
|
|
# depuis lui-même, et non depuis son parent.
|
|
#
|
|
# Dérivé du groupe `serveur_forgejo` de l'inventaire. Surchargeable pour une forge
|
|
# externe au plan.
|
|
serveur_ops_forge_hote: >-
|
|
{{ (groups['serveur_forgejo'] | default([]) | first | default('')) }}
|
|
serveur_ops_forge_url: >-
|
|
https://forge.{{ domaine_interne }}
|
|
serveur_ops_forge_organisation: "genome"
|
|
|
|
# Les dépôts du génome, et où ils atterrissent. Les noms sont ceux que la forge porte
|
|
# (minuscules) ; les destinations reprennent la disposition du poste du mainteneur, où
|
|
# le moteur et les instances sont des dossiers frères — c'est cette fraternité que
|
|
# `scripts/instances.py` découvre.
|
|
serveur_ops_depots:
|
|
- { depot: "set-ops-public", dest: "Set-OPS-public", role: "moteur" }
|
|
- { depot: "ops-patient0", dest: "OPS-Patient0", role: "instance" }
|
|
|
|
# L'instance que le poste pilote par défaut (symlink `instance` du moteur).
|
|
serveur_ops_instance: "OPS-Patient0"
|
|
|
|
# --- CLÉ SSH DU POSTE --------------------------------------------------------
|
|
#
|
|
# Le poste a besoin d'atteindre toute la flotte en SSH. Il se fabrique donc sa PROPRE
|
|
# paire, distincte de celle du mainteneur : deux exploitants, deux clés, deux révocations
|
|
# possibles. La clé publique produite doit être autorisée sur la flotte — le rôle
|
|
# l'affiche et l'écrit dans un fichier prévu pour être repris au plan (voir README).
|
|
serveur_ops_cle_type: "ed25519"
|
|
serveur_ops_cle_generer: true
|
|
|
|
# --- CACHE DES COLLECTIONS (côté CONTRÔLEUR) ---------------------------------
|
|
#
|
|
# Le poste ne va PAS chercher ses collections sur galaxy.ansible.com : la frontière ne
|
|
# laisse pas passer ce flux, et ouvrir une règle vers un serveur étranger pour qu'un
|
|
# écosystème sache se reconstruire serait la mauvaise réponse. Le contrôleur télécharge
|
|
# une fois dans son cache, puis pousse par SSH — même idiome que `serveur_forgejo`
|
|
# devant son propre tiers.
|
|
#
|
|
# Effet de bord recherché : le poste devient déployable **hors ligne**.
|
|
serveur_ops_cache_collections: >-
|
|
{{ (setops_cache_artefacts | default(lookup('env', 'HOME') + '/.cache/setops')) }}/collections
|
|
serveur_ops_requirements_controleur: "{{ playbook_dir }}/../../requirements.yml"
|