Nick SzaunigandClaude Opus 5
4b76247648
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]>
144 lines
6.6 KiB
YAML
144 lines
6.6 KiB
YAML
# image: unten mit der tatsaechlichen Registry/Tag aus der Gitea-Actions-
|
|
# Pipeline ersetzen. Kein separater Migrations-Job mehr noetig: der
|
|
# Container fuehrt "prisma migrate deploy" + "prisma db seed" selbst aus,
|
|
# BEVOR er den Server startet (siehe Dockerfile-CMD in der runner-Stage) —
|
|
# beide Schritte sind idempotent, laufen also bei jedem Neustart gefahrlos
|
|
# erneut. Readiness-/Liveness-Probes greifen automatisch erst, sobald Port
|
|
# 3000 offen ist, also nach abgeschlossener Migration/Seed.
|
|
apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: wabenhain-app
|
|
namespace: wabenhain
|
|
spec:
|
|
# ACHTUNG bevor du hochskalierst: lib/rate-limit.ts haelt Login-/2FA-/
|
|
# Checkout-Limits aktuell im Prozessspeicher, nicht in einem gemeinsamen
|
|
# Store. Mit replicas > 1 verteilt sich derselbe Nutzer per Load-Balancing
|
|
# auf mehrere Prozesse mit je eigenem Zaehler — das Limit wird effektiv um
|
|
# den Skalierungsfaktor schwaecher (2 Replicas = 2x mehr Versuche moeglich),
|
|
# ohne dass das im Frontend sichtbar waere. Fuer replicas > 1 zuerst
|
|
# lib/rate-limit.ts auf einen gemeinsamen Store (z.B. Redis) umstellen.
|
|
replicas: 1
|
|
selector:
|
|
matchLabels:
|
|
app: wabenhain-app
|
|
template:
|
|
metadata:
|
|
labels:
|
|
app: wabenhain-app
|
|
spec:
|
|
# fsGroup=1001 muss zur "nodejs"-Gruppe (gid 1001) passen, die das
|
|
# Dockerfile fuer den non-root "nextjs"-Laufzeitbenutzer anlegt: ohne
|
|
# dieses Feld mountet Kubernetes das "uploads"-Volume (egal ob emptyDir
|
|
# oder ein echtes PVC) mit root:root-Besitz — das ueberschreibt den im
|
|
# Image bereits per chown gesetzten Besitzer von /app/uploads
|
|
# vollstaendig, und der nicht-root laufende Container koennte trotzdem
|
|
# keine Datei dort anlegen (EACCES bei jedem Admin-Upload). fsGroup
|
|
# sorgt dafuer, dass Kubernetes JEDES gemountete Volume zusaetzlich der
|
|
# Gruppe 1001 zuordnet und gruppen-schreibbar macht.
|
|
securityContext:
|
|
fsGroup: 1001
|
|
containers:
|
|
- name: app
|
|
image: git.encry.de/nick.rosenloecher/wabenhain:latest
|
|
ports:
|
|
- containerPort: 3000
|
|
envFrom:
|
|
- configMapRef:
|
|
name: wabenhain-config
|
|
- secretRef:
|
|
name: wabenhain-secrets
|
|
volumeMounts:
|
|
# Muss auf denselben Pfad zeigen wie UPLOAD_DIR in
|
|
# 01-configmap.yaml. Das "uploads"-Volume selbst wird HIER
|
|
# bewusst nicht definiert (kein PV/PVC in diesem Manifest) — das
|
|
# haengt vom tatsaechlichen Storage-Backend ab (SMB/NFS/
|
|
# hostPath/...), das die Betreiberin bereitstellt. Unten im
|
|
# "volumes:"-Block einen passenden Eintrag mit demselben Namen
|
|
# ("uploads") ergaenzen, z.B. ueber eine
|
|
# persistentVolumeClaim.claimName, sonst startet der Pod nicht
|
|
# (fehlende Volume-Referenz).
|
|
- name: uploads
|
|
mountPath: /app/uploads
|
|
# Prueft die Datenbank mit (siehe app/api/health/ready/route.ts).
|
|
# Schlaegt sie fehl, nimmt Kubernetes den Pod nur aus dem
|
|
# Load-Balancing, startet ihn aber nicht neu.
|
|
readinessProbe:
|
|
httpGet:
|
|
path: /api/health/ready
|
|
port: 3000
|
|
initialDelaySeconds: 10
|
|
periodSeconds: 10
|
|
# Bewusst der DB-FREIE Endpunkt (siehe app/api/health/route.ts):
|
|
# eine Liveness-Probe an der Datenbank wuerde aus einer
|
|
# voruebergehenden DB-Stoerung eine Neustart-Schleife machen, weil
|
|
# der neu startende Container laut Dockerfile-CMD zuerst
|
|
# "prisma migrate deploy" gegen dieselbe gestoerte Datenbank faehrt.
|
|
# Beide Probes zeigten vorher auf "/" — also auf eine
|
|
# force-dynamic-Seite mit DB-Abfragen und vollem React-Rendering
|
|
# alle 10 bzw. 30 Sekunden.
|
|
livenessProbe:
|
|
httpGet:
|
|
path: /api/health
|
|
port: 3000
|
|
# initialDelaySeconds/failureThreshold grosszuegiger als sonst
|
|
# ueblich: der Container migriert/seedet die DB selbst vor dem
|
|
# Serverstart (siehe Kommentar oben) — genug Spielraum, damit ein
|
|
# laengerer erster Migrationslauf nicht faelschlich als haengender
|
|
# Prozess gewertet und der Container neu gestartet wird.
|
|
initialDelaySeconds: 30
|
|
periodSeconds: 30
|
|
failureThreshold: 5
|
|
# Bemessen nach dem teuersten Vorgang der Anwendung, dem
|
|
# Admin-Video-Upload: Node laedt den multipart-Body beim
|
|
# request.formData() vollstaendig in den Speicher, und die Datei
|
|
# darf bis zu 100 MB gross sein (MAX_UPLOAD_VIDEO_BYTES in
|
|
# lib/uploads.ts). Zusammen mit dem Grundverbrauch des
|
|
# Next.js-Servers sprengte das ein Limit von 512Mi — der Kernel
|
|
# beendet den Prozess dann mitten im Upload (OOMKilled), und im
|
|
# Browser kommt davon nur die HTML-Fehlerseite des Reverse-Proxy an
|
|
# ("Unexpected token '<', "<!DOCTYPE "... is not valid JSON").
|
|
#
|
|
# Die Route selbst haelt inzwischen nur noch den Body im Speicher
|
|
# und streamt alles Weitere ueber die Platte (siehe
|
|
# app/api/admin/upload-video/route.ts) — 1Gi gibt darueber hinaus
|
|
# Reserve, damit ein zweiter gleichzeitiger Zugriff den Pod nicht
|
|
# kippt.
|
|
#
|
|
# ffmpeg ist CPU-gebunden: mit nur 100m dauert das Umrechnen ein
|
|
# Vielfaches und laeuft eher in ein Proxy-Zeitlimit. Bewusst KEIN
|
|
# CPU-Limit, nur ein hoeherer Request — ein Limit wuerde den
|
|
# Transcode hart drosseln, auch wenn der Knoten gerade frei ist.
|
|
resources:
|
|
requests:
|
|
cpu: 500m
|
|
memory: 512Mi
|
|
limits:
|
|
memory: 1Gi
|
|
volumes:
|
|
# Platzhalter — die Betreiberin ergaenzt hier ihre eigene
|
|
# Volume-Quelle fuer den Namen "uploads" (z.B. ein PVC, das gegen
|
|
# ein SMB-/NFS-Backend oder einen hostPath gebunden ist), etwa:
|
|
# - name: uploads
|
|
# persistentVolumeClaim:
|
|
# claimName: wabenhain-uploads-pvc
|
|
- name: uploads
|
|
# CHANGE-ME: obige emptyDir-Zeile durch die echte Volume-Quelle
|
|
# ersetzen. emptyDir ist NICHT persistent (Inhalt geht bei jedem
|
|
# Pod-Neustart verloren) und dient hier nur als Platzhalter, damit
|
|
# dieses Manifest ohne weitere Aenderung "kubectl apply"-faehig
|
|
# bleibt.
|
|
emptyDir: {}
|
|
---
|
|
apiVersion: v1
|
|
kind: Service
|
|
metadata:
|
|
name: wabenhain-app
|
|
namespace: wabenhain
|
|
spec:
|
|
selector:
|
|
app: wabenhain-app
|
|
ports:
|
|
- port: 80
|
|
targetPort: 3000
|