Nick Szaunig
05876838b0
Bisher wurde nirgends automatisch ein erster Admin-User angelegt - prisma/seed.ts existierte, war aber weder im Dockerfile-CMD noch sonst irgendwo verdrahtet. Auf einer frischen Datenbank haette also niemand sich einloggen koennen. - Dockerfile-CMD: migrate:deploy && seed && node dist/main.js - ts-node/typescript von devDependencies zu dependencies verschoben (seed.ts laeuft als rohes TypeScript zur Laufzeit, kein Kompilierschritt), tsconfig.json zusaetzlich ins Runtime-Image kopiert - seed.ts gegen Unique-Constraint-Race bei mehreren gleichzeitig startenden Pod-Replicas gehaertet (P2002 abgefangen statt Absturz) - Login-Banner im Log nur beim tatsaechlichen Erst-Anlegen (URL aus FRONTEND_ORIGIN, Benutzername, Passwort) - bewusst nicht bei jedem Neustart, sonst wuerden veraltete/geaenderte Zugangsdaten weiter geloggt und Credentials landen unnoetig dauerhaft in den Logs Seed ist bereits idempotent per E-Mail-Check (auch bei deaktivierten Usern), UsersService.assertNotLastSystemRoleUser verhindert ohnehin das Deaktivieren des letzten aktiven Admins - kein Aenderungsbedarf dort, siehe Konversation. Verifiziert: tsc/eslint clean, 297/297 Tests, Build clean. Migration und Schema live gegen die lokale DB bestaetigt (ueber WSL direkt, da Windows->WSL-Portweiterleitung weiterhin kaputt ist); der eigentliche Seed-Lauf selbst konnte nicht End-to-End gegen die DB verifiziert werden (gleiches Verbindungsproblem), Banner-Ausgabe isoliert smoke-getestet.
32 lines
1.2 KiB
Docker
32 lines
1.2 KiB
Docker
# syntax=docker/dockerfile:1
|
|
|
|
FROM node:22-alpine AS builder
|
|
WORKDIR /app
|
|
COPY package.json package-lock.json ./
|
|
RUN npm ci
|
|
COPY . .
|
|
RUN npx prisma generate
|
|
RUN npm run build
|
|
|
|
FROM node:22-alpine AS runtime
|
|
ENV NODE_ENV=production
|
|
WORKDIR /app
|
|
COPY package.json package-lock.json ./
|
|
RUN npm ci --omit=dev
|
|
COPY --from=builder /app/dist ./dist
|
|
COPY --from=builder /app/generated ./generated
|
|
# schema.prisma, migrations/, seed.ts und prisma.config.ts: noetig fuer
|
|
# `npm run migrate:deploy` und `npm run seed`, die der Container beim Start
|
|
# selbst ausfuehrt (siehe CMD unten), bevor der Server Verbindungen annimmt.
|
|
# tsconfig.json: ts-node (Laufzeit-Dependency, siehe package.json) braucht es,
|
|
# um seed.ts direkt auszufuehren, ohne separaten Kompilierschritt.
|
|
COPY --from=builder /app/prisma ./prisma
|
|
COPY --from=builder /app/prisma.config.ts ./prisma.config.ts
|
|
COPY --from=builder /app/tsconfig.json ./tsconfig.json
|
|
EXPOSE 3001
|
|
USER node
|
|
# migrate deploy ist idempotent und nutzt einen DB-seitigen Advisory-Lock,
|
|
# seed ist idempotent per Unique-Constraint auf User.email (siehe seed.ts) -
|
|
# beides unproblematisch bei mehreren gleichzeitig startenden Pod-Replicas.
|
|
CMD ["sh", "-c", "npm run migrate:deploy && npm run seed && node dist/main.js"]
|