Fusionner le provisionnement du rôle applicatif

Deux implémentations du même correctif se sont croisées. La fusion garde de
chaque côté ce qui manquait à l'autre : le traitement explicite de PGHOST venu
de main, les valeurs par défaut et le transfert de propriété des objets déjà
présents venus d'ici — sans quoi une base ayant tourné avant l'existence du rôle
resterait inexploitable par lui.

Le service db-init figurait deux fois après la fusion automatique ; il est
dédupliqué.

Le port PostgreSQL publié est **lié à la boucle locale**. Publier sert à se
connecter depuis le serveur — sauvegarde, psql — pas depuis le réseau : sans
127.0.0.1, Docker ouvre le port sur toutes les interfaces, et un jeu de données
RH derrière un mot de passe par défaut devient joignable de l'extérieur.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cr9dkEHwbDgkWPnyGj1Rjv

.env.example

@@ -1,6 +1,10 @@
 # Copier vers .env et renseigner. Ne jamais committer .env.
 
 # --- Base de données --------------------------------------------------------
+# Port hôte publié pour PostgreSQL. Non commun à dessein : plusieurs instances
+# PostgreSQL coexistent sur le même serveur, et 5432 (voire 5433) est souvent
+# déjà pris. Le conteneur app écoute toujours sur 5432 en interne.
+POSTGRES_PORT=55432
 POSTGRES_USER=planflow
 # Une valeur par défaut existe dans docker-compose.yml : la base n'étant jamais
 # publiée ni attachée au réseau du reverse-proxy, ce mot de passe protège d'un

.gitattributes

@@ -0,0 +1,5 @@
+* text=auto
+
+# Les scripts shell doivent rester en LF : le CRLF casse le shebang dans une
+# image Linux (conteneur « .../entrypoint.sh: not found »).
+*.sh text eol=lf

README.md

@@ -148,7 +148,9 @@ pnpm test:e2e    # build, serveur standalone, tests de bout en bout
 
 **L'application ne doit pas se connecter en superutilisateur PostgreSQL.**
 
-En docker-compose c'est déjà réglé : `docker/init-app-role.sh` crée au premier démarrage un rôle `planflow_app`, `NOSUPERUSER NOBYPASSRLS`, propriétaire de la base — il lui faut ce droit pour appliquer les migrations, et les politiques sont déclarées en `FORCE` précisément pour s'appliquer aussi au propriétaire.
+En docker-compose c'est déjà réglé : d'abord `docker/init-app-role.sh` au premier démarrage, puis le service `db-init` qui le rejoue **à chaque `docker compose up`** — et seulement ensuite l'application. Le rôle `planflow_app`, `NOSUPERUSER NOBYPASSRLS`, propriétaire de la base — il lui faut ce droit pour appliquer les migrations, et les politiques sont déclarées en `FORCE` précisément pour s'appliquer aussi au propriétaire.
+
+L'idempotence n'est pas un luxe : une base déjà en place dont le rôle manque (ou dont le mot de passe a changé) ne doit pas exiger de SQL à la main. Le service `db-init` corrige les deux cas à chaque relance, et l'application n'est démarrée qu'une fois sa tâche terminée.
 
 Le script ne s'exécute qu'à la **première** initialisation du volume. Sur une installation déjà en place, jouer le même SQL à la main puis basculer `DATABASE_URL` sur ce rôle.
 

docker-compose.yml

@@ -34,18 +34,26 @@ services:
     # vrai problème.
     networks:
       - interne
-    # Jamais publiée : rien hors de la pile n'a besoin de la base, et un jeu de
+    # Le conteneur reste sur 5432 pour l'application, et le port hôte est publié
-    # données RH ne doit pas être à une règle de pare-feu du monde entier.
+    # sur un port non commun, configurable : plusieurs instances PostgreSQL
-    expose:
+    # coexistent sur le même serveur, et s'en tenir au 5432 par défaut les
-      - '5432'
+    # ferait entrer en collision.
+    #
+    # **Lié à la boucle locale**, et c'est important : la publication sert à se
+    # connecter depuis le serveur (sauvegarde, psql), pas depuis le réseau. Sans
+    # `127.0.0.1`, Docker ouvre le port sur toutes les interfaces — un jeu de
+    # données RH derrière un mot de passe par défaut, joignable depuis
+    # l'extérieur. Pour un accès distant, passer par un tunnel.
+    ports:
+      - '${POSTGRES_BIND:-127.0.0.1}:${POSTGRES_PORT:-55432}:5432'
 
   # Pose le rôle applicatif à **chaque** démarrage de la pile.
   #
   # `/docker-entrypoint-initdb.d` ne s'exécute qu'à la toute première
