From c3ecc8b1890a6b9267cbcece9bfcbb06691f52d9 Mon Sep 17 00:00:00 2001 From: bolbol Date: Fri, 3 Jul 2026 19:59:37 +0000 Subject: [PATCH] docs: analyse fragilites dependances stack 43 containers --- .../fragilites-dependances-stack-20260703.md | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 common/fragilites-dependances-stack-20260703.md diff --git a/common/fragilites-dependances-stack-20260703.md b/common/fragilites-dependances-stack-20260703.md new file mode 100644 index 0000000..7aa5b3a --- /dev/null +++ b/common/fragilites-dependances-stack-20260703.md @@ -0,0 +1,48 @@ +# Fragilites de dependances — stack 43 containers (analyse 03/07/2026) + +Analyse systematique restart-policy / persistance / couplages, croisee avec les pieges deja documentes (allow_all_keys Bifrost, footer DOCX nyora-doc-api, Portainer ID dynamique). Etat REEL via socket Docker. + +## CRITIQUE + +### 1. n8n + n8n-DB en restart=on-failure +Ne redemarrent PAS apres un arret systeme / coupure courant (Docker ne relance au boot que `always` et `unless-stopped` ; `on-failure` ne re-tente qu'apres un crash pendant que le demon tourne). n8n = orchestration centrale (veille, ingestion, routing LLM). Apres coupure EDF Sfax -> toute l'automatisation reste DOWN jusqu'a intervention manuelle. +FIX : passer n8n ET n8n-DB en `restart: unless-stopped` (compose n8n) + recreate. Aucun changement d'image. + +### 2. rla-api pointe vers des services MORTS (couplage casse silencieux) +Env rla-api : `GOTENBERG_URL` -> port 3001 (= pihole aujourd'hui, repond 403) et `PPTX_API_URL` -> 8015 (mort, 000). Ces deux services ont ete desinstalles (21/06 et 29/06). Toute generation PDF/PPTX des 55 contrats RLA echoue silencieusement. +FIX : repointer rla-api vers nyora-doc-api (port 3050) qui remplace tout l'ancien stack doc. Mettre a jour les 2 variables d'env + recreate. Verifier le format d'appel attendu par nyora-doc-api. + +## ELEVE + +### 3. reglement-definitif-api : restart=no + image locale + 0 mount + 0 env +Ne remonte jamais automatiquement (ni au boot, ni apres crash). Image `reglement-definitif:latest` construite localement (pas de registry -> irrecuperable si supprimee). 0 env visible = configuration entierement bakee dans l'image (fragile, non auditable). API metier TT. +FIX : `restart: unless-stopped` ; verifier que le Dockerfile source est versionne sur Gitea ; documenter la config (actuellement opaque). + +### 4. Trilium en restart=no +Notes personnelles ; ne remonte pas au boot. FIX : `unless-stopped`. + +### 5. Images construites localement sans registry (irrecuperables si prune -a) +rla-api, reglement-definitif, dashboard-terrain, nyora-doc-api, family-help, context-hub, gsparc-mezzouna, nyora-veille, panda-dashboard : images locales sans tag registry. Un `docker image prune -a` (ou un prune agressif) les supprime DEFINITIVEMENT — reconstruction possible seulement si le Dockerfile source existe encore. Le protocole Hermes recommande un prune regulier (builds :latest empilent du GB) -> danger reel de supprimer une image metier. +FIX : (a) versionner TOUS les Dockerfiles sur Gitea (backup source) ; (b) ne jamais utiliser `prune -a`, seulement `prune` (dangling) ; (c) idealement pousser les images critiques sur le registry Gitea. + +## MOYEN + +### 6. bifrost-proxy sans healthcheck +Maillon auth-rewrite + cap 16384 tokens devant Bifrost ; tout Hermes + n8n passe par lui. S'il fige (up mais non-repondant), rien ne le detecte ni le relance. FIX : ajouter un healthcheck (curl interne) au compose bifrost-proxy. + +### 7. Services critiques sans healthcheck (up-but-broken indetectable) +family-help, redaction-pro, context-hub, veille-backend/frontend, hermes-mail-proxy, dashboard-terrain, rla-api, reglement-definitif-api. FIX : ajouter healthcheck HTTP simple par service (progressif, non urgent). + +### 8. rla-api isole sur reseau bridge +Appele via 172.17.0.1:3005 (IP host bridge). Ne peut pas joindre les autres services par nom Docker. Fonctionnel mais fragile. FIX (optionnel) : rattacher au reseau `n8n`. + +## VERIFIE SAIN (contrairement aux apparences) +- **Bifrost allow_all_keys=1** actif sur toutes les VK/providers ET config.db bien monte dans /app/data -> le fix SURVIT au recreate. Seul vecteur de perte = editer via l'UI Bifrost (deja documente : bifrost-access.md, OPENCODE-GO-MIGRATION.md). Pas de nouvel equivalent DB cache trouve ailleurs. +- **hermes-workspace-* : 0 mount = sandbox jetable BY DESIGN** (l'etat — soul.md, skills, memory — vit dans les hermes-agent-* qui montent /opt/data). Normal, pas une fuite. +- **watchtower-nas en MONITOR_ONLY=true** : notifie mais n'update PAS automatiquement -> pas de risque de rupture surprise sur les :latest. +- **veille-frontend / dashboard-terrain / panda-dashboard** : frontends statiques stateless, 0 mount normal. + +## Methode / pieges d'analyse +- restart policy au boot systeme : seuls `always` + `unless-stopped` remontent. `on-failure` et `no` = NON. +- 0 mount /volume1 = etat ephemere au recreate SAUF si le service est stateless (frontend, sandbox, ou lit un backend externe comme Baserow). +- Chercher les couplages casses : comparer les URL/ports en env de chaque service au registre reel des services vivants (rla-api etait le cas).