Proposition : Migration dashboard-33800 vers projet GitLab avec CI/CD

Date : 15/02/2026 Contexte : Audit sécurité (36 findings) + demande utilisateur de passer en projet GitLab clean avec CI/CD full automatisé Statut : VALIDÉE (principe) — choix architecture à confirmer

1. État actuel

Ce qu'est le dashboard aujourd'hui

Un ensemble de scripts bash (~150K lignes) qui :

1. Collectent des données via SSH brut sur 8 VMs + 4 APIs HTTP
2. Génèrent 30+ pages HTML statiques via heredocs bash
3. Déploient via git push o2switch main & (en background, sans CI/CD)

Problèmes majeurs

Structure des fichiers actuels

/stock_8to/33800-stack/monitoring/
├── generate.sh              # Orchestrateur principal (77K lignes)
├── collect.sh               # Collecte données
├── collect-gitlab.sh        # Collecte GitLab CI/CD
├── config.json              # Config centrale (hosts, services, deploy)
├── current.json             # Cache données live (regénéré chaque cycle)
├── templates.sh             # Templates HTML réutilisables
├── generate.d/              # 26 modules de génération (1 par page)
│   ├── _common.sh
│   ├── 01-index.sh → 26-claude.sh
├── collect.d/               # 10 modules de collecte
│   ├── _common.sh
│   ├── 01-pve.sh → 09-linkedin.sh
├── audit.d/                 # 9 modules d'audit
├── assets/                  # CSS, JS, SVG
│   ├── style.css (1210 lines)
│   ├── dashboard.css (688 lines, doublon)
│   ├── data-loader.js (142 lines)
│   └── nav.js (44 lines)
├── *.html                   # 30+ pages HTML générées
├── data/current.json        # Symlink pour le JS frontend
├── logs/                    # Logs quotidiens JSON
└── .git/                    # Remotes: origin (GitLab) + o2switch

Sources de données actuelles

Collecte SSH (collect.d/)

APIs HTTP appelées

Credentials dans le code (TOUS à externaliser)

2. Architecture cible

Principe : API backend + SPA frontend, CI/CD full automatisé

┌─────────────────────┐         ┌──────────────────────┐
│    O2switch          │         │   prod-portainer     │
│                      │  HTTPS  │                      │
│  SPA Frontend        │────────►│  Dashboard API       │
│  (HTML/CSS/JS)       │◄────────│  (Bun/Elysia)       │
│                      │  JSON   │                      │
│  - Affiche données   │         │  - Collecte live     │
│  - Auto-refresh 30s  │         │  - Cache 30-60s      │
│  - Zéro credential   │         │  - Auth API key      │
│                      │         │  - Health check      │
└─────────────────────┘         └──────────┬───────────┘
                                           │
                              ┌────────────┼────────────┐
                              │            │            │
                              ▼            ▼            ▼
                    ┌──────────┐  ┌──────────┐  ┌──────────┐
                    │ APIs     │  │ SSH via   │  │ Direct   │
                    │ existantes│  │connectors │  │ accès    │
                    │          │  │ -api      │  │          │
                    │ Portainer│  │           │  │ Redis    │
                    │ GitLab   │  │ PVE       │  │ Postgres │
                    │ Ollama   │  │ Proxmox155│  │ Loki     │
                    │ AI-orch  │  │ Win11     │  │ Prometheus│
                    │ Prometheus│ │ Nginx     │  │          │
                    │ Loki     │  │ Jellyfin  │  │          │
                    └──────────┘  └──────────┘  └──────────┘

Pourquoi cette architecture

1. Frontend sur O2switch : accessible de l'extérieur (IP protégé par .htaccess), même si l'infra locale est down → on voit le dernier état connu
2. API backend sur prod-portainer : accès direct aux services internes, pas de SSH brut depuis O2switch, credentials côté serveur uniquement
3. CI/CD GitLab → smart-deploy : comme tous les autres projets de la stack, full automatisé

Comment récupérer chaque donnée

Constat : Toutes les données sont déjà accessibles via des APIs existantes (Portainer, GitLab, ai-orchestrator, Prometheus, Loki) ou via connectors-api (SSH proxy). Aucune donnée ne nécessite du SSH brut depuis le dashboard.

