Daniel Allaire
fa7e656844
Une regle inter-tenant n'appartient ni a l'emetteur ni au recepteur : c'est le site qui autorise un flux entre deux de ses tenants, et son runner qui prepare le terrain. Deux silences fermes dans le generateur de frontiere. flux_frontiere() ne retenait que les flux `externe` -- or deux tenants vivent sur des VLAN routes par la frontiere, leur trafic la traverse. Et un egress vers un voisin recevait !SETOPS_INTERNES en destination : le port ouvert vers l'INTERNET. La destination est desormais nommee. Deux roles parce que meta/flux.yml est statique : un role unique aurait declare l'ingress pour TOUS les caches -- maillage complet, visible au devis. serveur_artefacts_site porte l'ingress, serveur_artefacts l'egress vers l'amont. Debian est desormais telecharge une fois pour toute la fabric. Le cache du site ne voit que des requetes agregees, jamais quelle machine installe quoi. Rien n'est applique : le devis se lit avant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
56 lines
2.3 KiB
Markdown
56 lines
2.3 KiB
Markdown
# serveur_artefacts_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.
|