SQL and Seed into App

2026-08-19 07:26:47 +02:00
1 parent 4ed102afe7
commit 8587265155
@@ -24,6 +24,10 @@ stringData:
  # Host "wabenhain-postgres" bzw. "wabenhain-mysql" passend zum Service aus
  # 03-postgres.yaml/03-mysql.yaml waehlen; Port 5432 (Postgres) bzw. 3306
  # (MySQL). Muss zu DATABASE_PROVIDER in 01-configmap.yaml passen.
+  # WICHTIG: das Passwort hier MUSS URL-encodiert sein (Sonderzeichen wie
+  # @ : / % # ? & sonst ungueltig bzw. falsch geparst) — DB_PASSWORD unten
+  # bleibt dagegen roh/unencodiert. Encodieren z.B. mit:
+  #   node -e "console.log(encodeURIComponent('DEIN-PASSWORT'))"
  DATABASE_URL: "postgresql://wabenhain:CHANGE-ME@wabenhain-postgres:5432/wabenhain?schema=public"
  # Dasselbe Passwort wie oben in DATABASE_URL — wird vom Postgres-/MySQL-
  # StatefulSet (je nachdem, welches du anwendest) zum Anlegen des
@@ -1,37 +0,0 @@
-# Einmalig VOR jedem Deployment (bzw. bei jedem neuen Image-Tag) ausfuehren:
-#   kubectl delete job wabenhain-migrate -n wabenhain --ignore-not-found
-#   kubectl apply -f k8s/04-migrate-job.yaml
-#   kubectl wait --for=condition=complete job/wabenhain-migrate -n wabenhain --timeout=120s
-# "kubectl delete...--ignore-not-found" zuerst, weil Jobs nicht ueberschrieben
-# werden koennen (Kubernetes-Job-Objekte sind unveraenderlich) — ohne das
-# schlaegt ein erneutes "kubectl apply" mit demselben Namen fehl.
-#
-# Nutzt das ":migrate-<sha>"-Image aus der Gitea-Actions-Pipeline (hat die
-# Prisma-CLI + tsx an Bord, die "pnpm db:deploy"/"pnpm db:seed" brauchen —
-# das schlanke Laufzeit-Image aus 05-app-deployment.yaml bewusst nicht,
-# siehe Dockerfile). image: unten mit der tatsaechlichen Registry/Tag
-# ersetzen.
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: wabenhain-migrate
-  namespace: wabenhain
-spec:
-  backoffLimit: 2
-  template:
-    spec:
-      restartPolicy: Never
-      containers:
-        - name: migrate
-          image: git.encry.de/nick.rosenloecher/wabenhain:migrate-REPLACE-ME
-          # prisma migrate deploy (nicht "db push"): wendet die committeten
-          # Migrationsdateien nicht-interaktiv an, das ist Prismas
-          # vorgesehener Weg fuer Produktions-Deployments. db:seed danach
-          # legt/erneuert nur das Admin-Konto + Beispieldaten, ist idempotent
-          # (siehe prisma/seed.ts).
-          command: ["sh", "-c", "pnpm db:deploy && pnpm db:seed"]
-          envFrom:
-            - configMapRef:
-                name: wabenhain-config
-            - secretRef:
-                name: wabenhain-secrets
@@ -1,8 +1,10 @@
 # image: unten mit der tatsaechlichen Registry/Tag aus der Gitea-Actions-
-# Pipeline ersetzen (das schlanke Laufzeit-Image, NICHT ":migrate-...").
-# Vor dem ersten Rollout einmal den Migrations-Job (04-migrate-job.yaml)
-# erfolgreich durchlaufen lassen, sonst startet die App gegen eine leere,
-# ungemigrateet Datenbank.
+# 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:
@@ -45,8 +47,14 @@ spec:
            httpGet:
              path: /
              port: 3000
-            initialDelaySeconds: 20
+            # 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
          resources:
            requests:
              cpu: 100m
@@ -6,11 +6,12 @@ anwendbar. Nummerierung = empfohlene Reihenfolge.
 ## Einmalige Vorbereitung

 1. **Gitea Actions**: `.gitea/workflows/docker-build.yml` baut bei jedem
