# LehrerApp.Api – Deployment per Docker

## Starten

```bash
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:

```bash
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:

```bash
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.

## 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):

```bash
./docker/backup.sh
```

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

```bash
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.