Files
planflow/Dockerfile
T
Claude 0a15275d1b Livrer la CLI de migration dans une disposition qui tient
Le conteneur démarrait puis s'arrêtait sur « Cannot find module
'@prisma/config' ». Le Dockerfile prélevait à la main quelques répertoires de
node_modules — `prisma`, `.bin/prisma`, `@prisma` — en supposant une disposition
plate. pnpm range les dépendances dans un magasin virtuel `.pnpm`, sous des
répertoires au nom haché : la CLI arrivait sans les siennes.

Elle est désormais installée par npm, qui produit une disposition plate,
copiable telle quelle. La version est lue dans package.json plutôt que figée,
pour qu'elle ne diverge pas au premier changement.

Tout ce qui sert aux migrations — modules, schéma, configuration — vit dans un
arbre séparé. Les superposer aux modules de l'application les ferait entrer en
collision : la sortie `standalone` porte `react` en lien symbolique vers le
magasin pnpm, là où l'installation npm l'apporte en répertoire réel. Deux arbres
n'ont rien à s'écraser.

`prisma.config.ts` n'importe plus `dotenv` de façon ferme : la sortie
`standalone` n'embarque que ce que le serveur utilise, et `dotenv` n'en fait pas
partie — l'import aurait fait échouer les migrations au démarrage.

Cette fois l'image a été reconstituée à l'identique et **démarrée** : clé
produite, migrations appliquées, serveur prêt, `/connexion` en 200 et
`/api/sante` rapportant `tenantIsolation: enforced`. C'est ce que j'aurais dû
faire aux trois tentatives précédentes, où je n'avais éprouvé que des morceaux.

La simulation a d'ailleurs trouvé un chemin `/migrator` en dur dans le point
d'entrée ; il est désormais surchargeable, comme l'emplacement de la clé.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv
2026-08-09 11:09:23 +00:00

66 lines
2.7 KiB
Docker

# syntax=docker/dockerfile:1
FROM node:22-alpine AS base
RUN corepack enable
WORKDIR /app
# ---- dependencies -----------------------------------------------------------
FROM base AS deps
COPY package.json pnpm-lock.yaml ./
COPY prisma ./prisma
RUN pnpm install --frozen-lockfile
# ---- build ------------------------------------------------------------------
FROM base AS build
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN pnpm db:generate && pnpm build
# CLI Prisma pour les migrations au démarrage, installée à plat.
#
# `node_modules/prisma` de pnpm ne se recopie pas : ses dépendances vivent dans
# le magasin virtuel `.pnpm`, sous un répertoire au nom haché. En prélever
# quelques répertoires à la main donne une CLI qui se lance et s'arrête sur
# « Cannot find module '@prisma/config' ». npm produit une disposition plate,
# copiable telle quelle.
#
# La version est lue dans package.json : la figer ici la ferait diverger au
# premier changement.
RUN PRISMA_VERSION="$(node -p "require('/app/package.json').devDependencies.prisma")" \
&& npm install --prefix /migrator --no-save --no-audit --no-fund "prisma@${PRISMA_VERSION}"
# ---- runtime ----------------------------------------------------------------
FROM base AS runner
ENV NODE_ENV=production
RUN addgroup --system --gid 1001 nodejs \
&& adduser --system --uid 1001 --ingroup nodejs nextjs
# Tout ce qui sert aux migrations vit à part, dans /migrator : modules, schéma
# et fichier de configuration.
#
# Les superposer aux modules de l'application les ferait entrer en collision —
# la sortie `standalone` de pnpm porte `react` en lien symbolique vers son
# magasin interne, là où l'installation npm de la CLI l'apporte en répertoire
# réel. Deux arbres séparés n'ont rien à s'écraser.
COPY --from=build --chown=nextjs:nodejs /migrator/node_modules /migrator/node_modules
COPY --from=build --chown=nextjs:nodejs /app/prisma /migrator/prisma
COPY --from=build --chown=nextjs:nodejs /app/prisma.config.ts /migrator/prisma.config.ts
# `output: standalone` emits a server bundle carrying only the modules it uses.
COPY --from=build --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=build --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --from=build --chown=nextjs:nodejs /app/public ./public
COPY --chown=nextjs:nodejs docker/entrypoint.sh ./docker/entrypoint.sh
# Créé dans l'image, et non laissé au montage : un volume nommé hérite du
# propriétaire du répertoire qu'il recouvre, et sans cela l'application —
# qui ne tourne pas en root — ne pourrait pas y écrire.
RUN mkdir -p /data/documents /secrets && chown -R nextjs:nodejs /data /secrets
USER nextjs
EXPOSE 3000
ENV PORT=3000 HOSTNAME=0.0.0.0
CMD ["./docker/entrypoint.sh"]