Nick Szaunig
5889f58da7
Docker Image bauen und veroeffentlichen / build-and-push (push) Waiting to run
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.
93 lines
4.3 KiB
Markdown
93 lines
4.3 KiB
Markdown
# Wabenhain in Kubernetes
|
|
|
|
Rohe Manifeste, mit `kubectl apply -f k8s/<datei>` einzeln oder als Ordner
|
|
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`.
|
|
|
|
Voraussetzung: ein Repo-/Org-Secret `REGISTRY_TOKEN` in Gitea anlegen
|
|
(Personal Access Token mit `package`-Scope, unter Benutzereinstellungen →
|
|
Anwendungen → Access Tokens erzeugen, dann unter Repo-Einstellungen →
|
|
Actions → Secrets als `REGISTRY_TOKEN` hinterlegen). Der automatisch von
|
|
Gitea Actions bereitgestellte `GITEA_TOKEN` reicht dafuer aktuell NICHT
|
|
aus (fehlendes Package-Write-Recht, Stand heute).
|
|
|
|
2. **Ein Docker-Image ist Provider-uebergreifend**: Prisma generiert den
|
|
Client Provider-spezifisch — ein `.next/standalone`-Build kann seinen
|
|
generierten Client nicht zur Laufzeit wechseln. Deshalb generiert
|
|
`scripts/generate-prisma-clients.mjs` (Teil von `pnpm build`, laeuft also
|
|
automatisch bei jedem Image-Build) BEIDE Varianten ins selbe Image; die
|
|
Wahl zwischen ihnen passiert zur Laufzeit ueber `DATABASE_PROVIDER`, siehe
|
|
`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.
|
|
|
|
3. `k8s/02-secret.example.yaml` nach `k8s/02-secret.yaml` kopieren (per
|
|
`.gitignore` ausgeschlossen — NIE mit echten Werten committen) und
|
|
ausfuellen. Alternativ direkt per `kubectl create secret`, siehe
|
|
Kommentar in der Beispieldatei.
|
|
|
|
4. `01-configmap.yaml`: `DATABASE_PROVIDER` (postgresql/mysql) und
|
|
`NEXT_PUBLIC_SITE_URL` (echte Domain) anpassen.
|
|
|
|
5. In `04-migrate-job.yaml` und `05-app-deployment.yaml` die
|
|
`image:`-Platzhalter (`git.example.com/OWNER/wabenhain:...`) durch die
|
|
tatsaechliche Registry/Owner/Tag aus Schritt 1 ersetzen. In
|
|
`06-ingress.yaml` `shop.example.com` durch die echte Domain ersetzen
|
|
(zweimal: `host:` und `tls.hosts`).
|
|
|
|
## Deployment
|
|
|
|
```bash
|
|
kubectl apply -f k8s/00-namespace.yaml
|
|
kubectl apply -f k8s/01-configmap.yaml
|
|
kubectl apply -f k8s/02-secret.yaml
|
|
|
|
# Nur EINE der beiden Datenbanken anwenden, passend zu DATABASE_PROVIDER:
|
|
kubectl apply -f k8s/03-postgres.yaml
|
|
# kubectl apply -f k8s/03-mysql.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
|
|
```
|
|
|
|
## 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
|
|
```
|
|
|
|
## Bekannte Grenzen dieser Manifeste
|
|
|
|
- **`replicas: 1`** in `05-app-deployment.yaml`, bewusst nicht mehr: das
|
|
Login-/2FA-/Checkout-Rate-Limiting (`lib/rate-limit.ts`) haelt seinen
|
|
Zustand im Prozessspeicher, nicht in einem gemeinsamen Store. Mehrere
|
|
Replicas wuerden das Limit unbemerkt proportional aufweichen. Fuer
|
|
horizontale Skalierung zuerst `lib/rate-limit.ts` auf Redis o.ae. umstellen.
|
|
- Kein `HorizontalPodAutoscaler`, kein `PodDisruptionBudget`, keine
|
|
`NetworkPolicy` — je nach Cluster/Anforderungen ergaenzen.
|
|
- Die Postgres-/MySQL-StatefulSets sind Single-Instance ohne Replikation/
|
|
Backup-Automation. Fuer produktiven Betrieb einen Managed-Datenbank-Dienst
|
|
oder einen dedizierten DB-Operator (z.B. CloudNativePG) in Erwaegung
|
|
ziehen — `DATABASE_URL` in `02-secret.yaml` einfach auf den externen
|
|
Endpunkt zeigen lassen, `03-postgres.yaml`/`03-mysql.yaml` dann nicht
|
|
anwenden.
|