Pages à conserver/migrer

3. Mapping des 36 findings d'audit

Findings résolus par la migration (plus besoin de patcher le vieux code)

Findings à intégrer comme exigences du nouveau projet

4. Structure du nouveau projet

dashboard-33800/
├── backend/                          # API Bun/Elysia
│   ├── src/
│   │   ├── index.ts                  # Point d'entrée Elysia
│   │   ├── routes/
│   │   │   ├── health.ts             # GET /health (vérifie dépendances)
│   │   │   ├── infra.ts              # GET /api/infra (VMs, ZFS, system)
│   │   │   ├── docker.ts             # GET /api/docker (containers, images)
│   │   │   ├── gitlab.ts             # GET /api/gitlab (pipelines, jobs)
│   │   │   ├── ai.ts                 # GET /api/ai (GPU, jobs, models, queue)
│   │   │   ├── services.ts           # GET /api/services (health, registry)
│   │   │   ├── nginx.ts              # GET /api/nginx (sites, certs)
│   │   │   ├── monitoring.ts         # GET /api/monitoring (alerts, logs)
│   │   │   └── claude.ts             # GET /api/claude (tasks, propositions)
│   │   ├── collectors/
│   │   │   ├── portainer.ts          # Collecte via Portainer API
│   │   │   ├── gitlab.ts             # Collecte via GitLab API
│   │   │   ├── ai-orchestrator.ts    # Collecte via ai-orchestrator API
│   │   │   ├── prometheus.ts         # Collecte via Prometheus API
│   │   │   ├── loki.ts               # Collecte via Loki API
│   │   │   ├── ssh.ts                # Collecte via connectors-api SSH
│   │   │   └── connectors.ts         # Collecte via connectors-api /api/fetch
│   │   ├── cache.ts                  # Cache en mémoire avec TTL (30-60s)
│   │   ├── auth.ts                   # Auth API key
│   │   └── config.ts                 # Config depuis env vars
│   ├── package.json
│   ├── tsconfig.json
│   └── Dockerfile
│
├── frontend/                         # SPA statique
│   ├── src/
│   │   ├── index.html                # Shell HTML
│   │   ├── app.js                    # Routeur SPA + navigation
│   │   ├── pages/
│   │   │   ├── dashboard.js          # Page principale
│   │   │   ├── services.js           # Services registry
│   │   │   ├── ai-jobs.js            # AI jobs + previews
│   │   │   ├── ai-orchestrator.js    # GPU + queue
│   │   │   ├── gitlab.js             # CI/CD pipelines
│   │   │   ├── infra.js              # ZFS, NFS, VMs
│   │   │   ├── nginx.js              # Sites + SSL
│   │   │   ├── alerts.js             # Alertes temps réel
│   │   │   ├── claude.js             # Tasks/propositions
│   │   │   └── [...].js              # Autres pages
│   │   ├── components/
│   │   │   ├── nav.js                # Navigation unique
│   │   │   ├── card.js               # Composant carte
│   │   │   ├── table.js              # Composant tableau
│   │   │   ├── status-badge.js       # Badge statut
│   │   │   ├── chart.js              # Graphiques simples
│   │   │   └── toast.js              # Notifications
│   │   ├── api.js                    # Client API centralisé (fetch wrapper)
│   │   ├── style.css                 # Design system unique
│   │   └── utils.js                  # Helpers (formatDate, escapeHtml, etc.)
│   ├── static/
│   │   ├── architecture.svg          # Diagramme D2
│   │   └── favicon.ico
│   └── package.json                  # Build (minify, bundle) si besoin
│
├── docs/                             # Pages statiques (markdown → HTML au build)
│   ├── ai-tools.md
│   ├── endpoints.md
│   ├── syncthing.md
│   └── yolo.md
│
├── .gitlab-ci.yml                    # Pipeline CI/CD
├── conf.prod.gouroubleu.yml          # Config smart-deploy
└── README.md

Choix technologiques

Pourquoi pas un framework frontend lourd ?

Le dashboard est un outil interne de monitoring. Vanilla JS + fetch + template literals suffit :

• Pas de SEO nécessaire
• Pas d'interactivité complexe
• Pas de formulaires
• Juste afficher des données + auto-refresh