-   Push auf `main` zwei Image-Tags in der Gitea-Container-Registry:
-   - `<registry>/<owner>/wabenhain:latest` (+ `:sha-<kurzhash>`, `:vX.Y.Z` bei
-     Tags) — das schlanke Laufzeit-Image fuer `05-app-deployment.yaml`.
-   - `<registry>/<owner>/wabenhain:migrate-<sha>` — enthaelt zusaetzlich die
-     Prisma-CLI/tsx, fuer `04-migrate-job.yaml`.
+   Push auf `main` das Image `<registry>/<owner>/wabenhain:latest` (+
+   `:sha-<kurzhash>`, `:vX.Y.Z` bei Tags) in der Gitea-Container-Registry.
+   Ein einzelnes Image reicht fuer `05-app-deployment.yaml` — es traegt
+   sowohl die Next.js-App als auch die Prisma-CLI/tsx und migriert/seedet
+   die Datenbank beim Start selbst (siehe Punkt 2 unten), kein separates
+   Migrations-Image mehr.

   Voraussetzung: ein Repo-/Org-Secret `REGISTRY_TOKEN` in Gitea anlegen
   (Personal Access Token mit `package`-Scope, unter Benutzereinstellungen →
@@ -28,6 +29,10 @@ anwendbar. Nummerierung = empfohlene Reihenfolge.
   `src/lib/prisma.ts`. Ein Image reicht also fuer Postgres UND MySQL — nur
   `DATABASE_PROVIDER`/`DATABASE_URL` in `01-configmap.yaml`/
   `02-secret.yaml` muessen zur tatsaechlich gewaehlten Datenbank passen.
+   Beim Container-Start fuehrt derselbe Prozess erst `prisma migrate deploy`
+   und `prisma db seed` aus, BEVOR der Next.js-Server startet (siehe
+   Dockerfile-CMD in der `runner`-Stage) — beide Schritte sind idempotent
+   und bei jedem Neustart gefahrlos, kein separater Migrations-Job noetig.

 3. `k8s/02-secret.example.yaml` nach `k8s/02-secret.yaml` kopieren (per
   `.gitignore` ausgeschlossen — NIE mit echten Werten committen) und
@@ -37,13 +42,10 @@ anwendbar. Nummerierung = empfohlene Reihenfolge.
 4. `01-configmap.yaml`: `DATABASE_PROVIDER` (postgresql/mysql) und
   `NEXT_PUBLIC_SITE_URL` (echte Domain) anpassen.

-5. `image:` in `04-migrate-job.yaml`/`05-app-deployment.yaml` zeigt bereits
-   auf `git.encry.de/nick.rosenloecher/wabenhain` — nur noch den Tag pruefen
-   (`:latest` in `05-app-deployment.yaml` passt fuer den jeweils neuesten
-   `main`-Build; `:migrate-REPLACE-ME` in `04-migrate-job.yaml` durch den
-   echten Commit-Kurzhash aus dem Gitea-Actions-Lauf ersetzen, sichtbar unter
-   Repo → Actions → Workflow-Run). In `06-ingress.yaml` `shop.example.com`
-   durch die echte Domain ersetzen
+5. `image:` in `05-app-deployment.yaml` zeigt bereits auf
+   `git.encry.de/nick.rosenloecher/wabenhain` — nur noch den Tag pruefen
+   (`:latest` passt fuer den jeweils neuesten `main`-Build). In
+   `06-ingress.yaml` `shop.example.com` durch die echte Domain ersetzen
   (zweimal: `host:` und `tls.hosts`).

 ## Deployment
@@ -59,25 +61,24 @@ kubectl apply -f k8s/03-postgres.yaml

 kubectl wait --for=condition=ready pod -l app=wabenhain-postgres -n wabenhain --timeout=120s

-# Migrationen + Seed (Admin-Konto, Beispieldaten) — vor jedem neuen
-# Image-Tag erneut ausfuehren:
-kubectl delete job wabenhain-migrate -n wabenhain --ignore-not-found
-kubectl apply -f k8s/04-migrate-job.yaml
-kubectl wait --for=condition=complete job/wabenhain-migrate -n wabenhain --timeout=120s
-
 kubectl apply -f k8s/05-app-deployment.yaml
 kubectl apply -f k8s/06-ingress.yaml
 ```

+Migrationen + Seed (nur Admin-Konto, KEINE Beispieldaten — siehe Punkt 2
+oben) laufen automatisch beim Container-Start —
+`kubectl rollout status deployment/wabenhain-app -n wabenhain` zeigt, wann
+der erste Pod bereit ist.
+
 ## Bei einem neuen Image (Redeploy)

 ```bash
-kubectl delete job wabenhain-migrate -n wabenhain --ignore-not-found
-kubectl apply -f k8s/04-migrate-job.yaml
-kubectl wait --for=condition=complete job/wabenhain-migrate -n wabenhain --timeout=120s
 kubectl rollout restart deployment/wabenhain-app -n wabenhain
 ```

+Migrationen + Seed laufen automatisch erneut beim Start jedes neuen Pods
+(idempotent, siehe oben).
+
 ## Bekannte Grenzen dieser Manifeste

 - **`replicas: 1`** in `05-app-deployment.yaml`, bewusst nicht mehr: das