Daniel Allaire
b7c06755dd
`etat: planifie` etait l'heritage du modele : `flotte-creer` ne cree que les hotes ACTIFS, donc le deploiement n'aurait fabrique aucune machine. Passer a `actif` est la declaration d'intention — « je veux que cette machine existe » — et c'est le seul geste qui la transforme en VM. L'inventaire regenere ne porte plus que trois integrations : client_backup, client_pki, client_unbound. `client_journal` et `client_metrique` sont tombes d'eux-memes — patient 0 n'a ni Loki ni Prometheus, et le moteur sait desormais qu'une integration universelle sans service central n'a personne a qui parler. Dependances causales : OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| inventories/production | ||
| plan | ||
| .gitignore | ||
| cle-publique-sauvegarde.txt | ||
| parente.yml | ||
| README.md | ||
OPS-Patient0 — l'écosystème d'origine
Pour qui : l'exploitant de la lignée. Ce dépôt est le plan d'un écosystème Set-OPS comme les autres — mais de celui dont les autres descendent.
Ce qu'il est
Patient 0 est le plus petit écosystème complet : PKI, DNS, edge, courriel, PostgreSQL, et une forge. Six machines. Sa raison d'être tient en une phrase :
porter les dépôts qui fabriquent les écosystèmes, et les servir à ses enfants.
Aujourd'hui, ce rôle est tenu par eregion.chezlepro.ca — une machine hors flotte,
montée à la main, que Set-OPS ne déploie pas, ne sauvegarde pas et ne prouve pas. Tout ce
qui fabrique Chezlepro dépend d'elle. Patient 0 la remplace par un écosystème bâti par
le moteur, sauvegardé par le moteur, vérifié par le harnais. On ne déplace pas le point
unique de défaillance : on l'élimine.
La boucle, et comment elle se casse
Pour rebâtir patient 0, il faut le dépôt du moteur — qui vit sur patient 0. On n'échappe pas à ça par la ruse, mais par le nombre. Le génome doit exister en au moins trois endroits vivants, sans coordination :
patient 0 (la forge mère) · le poste de l'exploitant · restic hors cluster
+ chaque écosystème enfant, qui en porte un miroir
N'importe quel survivant réamorce les autres. Une famille, pas un maître.
Ce que ce dépôt contient, et ce qu'il ne contiendra jamais
plan/ |
les six machines, leurs zones, leurs applications |
inventories/production/group_vars/ |
les intrants, le placement Proxmox, le gabarit de voûte |
inventories/production/hosts.yml |
généré depuis le plan — ne jamais l'éditer à la main |
| le mot de passe de la voûte | jamais. Ni ici, ni dans aucun dépôt : c'est le seul objet que la reproduction exige d'un humain |
Deux réglages à connaître
index: 29 — tout l'adressage en dérive (10.29.0.0/16, VLAN 1291-1296). Choisi
libre : 13 est le lab, 17 Chezlepro, 23 Technolibre. Les index bas (1, 11) ont déjà forcé
deux renumérotages, ils tombaient dans des plages occupées par du matériel.
federe: false — patient 0 est exclu des devis du site tant qu'il n'est pas
matérialisé : ni la frontière, ni le SDN, ni le pare-feu de l'hyperviseur ne lui réservent
quoi que ce soit. C'est délibéré et temporaire. À basculer à true le jour où on le
déploie, avant make sdn-appliquer — sinon ses zones n'existeront nulle part.
Ce qui reste à faire avant de le matérialiser
- Décider où il vit. Sur
asgard, la perte du cluster emporte patient 0 et Chezlepro d'un coup. Ailleurs, la famille survit à la perte du cluster. Le déménagement tient en quatre valeurs (group_vars/proxmox.yml) et un symlink. - Créer la voûte réelle :
ansible-vault create inventories/production/group_vars/all/vault.yml, en couvrant les noms du gabarit (vault.yml.example). - Basculer
federe: true, puismake instancier→make instancier-appliquer. make placement-plan— confronter les quatre valeurs au cluster avant de cloner quoi que ce soit : quarante minutes de déploiement ne se rattrapent pas.- Déployer, puis y pousser les quatre dépôts du génome (moteur, instances, hébergeur, modèles) et inscrire la parenté de chacun.