adminandClaude Sonnet 5
a68bb933c5
create-user lehnt einen bereits existierenden Nutzernamen ab und UserStore hatte keinen Weg, ein Passwort nachträglich zu ändern - einzige Alternative wäre manuelles Editieren der LiteDB-Binärdatei gewesen. Neuer Befehl set-password <benutzername> [--password <pw>] nach demselben Muster wie create-user (Cli.ParsePassword extrahiert, von beiden Befehlen geteilt). docker/README.md ergänzt. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
89 lines
3.7 KiB
Markdown
89 lines
3.7 KiB
Markdown
# 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.
|
||
|
||
## 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):
|
||
|
||
```bash
|
||
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):
|
||
|
||
```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.
|