Wabenhain/Dockerfile

# 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
# System-ffmpeg statt des npm-Pakets ffmpeg-static (lib/video-transcode.ts
# nutzt es lokal per "npm run dev" trotzdem als Fallback, siehe dort):
# ffmpeg-static laedt seine Binary in den pnpm-Store, dessen Pfad ueber
# mehrere Docker-Build-Stages hinweg (migrator -> runner) per COPY nicht
# zuverlaessig ankam (spawn ... ffmpeg ENOENT im Betrieb beobachtet). Ein
# per apk installiertes System-Paket liegt dagegen fest unter /usr/bin auf
# PATH, unabhaengig von jeder Node/pnpm-Verzeichnisstruktur.
RUN apk add --no-cache ffmpeg
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"]