Daniel Allaire
ac85278366
La refonte de ce matin posait une convention. Une convention qu'on n'outille pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique au corpus documentaire. Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32 autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus utile du depot au §6 de autorisation.md. Les 38 le declarent desormais, lecteur determine document par document et non colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie, gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE). Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la premiere page ajoutee : un document qui s'annonce genere, et un fragment sans titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation dans leur corps — d'etre exemptes a tort. Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en nommant deux documents que mon inventaire avait manques (docs/audit/). Puis test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la nommant ; restauree -> OK. Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en revue ; elle garantit qu'on a du y penser. P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md annoncaient encore 30 preuves). Verifie : prouver.py 0 (34 OK), plan-recette inchange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
99 lines
4.6 KiB
Markdown
99 lines
4.6 KiB
Markdown
|
||
# Intégrations des VM
|
||
|
||
> **Pour qui :** le **mainteneur** qui ajoute une intégration à toutes les VM.
|
||
|
||
## Politique : le défaut est « oui », l'exception se justifie
|
||
|
||
Une intégration est de l'un des deux genres, et ils ne se déclarent pas au même endroit.
|
||
|
||
**Universelle** — supervision, journaux, PKI. Il n'y a aucun choix de cible : un seul
|
||
Prometheus, un seul Loki, une seule AC. Elle est déclarée **une fois, par le rôle**, dans
|
||
`roles/<role>/meta/integration.yml`, et tout hôte la reçoit :
|
||
|
||
```yaml
|
||
integration:
|
||
universelle: true
|
||
raison: "Tout hôte est mesuré. Une machine hors supervision tombe sans que personne ne l'apprenne."
|
||
sauf_role: serveur_step_ca # facultatif — voir « exemptions »
|
||
```
|
||
|
||
**Facultative** — `client_backup`, `client_smtp`, `client_unbound`. Là il y a un vrai choix,
|
||
et il se déclare par serveur, dans `plan/serveurs.yml : integrations`.
|
||
|
||
**Pourquoi cette inversion.** Le plan portait 57 lignes d'intégration écrites à la main. 28
|
||
d'entre elles disaient oui à quelque chose de vrai pour tous les hôtes — elles n'existaient
|
||
donc que pour être oubliées, et quatre l'avaient été : deux serveurs n'étaient ni supervisés,
|
||
ni journalisés, ni certifiés. Personne ne l'aurait su, puisqu'une machine non supervisée ne
|
||
proteste pas. Depuis, oublier est impossible : il faut **exempter**, et dire pourquoi.
|
||
|
||
Le plan **refuse** désormais une recopie (`valider_serveurs`). Deux sources finiraient par
|
||
diverger, et surtout : l'absence de `client_metrique` en face d'un serveur se lirait
|
||
« non supervisé » alors qu'il l'est.
|
||
|
||
### Les exemptions se dérivent du service rendu
|
||
|
||
Une exemption ne nomme jamais un hôte. Elle nomme le **rôle serveur** dont la présence la
|
||
justifie : `sauf_role: serveur_step_ca` retire `client_pki` à l'hôte qui *est* l'AC — elle ne
|
||
s'enrôle pas auprès d'elle-même. Déplacez step-ca sur une autre machine et l'exemption suit,
|
||
sans qu'on y touche.
|
||
|
||
**P26** garde les deux côtés : aucun hôte sans intégration universelle, aucune recopie dans le
|
||
plan.
|
||
|
||
### Ce que le panneau montre
|
||
|
||
Dans la **fiche d'un serveur**, les universelles apparaissent en ✓ **non décochables**, les
|
||
exemptions barrées, avec leur raison en infobulle. Sans cet affichage, un plan devenu
|
||
silencieux se lirait comme une flotte non supervisée — l'inverse exact de la vérité.
|
||
|
||
La vue **Intégrations** donne l'autre axe : une **matrice serveurs × intégrations**. Colonnes
|
||
✓ pour la politique, `—` barré pour les exemptions, cases à cocher pour les facultatives —
|
||
éditables sur place, puis *Sauvegarder*. La ligne **couverture** affiche `n/N` par colonne.
|
||
|
||
Elle **ne juge pas** : `7/14` sur `client_backup` peut être exactement juste. Elle rend le
|
||
motif visible, ce que quatorze fiches consultées une par une ne faisaient pas — c'est
|
||
précisément pour ça que le trou de Chezlepro est resté invisible jusqu'à ce qu'un devis de
|
||
pare-feu l'énumère.
|
||
|
||
---
|
||
|
||
## Séparation
|
||
|
||
```text
|
||
Template Debian 13 Proxmox : socle commun minimal
|
||
Cloud-init : identité initiale du clone
|
||
Set-OPS + Ansible : configuration réelle du serveur
|
||
```
|
||
|
||
Le template ne doit pas être modifié pour chaque nouveau serveur. Les intégrations sont appliquées après clonage selon les groupes d'inventaire et les playbooks dédiés.
|
||
|
||
## Domaines prévus
|
||
|
||
```text
|
||
DNS interne : PowerDNS, résolveurs, enregistrements applicatifs
|
||
PKI interne : step-ca, ACME, confiance CA locale
|
||
Identité : LDAP, SSSD, Keycloak/OIDC selon le besoin
|
||
Supervision : Icinga2 agent ou checks distants
|
||
Métriques : Prometheus node_exporter
|
||
Visualisation : Grafana côté plateforme centrale
|
||
```
|
||
|
||
## Principes Ansible
|
||
|
||
- Un rôle d'intégration doit être **inoffensif hors de son groupe** : c'est l'appartenance au groupe qui l'active, jamais un drapeau recopié. (Ce principe disait autrefois « désactivé par défaut », à l'époque où les serveurs centraux n'existaient pas ; depuis, trois intégrations sont universelles — voir §Politique.)
|
||
- Chaque variable de rôle doit utiliser le préfixe du rôle.
|
||
- Les secrets ne doivent jamais être stockés en clair dans le dépôt.
|
||
- Un rôle ne doit pas échouer si son intégration est désactivée.
|
||
- Les playbooks applicatifs doivent être appliqués sur les clones, pas sur le template.
|
||
- Les opérations pouvant couper l'accès réseau ou SSH doivent exiger une confirmation explicite.
|
||
|
||
## Ordre logique de construction
|
||
|
||
1. DNS interne.
|
||
2. PKI interne et confiance CA.
|
||
3. Identité système et applicative.
|
||
4. Supervision et métriques.
|
||
5. Visualisation et alerting.
|
||
|
||
Cet ordre reste indicatif. Les rôles doivent rester découplés pour permettre une adoption progressive.
|