Docker et déploiement

Fonctionnel

Le SaaS BI devra pouvoir être mis en production proprement sur serveur, avec isolation des composants critiques.

Docker sert à :

• isoler les responsabilités ;
• éviter qu'un job lourd bloque toute la plateforme ;
• séparer le runtime workspace de développement du runtime viewer publié ;
• scaler certains composants indépendamment ;
• préparer une évolution Kubernetes.

Technique

Containers recommandés au départ

workspace-web
viewer-web
api
worker
scheduler
postgres
redis
minio
reverse-proxy

Rôle des containers

workspace-web

Runtime de développement :

• workspace multi-fenêtres ;
• éditeurs ;
• datasets ;
• pipelines ;
• dashboards en édition.

viewer-web

Runtime de consultation :

• dashboards publiés ;
• filtres ;
• interactions ;
• exports ;
• aucun moteur workspace complet.

api

Backend principal :

• organisations ;
• workspaces ;
• objets BI ;
• permissions ;
• publication ;
• audit ;
• lineage.

worker

Jobs asynchrones :

• imports ;
• refresh ;
• pipelines ;
• exports ;
• transformations.

scheduler

Planification :

• refresh datasets ;
• exports planifiés ;
• alertes ;
• pipelines planifiés.

postgres

Base metadata :

• utilisateurs ;
• organisations ;
• workspaces ;
• datasets ;
• dashboards ;
• permissions ;
• audit ;
• locks.

redis

Cache et coordination :

• sessions ;
• locks ;
• queues simples ;
• présence ;
• cache court.

minio

Object storage compatible S3 :

• fichiers sources ;
• imports ;
• exports ;
• snapshots ;
• previews.

reverse-proxy

Entrée HTTP :

• routage vers workspace/viewer/API ;
• SSL plus tard ;
• headers sécurité.

Règle d’architecture critique

Les ressources de développement et de consommation publiée doivent être séparées.

Une requête qui plante en développement ne doit jamais rendre indisponibles les dashboards publiés.

Phase 1

Docker Compose.

Phase 2

Séparation plus fine :

• worker-dev ;
• worker-viewer ;
• worker-export ;
• worker-pipeline.

Phase 3

Kubernetes / orchestration avancée.