Kurzanleitung ergänzt, wie die API über Dokploys Git-basiertes Compose-Deployment ausgerollt wird (Repo-URL, Compose-Path, JWT_SECRET als Env-Var, Domain/Port, Auto-Deploy-Webhook, Nutzeranlage) – ersetzt den zunächst erwogenen manuellen ZIP-Upload-Workaround. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.3 KiB
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.
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.
- Neue Compose-Application anlegen, Quelle „Git" (Custom Git Provider), Repo-URL
https://git.science-teaching.de/admin/LehrerApp.git, Branchmain. Bei privatem Repo einen SSH-Deploy-Key in Dokploy hinterlegen und im Git-Server eintragen. - 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. - Umgebungsvariable
JWT_SECRETim Dokploy-UI unter „Environment" setzen (nicht als.enveinchecken) – wird als${JWT_SECRET}in die Compose-Datei injiziert, wie beim lokalen Start. - Domain/Port: Domain auf Container-Port
5000mappen, HTTPS über Dokploys eingebauten Reverse-Proxy aktivieren. - Auto-Deploy: Webhook-URL aus Dokploy als Push-Hook im Git-Server eintragen (falls
unterstützt, z. B. Gitea) – dann löst jeder
git pushautomatisch ein Rebuild aus. - 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.