Nick SzaunigandClaude Sonnet 5
d0c1d0840c
Docker Image bauen und veroeffentlichen / build-and-push (push) Successful in 2m29s
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]>
105 lines
5.4 KiB
Docker
105 lines
5.4 KiB
Docker
# syntax=docker/dockerfile:1
|
|
|
|
FROM node:22.23.2-alpine3.24 AS base
|
|
RUN corepack enable
|
|
WORKDIR /app
|
|
|
|
# --- Dependencies -----------------------------------------------------------
|
|
FROM base AS deps
|
|
COPY package.json pnpm-lock.yaml pnpm-workspace.yaml ./
|
|
# --ignore-scripts: postinstall generiert die Prisma-Clients aus
|
|
# prisma/schema.prisma + scripts/ — in dieser Stage noch nicht vorhanden
|
|
# (erst "COPY . ." im builder-Stage unten). Die build-Stage generiert ueber
|
|
# "pnpm build" ohnehin beide Client-Varianten, s.u.
|
|
RUN pnpm install --frozen-lockfile --ignore-scripts
|
|
|
|
# --- Build --------------------------------------------------------------
|
|
FROM base AS builder
|
|
COPY --from=deps /app/node_modules ./node_modules
|
|
COPY . .
|
|
# DATABASE_URL wird zur Build-Zeit nicht benoetigt (Prisma generate braucht
|
|
# keine Live-Verbindung), muss aber gesetzt sein, damit prisma.config.ts
|
|
# (laedt selbst kein .env im Image) nicht wegen einer fehlenden URL abbricht.
|
|
ENV DATABASE_URL="postgresql://placeholder:placeholder@localhost:5432/placeholder"
|
|
# Generiert intern beide Prisma-Client-Varianten (Postgres + MySQL, siehe
|
|
# scripts/generate-prisma-clients.mjs) und baut danach die Next.js-App — ein
|
|
# einzelnes Image, das per DATABASE_PROVIDER zur Laufzeit zwischen beiden
|
|
# Datenbanken wechseln kann, siehe lib/prisma.ts.
|
|
RUN pnpm build
|
|
|
|
# --- Migrator-Tools -----------------------------------------------------
|
|
# Eigenstaendiger, schlanker node_modules-Baum nur mit Prisma-CLI, tsx und
|
|
# den paar Laufzeit-Paketen, die prisma/seed.ts importiert — NICHT
|
|
# next/react/sharp/stripe/alle devDependencies, die der volle builder-Stage
|
|
# oben mitbringt. Wird unten in die runner-Stage kopiert, damit die App sich
|
|
# beim Start selbst migrieren/seeden kann (kein separates Migrations-Image/
|
|
# kein Kubernetes-Job mehr noetig).
|
|
FROM base AS migrator
|
|
# pnpm-workspace.yaml zuerst kopieren: pnpm v11 blockt Postinstall-Skripte
|
|
# (u.a. @prisma/engines, laedt die Schema-Engine-Binary fuer "migrate
|
|
# deploy") standardmaessig, ausser sie sind per "allowBuilds" in dieser
|
|
# Datei freigegeben. Ohne die Datei an dieser Stelle liefe "pnpm add" gegen
|
|
# ein Verzeichnis ohne jede Allowlist und wuerde die Skripte ignorieren
|
|
# ([ERR_PNPM_IGNORED_BUILDS]) -> Schema Engine fehlt -> "migrate deploy"
|
|
# schlaegt mit E_CANNOT_RESOLVE_VERSION fehl.
|
|
COPY pnpm-workspace.yaml ./
|
|
# dotenv: prisma.config.ts importiert "dotenv/config" (Vorlagen-Kommentar
|
|
# dort: "assumes you have installed ... dotenv") — im vollen builder-Stage
|
|
# oben nur ueber eine transitive Abhaengigkeit erreichbar, hier in der
|
|
# isolierten node_modules-Installation nicht automatisch mit dabei.
|
|
RUN pnpm add --save-prod \
|
|
prisma@^7.9.1 tsx@^4 bcryptjs@^3.0.3 dotenv@^17.4.2 \
|
|
@prisma/client@^7.9.1 @prisma/adapter-pg@^7.9.1 \
|
|
@prisma/adapter-mariadb@^7.9.1 mariadb@^3.5.3
|
|
|
|
# --- Runtime --------------------------------------------------------------
|
|
FROM base AS runner
|
|
ENV NODE_ENV=production
|
|
RUN addgroup --system --gid 1001 nodejs \
|
|
&& adduser --system --uid 1001 nextjs
|
|
|
|
COPY --from=builder /app/public ./public
|
|
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
|
|
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
|
|
COPY --from=builder /app/prisma ./prisma
|
|
COPY prisma.config.ts ./
|
|
COPY scripts ./scripts
|
|
COPY src/lib/db-adapter.ts ./src/lib/db-adapter.ts
|
|
COPY src/lib/password-breach-check.ts ./src/lib/password-breach-check.ts
|
|
COPY --from=builder /app/src/generated ./src/generated
|
|
# Migrations-/Seed-Pakete (prisma-CLI/tsx/dotenv) DIREKT ins selbe
|
|
# node_modules wie der Next.js-Standalone-Output kopieren (ueberlagert dort
|
|
# nur exakt dieselben Paketversionen, die builder bereits fuer next/react
|
|
# aufgeloest hat) statt in einen separaten Baum + PATH/NODE_PATH-Trick: der
|
|
# generierte Prisma-Client + tsx nutzen Node's ESM-Modulaufloesung, die
|
|
# NODE_PATH schlicht ignoriert (nur ein CommonJS-"require()"-Feature) —
|
|
# fuehrte zu "Cannot find package '@prisma/client'" beim Seed-Lauf. Die
|
|
# normale node_modules-Huelle nach oben (von jeder Datei unter /app/ aus)
|
|
# funktioniert dagegen fuer beide Modulsysteme zuverlaessig.
|
|
COPY --chown=nextjs:nodejs --from=migrator /app/node_modules ./node_modules
|
|
ENV PATH="/app/node_modules/.bin:${PATH}"
|
|
|
|
# UPLOAD_DIR (Standard "./uploads", siehe .env.example) faellt ohne diesen
|
|
# Schritt unter das root-eigene /app-Arbeitsverzeichnis: der Container laeuft
|
|
# als non-root "nextjs" (s.u.), dessen mkdir()-Aufruf in
|
|
# app/api/admin/upload*/route.ts dort ohne Schreibrecht auf /app selbst mit
|
|
# EACCES fehlschlaegt — Admin-Uploads (Bilder UND Hero-Video) scheitern dann
|
|
# ausnahmslos. Verzeichnis hier bereits VOR "USER nextjs" anlegen und
|
|
# uebereignen; docker-compose.yml mountet ausserdem ein Volume genau hierher,
|
|
# damit Uploads auch einen Container-Neustart ueberleben (siehe dort).
|
|
RUN mkdir -p /app/uploads && chown nextjs:nodejs /app/uploads
|
|
|
|
USER nextjs
|
|
EXPOSE 3000
|
|
ENV PORT=3000
|
|
ENV HOSTNAME="0.0.0.0"
|
|
|
|
# Migrationen + Seed laufen VOR dem Serverstart, damit Readiness-/Liveness-
|
|
# Probes nie gegen eine ungemigrateet Datenbank treffen — dafuer kein
|
|
# separater Kubernetes-Job mehr noetig. Beide Schritte sind idempotent
|
|
# ("migrate deploy" wendet nur neue Migrationen an, prisma/seed.ts
|
|
# legt/erneuert nur das Admin-Konto) und damit bei jedem Neustart
|
|
# gefahrlos. KEINE Beispieldaten im Image/Auto-Seed — dafuer separat
|
|
# "pnpm db:seed:demo" (prisma/seed-demo.ts), nie automatisch ausgefuehrt.
|
|
CMD ["sh", "-c", "node scripts/prisma-provider.mjs && prisma migrate deploy && prisma db seed && exec node server.js"]
|