nas-runbooks/common/fragilites-dependances-stack-20260703.md

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).