1061a8b9ad
Die SvelteKit-App liegt unter frontend/, das Backend unter backend/ als eigenständige PocketBase-Instanz mit Dockerfile, docker-compose und versioniertem Schema. - PocketBase-URL über PUBLIC_PB_URL konfigurierbar, Default bleibt die produktive Instanz https://api.stammtisch-hersbruck.de - Schema als Snapshot-Migration der sechs fachlichen Collections (users, teams, events, runs, riders, times), abgezogen von der produktiven Instanz. Verifiziert: ein Erststart gegen leere pb_data legt alle sechs an, Felder und API-Rules stimmen überein. - pb_data und pb_migrations als Bind-Mounts, damit Daten persistieren und im Admin-UI erzeugte Migrationen im Repo landen - Veraltete Dokumentation entfernt: pocketbase_schema.json nannte Collections (stages, results, organizers), die es nicht gibt Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| pb_hooks | ||
| pb_migrations | ||
| .env.example | ||
| .gitignore | ||
| docker-compose.yaml | ||
| Dockerfile | ||
| entrypoint.sh | ||
| README.md | ||
stammtisch-hersbruck.de — Backend (PocketBase)
PocketBase-Instanz für Events, Läufe, Fahrer, Zeiten und Teams.
Lokal starten
.env aus der Vorlage anlegen (die .env selbst steht in .gitignore):
cp .env.example .env
und die Werte eintragen — .env.example beschreibt jede Variable. Dann:
docker compose up -d --build
Admin-UI: http://127.0.0.1:8090/_/ — Login mit SUPERUSER_EMAIL/SUPERUSER_PASSWORD.
Damit das Frontend gegen diese Instanz läuft, in ../frontend/.env
PUBLIC_PB_URL=http://127.0.0.1:8090 setzen.
Schema
Das Schema liegt als versionierte Migration in pb_migrations/ und wird beim
Start automatisch angewendet. Es enthält die sechs fachlichen Collections
users, teams, events, runs, riders, times.
1754400000_init_schema.js ist ein Snapshot der produktiven Instanz. Er wurde
per GET /api/collections abgezogen und ruft importCollections mit
deleteMissing = false auf — die Migration legt an und aktualisiert, löscht
aber nichts, was nicht im Snapshot steht.
Schema-Änderungen im Admin-UI erzeugen in pb_migrations/ neue Dateien; diese
müssen committet werden.
Ein frisch gestarteter Container hat damit dasselbe Schema wie die produktive Instanz — aber keine Daten.
Datenpersistenz
Sämtliche Laufzeitdaten liegen in der SQLite-DB unter /pb/pb_data: Datensätze,
Uploads, die SMTP-Einstellungen und der Superuser. Ohne gemountetes Volume auf
diesem Pfad sind sie nach jedem Redeploy verloren.
Das Volume-Mapping ./pb_data:/pb/pb_data steht in der docker-compose.yaml,
damit die Persistenz-Konfiguration versioniert im Repo liegt.
Trügerisches Signal: Die Collections kommen aus der Migration und sind nach einem Redeploy auch dann da, wenn gar kein Volume existiert. Sie taugen nicht als Nachweis funktionierender Persistenz — das zeigt nur ein Datensatz, der in keiner Migration steht.
Mount prüfen:
docker inspect <container> --format '{{json .Mounts}}' | jq
Erscheint dort kein Eintrag mit "Destination": "/pb/pb_data", fehlt die Persistenz.
pb_data/ steht in .gitignore und gehört dort auch hin.
Superuser-Verhalten
entrypoint.sh ruft superuser create auf — bewusst nicht upsert.
Existiert der Account bereits, scheitert create mit „Value must be unique" und
das Passwort bleibt unangetastet. Eine im Admin-UI vorgenommene
Passwortänderung überlebt damit jeden Redeploy.
| Situation | Verhalten |
|---|---|
| Erster Start, Variablen gesetzt | Superuser wird angelegt |
| Neustart, Account existiert | „Superuser existiert bereits — Passwort bleibt unverändert" |
| Passwort im UI geändert, dann Neustart | UI-Passwort gilt weiter, Env wird ignoriert |
| Variablen nicht gesetzt | Übersprungen, PocketBase gibt Installer-Link im Log aus |
| Passwort zu kurz (< 8 Zeichen) | Container bricht mit Exitcode 1 ab |
Passwort später ändern: im Admin-UI, nicht über die Env — eine Änderung der Env-Variable hat keine Wirkung mehr, sobald der Account existiert.
PocketBase aktualisieren
Die Version ist über das Build-Arg PB_VERSION gepinnt (Dockerfile und
docker-compose.yaml). Wert hochsetzen, committen, neu bauen.
Ein latest gibt es bewusst nicht: Der GitHub-Asset heißt
pocketbase_<version>_linux_amd64.zip, enthält die Version also im Dateinamen.
Der Pin ist auch gewollt — sonst zieht jeder Rebuild unangekündigt eine neue
Version, inklusive möglicher DB-Schema-Migrationen.
Vor einem Update: Changelog prüfen
(https://github.com/pocketbase/pocketbase/releases) und pb_data sichern —
PocketBase migriert die DB beim Start automatisch, ein Downgrade ist danach
nicht mehr ohne Weiteres möglich.