feat: Phase 3 – Modul-System (Manifest, ZIP-Installation, Lifecycle, Prozess-Manager)

This commit is contained in:
MPM Dev
2026-10-07 15:37:09 +02:00
parent e87dc1f836
commit 4bbca21fd6
31 changed files with 2055 additions and 19 deletions

View File

@@ -6,7 +6,7 @@ Der Arbeitsplan sieht zehn inkrementelle Phasen vor. Nach jeder Phase muss das S
|---|---|---|
| 1 | Grundgerüst (Docker, DB, Login, Rollen) | ✅ Abgeschlossen |
| 2 | Benutzerverwaltung | ✅ Abgeschlossen |
| 3 | Modul-System (Manifest, Installation, Lifecycle) | ⏳ Geplant |
| 3 | Modul-System (Manifest, Installation, Lifecycle) | ✅ Abgeschlossen |
| 4 | Gateway & dynamisches Routing (`/slug`) | ⏳ Geplant |
| 5 | Berechtigungssystem (User ↔ Module) | ⏳ Geplant |
| 6 | Modul-API (`/health`, `/api/manifest`, `/api/me`) | ⏳ Geplant |
@@ -51,10 +51,26 @@ Definition of Done: Admin kann Benutzer vollständig verwalten.
- [x] Backend-Tests: 49 bestanden (inkl. UsersService, ProfileService)
- [x] E2E verifiziert: CRUD, RBAC (User → 403), Login-Sperre nach Deaktivierung, Passwort-Flows
## Nächste Schritte (Phase 3 – Modul-System)
## Phase 3 – Modul-System (abgeschlossen)
- Modul-Datenmodell (`modules`-Tabelle) und Manifest-Vertrag (`module.json`)
- Modul-Installation als ZIP-Paket (Validierung, Dateien, Registrierung)
- Modul-Lifecycle (INSTALLED/STARTING/RUNNING/STOPPING/STOPPED/ERROR/DISABLED)
- Prozessverwaltung der Modul-Prozesse über Supervisor
- Healthchecks und Statusanzeige im Admin-Bereich
Definition of Done: Modul-Datenmodell, Manifest, Installation, Registrierung, Status, Start/Stop/Restart, Healthcheck.
- [x] `modules`-Tabelle (Migration 002) mit Lifecycle-Status und eindeutigen Ports/Slugs
- [x] Manifest-Vertrag `module.json` (Zod: ID, Name, Version, Slug, Runtime, Entrypoint, Port 41000–41999, Healthcheck, apiVersion)
- [x] ZIP-Installer mit Manifest-Validierung, Größenlimit (10 MB) und **Zip-Slip-Schutz**
- [x] Modul-Prozess-Manager: Start/Stop (SIGTERM→SIGKILL) als Kindprozesse, minimale ENV (keine Plattform-Secrets), eigene Log-Dateien
- [x] Healthcheck-Service mit Startup-Grace (10 Retries × 500 ms)
- [x] Lifecycle: INSTALLED → STARTING → RUNNING → STOPPING → STOPPED, ERROR, DISABLED
- [x] `GET/POST /api/v1/modules`, `POST :id/start|stop|restart`, `PATCH :id/enabled`, `GET :id/health`, `DELETE :id` (nur ADMIN)
- [x] Duplikat-Schutz: Modul-ID, Slug und Port müssen eindeutig sein (409)
- [x] Frontend: Modulverwaltungs-Seite (ZIP-Upload, Tabelle mit Status-Badges, Lifecycle-Buttons, Health-Anzeige, Remove-Dialog)
- [x] Persistente Volumes für Modul-Dateien und Logs (`modules-data`, `module-logs`)
- [x] Demo-Modul (`modules/demo`) als Referenzimplementierung
- [x] Backend-Tests: 72 bestanden (inkl. ModulesService-Lifecycle, Manifest-Validierung, Installer)
- [x] E2E verifiziert: Installation (201), Start → RUNNING, Healthcheck (healthy, 2 ms), Stop, Restart, Disable (stoppt Prozess), Start-Sperre bei Disable (400), Remove, RBAC (USER → 403)
## Nächste Schritte (Phase 4 – Gateway & Routing)
- Dynamisches Routing: `/slug` → Modul-Prozess (Nginx-Konfiguration zur Laufzeit)
- Zugriffskontrolle beim Routing (Session → Permission Check → 403/Proxy)
- Modul-Gateway mit sicherer Identitätsübergabe an das Modul