Nick SzaunigandClaude Sonnet 5
8ddf781d9b
Docker Image bauen und veroeffentlichen / build-and-push (push) Successful in 4m35s
Ein direkt von Kamera/Handy hochgeladenes Video (57 MB) lud spuerbar langsam: keine Kompression, kein Ton entfernt, und ohne "faststart" musste der Browser oft die gesamte Datei laden, bevor die Wiedergabe ueberhaupt beginnen konnte. Neues lib/video-transcode.ts (ffmpeg-static, per pnpm-workspace.yaml allowBuilds freigegeben) enkodiert jedes hochgeladene Video jetzt zu einem web-optimierten MP4 neu: Ton entfernt (Hero-Video ist ohnehin stumm), auf max. 1920px Breite skaliert, CRF 26 mit Bitratendeckel, "+faststart" fuer sofortigen Wiedergabestart. Nebeneffekt: ein erfolgreicher Transcode validiert das Video jetzt genauso vollstaendig wie reencodeImage() das bei Bildern schon tut (nicht mehr nur Magic-Bytes). ffmpeg-static-Binary wird in der migrator-Docker-Stage mitinstalliert (Next.js' Standalone-Tracing erkennt den Pfad hinter dem pnpm-Store-Symlink nicht zuverlaessig), lokal per npm-Postinstall ohne manuelle Einrichtung. Getestet mit synthetischem Testvideo: Transcode laeuft durch, Ausgabe enthaelt keine Audiospur mehr, ist als H.264/MP4 dekodierbar. Co-Authored-By: Claude Sonnet 5 <[email protected]>
118 lines
6.2 KiB
Docker
118 lines
6.2 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 + Laufzeit-Zusatzpakete --------------------------------
|
|
# 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).
|
|
#
|
|
# ffmpeg-static (Video-Transcoding, siehe lib/video-transcode.ts) landet
|
|
# bewusst HIER statt per Next.js' automatischer Standalone-Output-Tracing
|
|
# aus der builder-Stage: dessen heruntergeladene ffmpeg-Binary liegt im
|
|
# pnpm-Store hinter einem Symlink, den Next.js' Tracer (anders als bei
|
|
# sharp, dafuer gibt es eine Sonderbehandlung) nicht zuverlaessig erkennt,
|
|
# UND ein direktes COPY einzelner Pakete aus dem pnpm-Store der
|
|
# builder-Stage wuerde denselben Symlink lediglich unaufgeloest (und damit
|
|
# kaputt) in die runner-Stage kopieren. Diese Stage installiert stattdessen
|
|
# jedes benoetigte Laufzeitpaket ueber ein eigenes, in sich geschlossenes
|
|
# "pnpm add" neu — genau das Muster, das fuer Prisma/tsx hier bereits
|
|
# funktioniert.
|
|
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 \
|
|
ffmpeg-static@^5.3.0
|
|
|
|
# --- 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"]
|