Déploiement Docker — Version exécutable avec page d’accueil

Ce qui est déployable maintenant

Cette archive contient un docker-compose.yml à la racine.

La version actuelle ajoute une page d’accueil dédiée à la racine du site.

Routes exposées

/             -> page d’accueil DataLab0
/workspace/   -> interface workspace actuelle, ancien prototype index.html
/doc.html     -> portail documentaire HTML
/doc/         -> documentation Markdown
/viewer/      -> viewer placeholder séparé
/api/health   -> API placeholder

Changement v1.1 : page d’accueil

Avant cette évolution, le prototype workspace était directement exposé à la racine /.

Désormais :

• / affiche une page d’accueil DataLab0 ;
• le bouton Rejoindre l’interface redirige vers /workspace/ ;
• le bouton Ouvrir la documentation redirige vers /doc.html ;
• l’interface workspace existante reste inchangée dans apps/workspace-web/index.html.

La page d’accueil utilise le même langage visuel que le workspace :

• police Inter ;
• sidebar sombre ;
• gradients bleus/violets ;
• cartes glass/acrylic ;
• boutons arrondis ;
• palette #0d1f35, #7357ff, #5d46f0.

Rôle du reverse proxy

Le container reverse-proxy sert maintenant :

• la page / directement depuis son image Nginx ;
• doc.html et /doc/ directement depuis son image Nginx ;
• /workspace/ en proxy vers workspace-web ;
• /viewer/ en proxy vers viewer-web ;
• /api/ en proxy vers api.

Le contexte de build du reverse proxy est donc la racine du projet afin de copier :

infra/docker/nginx/default.conf
infra/docker/nginx/static/index.html
doc.html
doc/

Commandes Docker

Depuis la racine de l’archive :

docker compose up --build -d

Arrêt :

docker compose down

Suppression des volumes :

docker compose down -v

Rebuild du reverse proxy seul après changement de page d’accueil ou documentation :

docker compose up -d --build reverse-proxy

Containers inclus

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

Fonctionnel maintenant

• page d’accueil DataLab0 ;
• accès à l’interface workspace via /workspace/ ;
• accès à la documentation via /doc.html ;
• service statique du prototype workspace ;
• reverse proxy ;
• viewer placeholder séparé ;
• API healthcheck ;
• containers worker/scheduler placeholders ;
• PostgreSQL ;
• Redis ;
• MinIO.

Préparé mais pas encore implémenté métier

• backend complet ;
• publication Draft/Published ;
• jobs BI réels ;
• scheduler métier réel ;
• connexion effective du prototype à l’API ;
• séparation réelle worker-dev / worker-viewer ;
• query engine ;
• permissions backend ;
• dependency graph persistant.

Pourquoi cette étape

On passe d’une archive architecture/documentation à une archive réellement lançable sur serveur, avec une entrée utilisateur plus propre.

La racine / devient une porte d’entrée claire, tandis que le prototype workspace reste accessible et isolé sur /workspace/.