-  # initialisation du volume : un volume créé par une tentative antérieure
+  # initialisation du volume : une base dont le volume existait déjà — ou dont
-  # n'aurait jamais vu passer ce rôle, et l'application échouerait à
+  # le mot de passe a changé — laisserait l'application en échec
-  # s'authentifier sans que rien n'explique pourquoi. Le script est rejouable,
+  # d'authentification P1000, sans recours autre que du SQL à la main. Le script
-  # ce service le rejoue.
+  # est rejouable, ce service le rejoue.
   #
   # Les identifiants du superutilisateur restent ici : les confier au conteneur
   # applicatif lui donnerait de quoi contourner la row-level security, ce que
@@ -65,6 +73,8 @@ services:
       APP_DB_PASSWORD: ${APP_DB_PASSWORD:-planflow-app-interne}
     volumes:
       - ./docker/init-app-role.sh:/init-app-role.sh:ro
+    # `entrypoint` et non `command` : l'image postgres a son propre point
+    # d'entrée, qui tenterait de démarrer un serveur.
     entrypoint: ['sh', '/init-app-role.sh']
     networks:
       - interne

docker/init-app-role.sh

@@ -14,22 +14,26 @@ set -eu
 # ni superutilisateur ni BYPASSRLS. C'est précisément pourquoi les politiques
 # sont déclarées en FORCE : elles s'appliquent aussi au propriétaire.
 #
-# Ce script est **rejouable**, et il le doit : `/docker-entrypoint-initdb.d` ne
+# Joué par le conteneur `db` à la **première** initialisation du volume, puis
-# s'exécute qu'à la toute première initialisation du volume. Une installation
+# par le service `db-init` à chaque `docker compose up`. Les deux sont
-# déjà en place — un volume créé par une tentative antérieure, par exemple —
+# nécessaires : `/docker-entrypoint-initdb.d` ne s'exécute qu'une fois, et une
-# n'aurait jamais vu passer ce rôle, et l'application échouerait à se connecter
+# installation dont le volume existait déjà n'aurait jamais vu passer ce rôle.
-# sans que rien n'explique pourquoi. Il est donc aussi joué à chaque démarrage
+# Le script est donc rejouable de bout en bout.
-# de la pile, par le service `db-init`.
 
 APP_ROLE="${APP_DB_USER:-planflow_app}"
 APP_PASSWORD="${APP_DB_PASSWORD:-planflow-app-interne}"
 DB_NAME="${POSTGRES_DB:-planflow}"
 DB_USER="${POSTGRES_USER:-planflow}"
 
-# Sans PGHOST, psql passe par la socket locale — le cas quand le script est
+# Dans le conteneur `db`, l'hôte est local ; depuis `db-init`, c'est `db`.
-# joué par l'image postgres à l'initialisation. Avec, il passe par le réseau —
+# L'un et l'autre doivent aboutir au même SQL.
-# le cas du service qui le rejoue à chaque démarrage.
+if [ -n "${PGHOST:-}" ]; then
-psql -v ON_ERROR_STOP=1 --username "$DB_USER" --dbname "$DB_NAME" <<SQL
+  set -- -h "$PGHOST" -p "${PGPORT:-5432}" -U "$DB_USER" -d "$DB_NAME" -v ON_ERROR_STOP=1
+else
+  set -- -U "$DB_USER" -d "$DB_NAME" -v ON_ERROR_STOP=1
+fi
+
+psql "$@" <<SQL
 DO \$\$
 BEGIN
   IF NOT EXISTS (SELECT FROM pg_roles WHERE rolname = '${APP_ROLE}') THEN
@@ -49,7 +53,8 @@ ALTER SCHEMA public OWNER TO ${APP_ROLE};
 GRANT ALL ON SCHEMA public TO ${APP_ROLE};
 
 -- Objets déjà créés par un compte d'amorçage : sans ce transfert, le rôle
--- applicatif ne pourrait ni migrer ni lire ce qui existe déjà.
+-- applicatif ne pourrait ni migrer ni lire ce qui existe déjà. Le cas se
+-- produit dès qu'une base a tourné avant que ce rôle n'existe.
 DO \$\$
 DECLARE
   statement text;