Si le besoin évolue, on peut migrer vers Qwik plus tard.

5. conf.prod.gouroubleu.yml

dashboard-api:
  image: registry.33800.nowhere84.com/dashboard-api
  port: 5520
  nginx:
    domain: dashboard-api.33800.nowhere84.com
    ssl: true
    private: true
    websocket: false
  env:
    # Auth
    API_KEY: "${DASHBOARD_API_KEY}"
    # Sources
    CONNECTORS_API_URL: "https://connectors.33800.nowhere84.com"
    CONNECTORS_API_KEY: "${CONNECTORS_API_KEY}"
    AI_ORCHESTRATOR_URL: "https://ai-orchestrator.33800.nowhere84.com"
    AI_ORCHESTRATOR_API_KEY: "${AI_ORCHESTRATOR_API_KEY}"
    GITLAB_URL: "https://gitlab.33800.nowhere84.com"
    GITLAB_TOKEN: "${GITLAB_TOKEN}"
    PORTAINER_URL: "https://prod-portainer.local:9443"
    PORTAINER_API_KEY: "${PORTAINER_API_KEY}"
    PROMETHEUS_URL: "http://localhost:9090"
    LOKI_URL: "http://localhost:3100"
    # Config
    CACHE_TTL_SECONDS: "30"
    ALLOWED_ORIGINS: "https://dashboard.nowhere84.com"
  loki: true

6. Pipeline CI/CD (.gitlab-ci.yml)

stages:
  - build
  - deploy

