Claude
0a15275d1b
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
63 lines
2.8 KiB
Bash
Executable File
63 lines
2.8 KiB
Bash
Executable File
#!/bin/sh
|
|
set -eu
|
|
|
|
# Démarrage du conteneur applicatif.
|
|
#
|
|
# La clé de chiffrement protège le NIR, l'IBAN, les secrets de second facteur et
|
|
# les pièces du dossier salarié. Elle doit exister avant que quoi que ce soit
|
|
# démarre — mais l'exiger en variable d'environnement rendait tout déploiement
|
|
# impossible sans une étape manuelle, et une variable d'environnement n'est de
|
|
# toute façon pas un bon coffre : elle s'affiche dans `docker inspect` et dans
|
|
# l'interface de gestion.
|
|
#
|
|
# Elle est donc produite au premier démarrage et conservée dans un volume
|
|
# **distinct** de la base et des documents : une sauvegarde de l'un ne doit pas
|
|
# emporter la clé de l'autre.
|
|
#
|
|
# `ENCRYPTION_KEY` fournie explicitement l'emporte toujours : un déploiement qui
|
|
# gère ses secrets par ailleurs ne doit pas être contrarié.
|
|
|
|
KEY_FILE="${ENCRYPTION_KEY_FILE:-/secrets/encryption.key}"
|
|
# Surchargeable pour pouvoir éprouver ce script hors d'une image.
|
|
MIGRATOR_DIR="${MIGRATOR_DIR:-/migrator}"
|
|
|
|
if [ -z "${ENCRYPTION_KEY:-}" ]; then
|
|
if [ -f "$KEY_FILE" ]; then
|
|
ENCRYPTION_KEY="$(cat "$KEY_FILE")"
|
|
else
|
|
mkdir -p "$(dirname "$KEY_FILE")"
|
|
ENCRYPTION_KEY="$(node -e "process.stdout.write(require('node:crypto').randomBytes(32).toString('base64'))")"
|
|
# Écriture puis restriction : le fichier ne doit jamais être lisible par
|
|
# d'autres, même brièvement.
|
|
(umask 077; printf '%s' "$ENCRYPTION_KEY" > "$KEY_FILE")
|
|
|
|
echo ''
|
|
echo '════════════════════════════════════════════════════════════════'
|
|
echo ' Clé de chiffrement produite au premier démarrage.'
|
|
echo ''
|
|
echo " $ENCRYPTION_KEY"
|
|
echo ''
|
|
echo ' Conservez-la hors de ce serveur. Sans elle, le NIR, les IBAN et'
|
|
echo ' les pièces du dossier salarié sont définitivement illisibles.'
|
|
echo ''
|
|
echo " Elle est stockée dans $KEY_FILE, sur un volume distinct de la"
|
|
echo ' base et des documents — à sauvegarder séparément.'
|
|
echo '════════════════════════════════════════════════════════════════'
|
|
echo ''
|
|
fi
|
|
fi
|
|
|
|
export ENCRYPTION_KEY
|
|
|
|
# Les migrations s'appliquent au démarrage : l'image se déploie sans étape
|
|
# séparée.
|
|
#
|
|
# Depuis /migrator, arbre séparé de celui de l'application : la CLI y trouve ses
|
|
# propres dépendances, et le fichier de configuration y résout `prisma/config`.
|
|
# Appelée par son chemin plutôt que par `.bin/prisma` — un lien symbolique
|
|
# recopié d'une image à l'autre est une dépendance de plus à la disposition des
|
|
# fichiers, et c'est exactement ce qui a cassé ici.
|
|
( cd "$MIGRATOR_DIR" && node node_modules/prisma/build/index.js migrate deploy )
|
|
|
|
exec node server.js
|