3 Commits

Include renames

Author	SHA1	Message	Date
Nick SzaunigandClaude Opus 5	4b76247648	fix: Health-Endpunkte trennen Liveness von Readiness ... Readiness- und Liveness-Probe zeigten beide auf "/" — eine force-dynamic-Seite samt Datenbankabfragen und vollem React-Rendering, alle 10 bzw. 30 Sekunden. Der teure Teil ist dabei nicht das eigentliche Problem. Entscheidend ist, dass damit auch die LIVENESS-Probe an der Datenbank haengt: faellt die DB voruebergehend aus, wertet Kubernetes den Container als tot und startet ihn neu — woraufhin der neue Container laut Dockerfile-CMD zuerst "prisma migrate deploy" und "prisma db seed" gegen genau die gestoerte Datenbank faehrt. Aus einer voruebergehenden Stoerung wird so eine Neustart-Schleife. Jetzt zwei Endpunkte mit klar getrennter Aufgabe: - /api/health — nur "Prozess antwortet", ohne Datenbankzugriff. Liveness-Probe. - /api/health/ready — zusaetzlich "SELECT 1" gegen die Datenbank, sonst 503. Readiness-Probe und Docker-Healthcheck. Faellt die Readiness-Probe aus, nimmt Kubernetes den Pod nur aus dem Load-Balancing und startet ihn nicht neu — genau das richtige Verhalten. "SELECT 1" laeuft unveraendert auf PostgreSQL und MySQL/MariaDB und beruehrt keine Tabelle, ist also unabhaengig vom Migrationsstand. Die Fehlerdetails gehen nur ins Server-Log, nicht in die oeffentliche Antwort. docker-compose.yml bekommt denselben Readiness-Endpunkt als Healthcheck, mit start_period fuer den Migrations-/Seed-Lauf vor dem Serverstart. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-15 10:01:06 +02:00
Nick SzaunigandClaude Sonnet 5	d0c1d0840c	fix: Admin-Uploads auf dem Live-Server (Berechtigung, Persistenz, Body-Size-Limit) ... Uploads (Bilder + Hero-Video) schlugen live fehl, lokal aber nicht: der Container laeuft als non-root "nextjs", /app/uploads existierte nirgends vorbereitet und gehoert root -> mkdir() scheiterte mit EACCES, unbehandelt als HTML-500 statt JSON, der Client zeigte nur einen haengenden "wird hochgeladen"-Zustand ohne Fehlermeldung. - Dockerfile legt /app/uploads jetzt vor dem User-Wechsel an und uebereignet es dem nextjs-Nutzer - docker-compose.yml persistiert Uploads jetzt ueber ein eigenes Volume (vorher gingen sie bei jedem Redeploy verloren) und setzt UPLOAD_DIR explizit - Beide Upload-Routen fangen Dateisystemfehler jetzt ab und liefern eine echte JSON-Fehlermeldung statt eine unbehandelte Exception - k8s-Manifeste vorsorglich mitgefixt (fsGroup fuer den Volume-Mount, Ingress-Body-Size-Limit) fuer den Fall eines spaeteren Kubernetes-Wechsels Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-11 15:48:14 +02:00
Nick Szaunig	5889f58da7	feat: Docker-, Kubernetes- und Gitea-Actions-Deployment-Pipeline ... Dockerfile (Multi-Stage, "output: standalone"), docker-compose.yml mit Caddy als einzigem nach aussen offenem Reverse-Proxy (verhindert X-Forwarded-For-Faelschung fuer das App-eigene Rate-Limiting), Gitea Actions Workflow der bei jedem Push zwei Image-Tags in die Gitea- Container-Registry baut (schlankes Laufzeit-Image + ein Migrations- Image mit Prisma-CLI), sowie rohe Kubernetes-Manifeste (Namespace, ConfigMap, Secret-Vorlage, Postgres-/MySQL-StatefulSet, Migrations-Job, App-Deployment, Ingress) fuer den Cluster-Betrieb. Siehe k8s/README.md fuer den vollstaendigen Einrichtungs-/Deployment-Ablauf.	2026-08-17 14:30:46 +02:00