# Backend: build Docker image + deploy via smart-deploy
build-backend:
  stage: build
  script:
    - cd backend
    - docker build -t $CI_REGISTRY_IMAGE/api:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE/api:$CI_COMMIT_SHA
    - docker tag $CI_REGISTRY_IMAGE/api:$CI_COMMIT_SHA $CI_REGISTRY_IMAGE/api:latest
    - docker push $CI_REGISTRY_IMAGE/api:latest
  only:
    - main
    changes:
      - backend/**

deploy-backend:
  stage: deploy
  script:
    - smart-deploy dashboard-api
  only:
    - main
    changes:
      - backend/**

# Frontend: build + deploy to O2switch
build-frontend:
  stage: build
  script:
    - cd frontend
    - bun install
    - bun run build  # minify, bundle
  artifacts:
    paths:
      - frontend/dist/
  only:
    - main
    changes:
      - frontend/**
      - docs/**

deploy-frontend:
  stage: deploy
  script:
    - rsync -avz --delete frontend/dist/ $O2SWITCH_USER@$O2SWITCH_HOST:~/repositories/dashboard/
  only:
    - main
    changes:
      - frontend/**
      - docs/**

7. Endpoints API backend

Authentification

• Frontend → Backend : header X-API-Key: <DASHBOARD_API_KEY>
• Backend → connectors-api : header X-API-Key: <CONNECTORS_API_KEY>
• Backend → ai-orchestrator : header Authorization: Bearer <AI_ORCHESTRATOR_API_KEY> (après fix audit C-17)
• Backend → GitLab : header PRIVATE-TOKEN: <GITLAB_TOKEN>
• Backend → Portainer : header X-API-Key: <PORTAINER_API_KEY>

Cache

• Chaque endpoint a un cache en mémoire avec TTL configurable
• Le frontend fetch toutes les 30s (ou configurable)
• Le backend ne re-collecte que si le cache est expiré
• Résultat : les services sources ne sont appelés que toutes les TTL secondes, pas à chaque requête frontend

8. Frontend SPA — Design

Navigation unique

┌──────────────────────────────────────────────────────────────┐
│  33800 Dashboard    [Infra] [Docker] [AI] [CI/CD] [Alertes] │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  Contenu de la page active                                   │
│                                                              │
│  - Auto-refresh toutes les 30s                               │
│  - Pause quand onglet caché (visibilitychange)               │
│  - Toast notification si erreur                              │
│  - Bandeau "Dernière mise à jour : il y a Xs"               │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Client API centralisé (api.js)

// Un seul wrapper fetch, utilisé par toutes les pages
// - Ajoute X-API-Key automatiquement
// - Gère les erreurs (toast)
// - Gère le cache côté client si besoin
// - Pause quand onglet caché

Sécurité frontend (exigences audit)

• Pas de innerHTML pour du contenu dynamique → textContent ou échappement
• Pas de javascript: URI dans les liens
• Pas d'injection JSON dans <script> → fetch API
• CSP header strict via le backend
• .htaccess IP restriction sur O2switch (comme actuellement)

9. Plan d'implémentation

Phase 1 : Setup projet (1 session)

1. Créer le repo GitLab dashboard-33800 (ou nettoyer l'existant)
2. Initialiser la structure backend/ + frontend/
3. Configurer .gitlab-ci.yml
4. Configurer conf.prod.gouroubleu.yml
5. Premier deploy : page blanche avec health check OK

Phase 2 : Backend API — collecteurs (2-3 sessions)

1. index.ts + auth middleware + CORS + health check
2. cache.ts — cache mémoire avec TTL
3. Collecteurs un par un :
   • docker.ts (Portainer API) — containers, images
   • gitlab.ts (GitLab API) — pipelines, jobs
   • ai.ts (ai-orchestrator API) — GPU, jobs, queue, models
   • services.ts (health endpoints) — ping chaque service
   • ssh.ts (connectors-api SSH) — ZFS, NFS, crons, nginx, system
   • prometheus.ts — métriques système
   • loki.ts — derniers logs erreur
   • claude.ts — lire fichiers tasks/propositions/backlog
4. Tester chaque endpoint

Phase 3 : Frontend SPA (2-3 sessions)

1. Shell HTML + routeur + navigation + design system CSS
2. api.js — client API centralisé
3. Pages une par une :
   • Dashboard principal (containers, VMs, GPU, health)
   • Services (registry, health status)
   • AI (jobs, GPU, queue, models)
   • CI/CD (pipelines, deploys)
   • Infra (ZFS, NFS, system)
   • Nginx (sites, certs)
   • Alertes (agrégation)
   • Claude (tasks, propositions)
4. Pages statiques (docs, guides) — markdown → HTML au build
5. Auto-refresh + visibilitychange + toast erreurs

Phase 4 : CI/CD + migration (1 session)

1. Tester pipeline CI/CD complète (build → deploy backend + frontend)
2. Vérifier que le dashboard live fonctionne sur O2switch
3. Basculer le cron actuel vers le nouveau dashboard
4. Garder l'ancien en backup quelques jours
5. Supprimer l'ancien generate.sh quand le nouveau est stable

Phase 5 : Nettoyage (1 session)

1. Supprimer les anciens scripts bash (generate.sh, collect.sh, etc.)
2. Nettoyer les credentials de l'historique git si possible
3. Régénérer les tokens exposés (GitLab, Redis, JWT)
4. Mettre à jour CLAUDE.md + memory files
5. Mettre à jour config.json si toujours utilisé par d'autres projets

10. Dépendances avec les autres correctifs d'audit

Le nouveau dashboard dépend de certains correctifs d'audit sur les autres projets :

Ordre recommandé :

1. D'abord les correctifs d'audit sur les services existants (auth, health, CORS, DNS)
2. Ensuite la migration dashboard (qui utilise ces améliorations)

11. Résumé des décisions

Informations pour reprise en session future

Fichiers de référence :

• Cette proposition : ~/propositions/15-02-2026-13-30-dashboard-projet-gitlab-complet.md
• Rapport audit vérifié : ~/propositions/15-02-2026-10-10-audit-rapport-final-verifie.md
• Revue des correctifs : ~/tasks/15-02-2026-10-30-revue-audit-correctifs.md
• Proposition DNS Pi-hole : ~/propositions/15-02-2026-12-00-migration-ip-vers-dns-pihole.md
• Ancien dashboard : /stock_8to/33800-stack/monitoring/

Config réseau :

• config.json : /stock_8to/33800-stack/monitoring/config.json
• Hosts/IPs : voir CLAUDE.md section machines principales
• DNS Pi-hole : voir ~/.claude/memory/pihole-split-dns.md

Stack technique :

• Bun + Elysia (comme connectors-api, ulias-org)
• smart-deploy pour déploiement (voir ~/.claude/memory/ci-cd.md)
• conf.prod.gouroubleu.yml = source de vérité (voir ~/.claude/memory/docker.md)