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

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
-    # données RH ne doit pas être à une règle de pare-feu du monde entier.
-    expose:
-      - '5432'
+    # Le conteneur reste sur 5432 pour l'application, et le port hôte est publié
+    # sur un port non commun, configurable : plusieurs instances PostgreSQL
+    # coexistent sur le même serveur, et s'en tenir au 5432 par défaut les
+    # 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
-  # n'aurait jamais vu passer ce rôle, et l'application échouerait à
-  # s'authentifier sans que rien n'explique pourquoi. Le script est rejouable,
-  # ce service le rejoue.
+  # initialisation du volume : une base dont le volume existait déjà — ou dont
+  # le mot de passe a changé — laisserait l'application en échec
+  # d'authentification P1000, sans recours autre que du SQL à la main. Le script
+  # 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