Daniel Allaire
a1997774be
Devis clos : 0 a creer, 0 a retirer, 65 inchange + 15 routes. Flotte verifiee apres coup -- DNS interne, Internet et apt sans erreur sur les cinq hotes. OPNsense refuse un alias de 32 caracteres ou plus. La contrainte n'etait ecrite nulle part et se manifestait a l'APPLICATION, pas au devis. nom_alias abrege desormais (SERVEUR_ -> SRV_, comme le pare-feu est-ouest) et REFUSE bruyamment si le nom deborde encore : un devis qui promet un objet que la cible rejettera n'est pas un devis. Le role devient serveur_cache_site. « RIEN N'EST APPLIQUE » signifiait « pas encore recharge », pas « rien ecrit » : les objets etaient dans la config, le pare-feu en marche les ignorait. J'avais lu le message a l'envers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
56 lines
2.3 KiB
Markdown
56 lines
2.3 KiB
Markdown
# serveur_cache_site
|
||
|
||
**Le cache d'artefacts du SITE** : celui que les écosystèmes voisins prennent comme amont,
|
||
pour que Debian ne soit téléchargé qu'une fois pour toute la fabric.
|
||
|
||
## Le chaînage
|
||
|
||
```
|
||
VM du tenant → cache du tenant → cache du SITE → Debian
|
||
```
|
||
|
||
Chaque écosystème **garde le sien** — il reste maître de ses paquets et s'en émancipe d'un
|
||
drapeau — mais il ne va plus chercher chez Debian.
|
||
|
||
**Un cache unique où toutes les VM taperaient** aurait demandé un flux de chaque machine
|
||
de chaque tenant vers un hôte d'un autre tenant : N×M chemins à travers le default-deny.
|
||
Avec le chaînage il n'y en a **qu'un par écosystème**, entre deux caches.
|
||
|
||
Et l'étanchéité y gagne : le cache du site ne voit que des requêtes **agrégées**, jamais
|
||
quelle machine installe quoi.
|
||
|
||
## Pourquoi deux rôles plutôt qu'un drapeau
|
||
|
||
Les flux se déclarent dans `meta/flux.yml`, qui est **statique**. Un rôle unique aurait dû
|
||
déclarer l'ingress inter-tenant pour **tous** les caches — et le devis l'a montré :
|
||
|
||
```
|
||
+ TENANT_PATI29 -> CHEZ17_SERVEUR_ARTEFACTS un maillage complet,
|
||
+ TENANT_TECH23 -> CHEZ17_SERVEUR_ARTEFACTS chaque cache acceptant chaque autre
|
||
```
|
||
|
||
Avec la séparation, l'ingress n'existe qu'ici, et un seul cache est joignable.
|
||
|
||
## Qui peut le déclarer
|
||
|
||
**L'écosystème de l'hébergeur**, celui qui exploite la fabric. Un tenant ordinaire qui le
|
||
déclarerait s'offrirait à servir ses voisins sans y être invité.
|
||
|
||
C'est le même patron que `serveur_ops_site` : le **runner de site** prépare le terrain —
|
||
VNets, routes, flux — pour que les plans des tenants tiennent. Aucun écosystème n'ouvre de
|
||
porte chez un autre ; c'est le site qui autorise.
|
||
|
||
## Ce qu'il vérifie
|
||
|
||
**Qu'il ne se chaîne pas lui-même.** Il est le bout de la chaîne : le laisser pointer sur
|
||
un amont ferait tourner les paquets en rond entre deux caches, ou les ferait sortir du site
|
||
sans que personne ne l'ait décidé.
|
||
|
||
**Que le cache écoute vraiment.** Le rôle n'installe rien : sa seule prise sur le réel est
|
||
de vérifier que le service qu'il désigne existe. Sans ça, il attribuerait une
|
||
responsabilité à un port que personne n'écoute.
|
||
|
||
## Ce que ce rôle ne fait pas
|
||
|
||
Il n'installe ni ne configure apt-cacher-ng — c'est `serveur_artefacts`. Il **attribue une
|
||
responsabilité** et la rend lisible dans le plan.
|