Inventaire mesure de ce qu'une reconstruction de tenant telecharge — ~1,5 Gio :
Nextcloud 230 Mio, image collabora/code 471 Mio (Docker Hub), Keycloak 140,
Forgejo 101, oauth2-proxy 18, plus les paquets apt (Debian + Grafana +
smallstep + Icinga) sur 14 hotes.
Les quatre archives sont EPINGLEES EN VERSION et vont chacune sur UN SEUL
hote. Les retelecharger a chaque reconstruction est un gaspillage et une
dependance de plus sur le chemin critique — un serveur tiers lent a deja fait
tomber un deploiement le 2026-08-09, sur le binaire Forgejo precisement.
POURQUOI POUSSER PLUTOT QUE SERVIR UN CACHE. L'exploitant proposait son poste
comme cache HTTP ; l'intention est juste mais elle butait sur ce qu'on avait
ferme le matin meme : les regles sortantes visent !SETOPS_INTERNES, donc une
VM de tenant ne peut plus atteindre le poste. Servir un cache aurait exige de
ROUVRIR un flux vers le plan d'administration.
L'inversion evite le probleme entier : le controleur telecharge dans son cache
(~/.cache/setops, garde par un stat), puis pousse par le canal SSH qui existe
deja. Aucun port, aucun service, aucune regle, aucun couplage. Et ces
artefacts deviennent deployables HORS LIGNE une fois le cache rempli.
Ce que ca ne couvre pas, et qu'il faut nommer : l'image collabora/code, seule
entorse a la doctrine « zero Docker » du depot — elle merite sa propre
decision, pas un contournement discret ; et les paquets apt, dont le cache a
sa place cote HEBERGEUR, partage entre tenants.
Et une mesure qui a contredit mon hypothese : le .zip de Nextcloud pese
271 Mio contre 230 pour le .tar.bz2. Il telecharge PLUS pour decompresser
moins lentement. Le changement de format attend une mesure, pas une intuition.
Verifie : cache rempli (491 Mio, 4/4), ansible-lint production sur 79 fichiers,
prouver.py 35 OK, plus aucun get_url n'ecrit sur la cible.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recensement apres l'echec du passage d'idempotence : 9 get_url sans aucune
garde, 1 avec.
Les quatre artefacts epingles (forgejo, keycloak, nextcloud, oauth2-proxy)
sont immuables PAR CONSTRUCTION — leur chemin de destination porte la version.
Les retelecharger n'a aucun sens, les recontacter encore moins. Gardes par une
verification d'existence.
Restent cinq cles de signature apt et un trousseau .deb, recuperes a chaque
passage : cinq serveurs externes x quatorze hotes = 70 allers-retours par
deploiement. Les garder supprimerait la dependance au prix de ne plus detecter
une rotation ; une cle tournee casse apt bruyamment, donc l'oubli se voit.
Arbitrage a rendre — pas a moi.
Sur une plateforme souveraine la question merite d'etre posee : combien de
serveurs tiers doivent etre joignables pour redeployer ce qu'on possede deja ?
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
