LehrerApp/docker/README.md

LehrerApp.Api – Deployment per Docker

Starten

cd docker
JWT_SECRET=<zufälliger-langer-string> docker compose up -d

./data (relativ zu docker/) wird als Volume gemountet und enthält alle Server-Daten (Ereignis-Logs, Snapshots, Nutzer) – bei Neustarts/Updates bleibt es erhalten.

Nutzer anlegen

Es gibt keine offene Registrierung (/api/auth/register). Neue Nutzer werden per CLI im laufenden Container angelegt:

docker compose exec api dotnet LehrerApp.Api.dll create-user <benutzername>

Fragt interaktiv nach einem Passwort (mind. 12 Zeichen). Alternativ nicht-interaktiv, z. B. aus einem Skript:

docker compose exec api dotnet LehrerApp.Api.dll create-user <benutzername> --password "<passwort>"

Der Befehl beendet sich danach sofort wieder, ohne den API-Dienst zu starten – für den eigentlichen Serverbetrieb läuft docker compose up unverändert weiter.

Passwort zurücksetzen

Analog zu create-user, aber für einen bereits existierenden Nutzer (schlägt fehl, wenn der Nutzer nicht existiert – zum Anlegen create-user verwenden):

docker compose exec api dotnet LehrerApp.Api.dll set-password <benutzername>
docker compose exec api dotnet LehrerApp.Api.dll set-password <benutzername> --password "<passwort>"

Backup

backup.sh sichert ./data (Ereignis-Logs, Snapshots, Anhänge, Nutzer) als komprimiertes Tar-Archiv unter docker/backups/ und räumt Archive älter als 30 Tage automatisch auf. Läuft direkt auf dem Host (kein Container-Zugriff nötig, ./data liegt dort per Bind-Mount ohnehin):

./docker/backup.sh

Für regelmäßige Sicherung z. B. per Cron, einmal täglich nachts:

0 3 * * * /pfad/zu/docker/backup.sh >> /pfad/zu/docker/backup.log 2>&1

Rate Limiting

/api/auth/login ist auf 5 Versuche pro Minute begrenzt (Brute-Force-Schutz). Alle übrigen Endpunkte sind zusätzlich global auf 120 Anfragen pro Minute je IP begrenzt. Anhänge sind auf 15 MB Anfragegröße gedeckelt (Kestrel MaxRequestBodySize), einzelne Dateien clientseitig zusätzlich auf 10 MB (IAttachmentStorage.MaxSizeBytes).

Deployment über Dokploy

Kein manuelles Bauen/Hochladen nötig – Dokploy zieht das Repo direkt per Git und baut das Image selbst aus docker/Dockerfile.api.

1. Neue Compose-Application anlegen, Quelle „Git" (Custom Git Provider), Repo-URL https://git.science-teaching.de/admin/LehrerApp.git, Branch main. Bei privatem Repo einen SSH-Deploy-Key in Dokploy hinterlegen und im Git-Server eintragen.
2. Compose Path: docker/docker-compose.yml. Der Build-Context (context: ..) und das Dockerfile sind darin bereits korrekt referenziert – Dokploy checkt das ganze Repo aus, das passt ohne Anpassung.
3. Umgebungsvariable JWT_SECRET im Dokploy-UI unter „Environment" setzen (nicht als .env einchecken) – wird als ${JWT_SECRET} in die Compose-Datei injiziert, wie beim lokalen Start.
4. Domain/Port: Domain auf Container-Port 5000 mappen, HTTPS über Dokploys eingebauten Reverse-Proxy aktivieren.
5. Auto-Deploy: Webhook-URL aus Dokploy als Push-Hook im Git-Server eintragen (falls unterstützt, z. B. Gitea) – dann löst jeder git push automatisch ein Rebuild aus.
6. Nutzer anlegen nach dem ersten Deploy: über Dokploys Terminal/Exec-Tab am laufenden Container dotnet LehrerApp.Api.dll create-user <name> ausführen (siehe oben).

Der ./data-Bind-Mount bleibt unverändert – Dokploy hält das Checkout-Verzeichnis der Compose-App über Redeploys hinweg stabil, backup.sh funktioniert damit unverändert weiter. Nach dem ersten echten Deploy einmal gegenprüfen: Redeploy anstoßen und verifizieren, dass Daten (z. B. ein testweise angelegter Nutzer) erhalten bleiben.