Multi-stage build on node:22-alpine, standalone output, non-root user, healthcheck on /api/health, and migrations applied by the entrypoint before the first request. A failed migration stops the container rather than serving an inconsistent database. Getting the Prisma CLI into the runtime image took three attempts and the reasoning is recorded in the Dockerfile. Copying it out of the build stage leaves its transitive dependencies behind; patching them in one at a time is a losing game. It now gets its own stage and its own tree, with the schema and prisma.config.ts beside it, and the entrypoint runs from there so every import resolves locally. The version is read from our own package.json so it cannot drift from the generated client. Two things had to change to build without a database, which a build container rightly does not have. prisma.config.ts no longer reads the URL through prisma's env() helper, which throws on a missing variable even for `generate`. And lib/db.ts creates the client on first use rather than on import: Next imports every route module while collecting page data, so a module that threw on import failed the build with an error naming whichever route was analysed first, which says nothing useful. The failure now lands on the first query, where it belongs. Verified by running the image against a real database: migrations applied, cron scheduled in Europe/Zurich, a device paired, and the panel image served as a genuine 1-bit 800x480 BMP — so satori, resvg and the vendored fonts all work on musl. The image hash came out identical to the one produced on the glibc host, which is the reproducibility the vendored fonts were for. The production overlay publishes through an existing Traefik, drops the host port, mounts the filesystem read-only, and adds a nightly dump kept for a fortnight. README and DEPLOY are in French and cover what actually bites: the panel receives nothing and only updates when it wakes; the issuer must match to the character; the captive portal URL takes no trailing slash; a rollback across a migration needs the dump, because Prisma does not undo one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012cSY9pVhZmJUKNN7wf1Myd
5.0 KiB
Déploiement
Procédures d'exploitation pour horaires.ita-ito.com. Le README
couvre l'installation locale et la configuration d'Authentik.
Première installation sur le VPS
Prérequis : Docker, Docker Compose, et un Traefik déjà en route possédant le
réseau externe nommé par TRAEFIK_NETWORK.
git clone <dépôt> /opt/horaires && cd /opt/horaires
cp .env.example .env
sed -i "s|^AUTH_SECRET=.*|AUTH_SECRET=$(openssl rand -base64 33)|" .env
sed -i "s|^POSTGRES_PASSWORD=.*|POSTGRES_PASSWORD=$(openssl rand -base64 24)|" .env
# Renseignez APP_DOMAIN, AUTH_URL, AUTH_AUTHENTIK_*, TRANSLATION_API_KEY.
mkdir -p backups
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build --wait
Les migrations s'appliquent au démarrage. Si elles échouent, le conteneur
s'arrête avant de servir quoi que ce soit, plutôt que d'exposer une base
incohérente : docker compose logs app dira pourquoi.
Ensuite :
docker compose exec app node .migrator/node_modules/prisma/build/index.js migrate status
curl -fsS https://horaires.ita-ito.com/api/health
Puis, une fois connecté : Paramètres pour le canton et les intervalles de réveil, Fériés → Synchroniser maintenant, Horaires pour la vraie semaine, et enfin l'appairage de l'écran (README).
Mise à jour
cd /opt/horaires
./scripts/backup.sh # ou attendre le dump nocturne
git pull
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build --wait
docker compose logs -f app # ^C une fois « démarrage de l'application »
--wait rend la main seulement quand le healthcheck passe. S'il ne passe pas,
la mise à jour a échoué et l'ancien conteneur a déjà été remplacé : voir le
retour arrière ci-dessous.
Avant une mise à jour qui touche au rendu (polices, gabarit, logo), sachez que le nom de fichier de l'image change et que tous les écrans redessineront une fois. C'est sans gravité, seulement un cycle de batterie.
Sauvegarde
Le service backup dépose un dump compressé par jour dans ./backups et purge
au-delà de BACKUP_KEEP_DAYS (14 par défaut).
Dump immédiat :
docker compose exec -T db pg_dump -U horaires horaires | gzip > backups/horaires-$(date +%Y%m%d-%H%M%S).sql.gz
Ces fichiers contiennent les horaires, les messages et le journal d'audit. Ils
ne contiennent aucun secret : les jetons d'appareil n'y figurent que sous
forme d'empreintes, et les identifiants Authentik vivent dans .env, qui n'est
pas dans les sauvegardes. Sauvegardez .env séparément, ailleurs.
Restauration
docker compose -f docker-compose.yml -f docker-compose.prod.yml stop app
gunzip -c backups/horaires-20260920-030000.sql.gz \
| docker compose exec -T db psql -U horaires -d horaires
docker compose -f docker-compose.yml -f docker-compose.prod.yml start app
Après une restauration, les écrans appairés depuis le dump ne le sont plus du point de vue de la base : ils recevront un 401 et devront être réappairés par le portail captif. Rien d'autre ne se perd.
Retour arrière
L'image porte la version du dépôt, donc revenir en arrière veut dire revenir au commit :
git log --oneline -10
git checkout <commit-précédent>
docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --build --wait
Si la mise à jour comportait une migration, revenir au code ne suffit pas : le schéma est déjà migré. Prisma ne défait pas une migration. Restaurez alors le dump pris avant la mise à jour, puis reprenez le code. C'est la raison d'être de la sauvegarde préalable.
Ce qu'il faut surveiller
| Signe | Où | Que faire |
|---|---|---|
| L'écran n'a pas donné signe de vie | alerte du tableau de bord | batterie, puis Wi-Fi de la boutique |
| Synchro des fériés en échec | alerte, page Fériés | le cache local tient ; relancer à la main |
| Messages sans traduction | alerte, page Messages | npm run translate:test pour savoir pourquoi |
| Conteneur unhealthy | docker compose ps |
docker compose logs app |
Le panneau tombe sur le certificat TLS
Certains firmwares ESP32 échouent sur une chaîne de certificats que tous les
navigateurs acceptent. Si l'écran n'arrive à joindre le serveur qu'en clair,
DEVICE_ALLOW_HTTP=true existe — mais c'est le dernier recours, pas le premier.
Dans l'ordre :
- Vérifiez que l'écran atteint bien le domaine :
docker compose logs app | grep /api/setup. - Vérifiez la chaîne servie :
openssl s_client -connect horaires.ita-ito.com:443 -servername horaires.ita-ito.com | head -20. Une chaîne incomplète est le cas le plus fréquent et se corrige côté Traefik, pas côté écran. - En dernier recours seulement, exposez un hôte virtuel en clair réservé aux
routes
/api/setup,/api/display,/api/loget/api/device/image/*. Le jeton d'appareil circulerait alors en clair : il est distinct de tout autre secret et révocable depuis Paramètres → Appareils, ce qui rend l'arbitrage tenable — mais l'administration, elle, reste en TLS.