L'utilisateur signale devoir recréer un compte admin après chaque
déploiement en prod. Cause : docker-compose.prod.yml ne montait un
volume que pour /app/projects (les jeux) — la base des comptes créateurs
(data/users.db, voir auth/connection.py) et la clé de session Flask
(data/secret_key, voir core/flask_app.py::_load_or_create_secret_key)
vivaient toutes les deux dans /app/data, jamais monté : chaque nouveau
conteneur (à chaque déploiement) repartait d'un /app/data vide, donc
d'une base de comptes vide ("premier compte = admin" recommençait à
zéro) ET d'une nouvelle clé de session (tout le monde déconnecté, en
plus de la perte du compte).
Nouveau volume nommé forge_data:/app/data, à côté de forge_projects.
docker-entrypoint.sh corrige aussi sa propriété (root par défaut à la
création d'un volume nommé, comme pour forge_projects déjà) avant
d'abandonner les privilèges root.
Note : ce correctif ne prend effet qu'au déploiement SUIVANT sur main
(le conteneur actuellement en prod n'a pas ce volume) — un dernier compte
admin à recréer après ce déploiement, plus jamais ensuite.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
su forge -s /bin/sh -c 'exec "$@"' -- "$@" didn't forward gunicorn's
argv correctly with this image's su, so the container never actually
started gunicorn — Caddy then had nothing to proxy to (502). Flatten
the command into a single string via "$*" instead.
The named Docker volume mounted at /app/projects is created by Docker
as root before the container starts, so the image's build-time chown
never applies to it. A root-owned volume made the app (running as the
non-root forge user) unable to write new game folders in production.
Add an entrypoint that chowns /app/projects to forge at each startup,
then drops privileges before exec'ing gunicorn.