[infra] Faire tourner PostgreSQL 17 et TimescaleDB sur Docker

olivier commented

2026-09-02 09:55:45 +00:00

Member

Exigence couverte

ENF-08, ENF-09, ENF-12, ENF-14

Épreuve servie

EC04 · Cloud et sécurisation

Charge estimée

0,5 j.h

Ce qu'on veut obtenir

Sortir PostgreSQL 17 et TimescaleDB des paquets Debian et les faire tourner dans un conteneur, pour que le service de base se décrive, se reconstruise et se relise depuis le dépôt comme le reste de l'infrastructure. Aujourd'hui l'installation ne vit que sur la machine : sa configuration est dans /etc/postgresql/17/main, éditée à la main, et le seul endroit qui la décrit est une page de documentation qui peut diverger sans que rien le détecte.

Le port (5433), les noms de bases, la collation fr_FR.UTF-8 et les valeurs de dimensionnement ne changent pas : un client existant ne doit voir aucune différence, hors accès distant (voir #65).

Ce ticket porte aussi la mise en conformité des rôles et des bases avec la cible arrêtée : quatre rôles applicatifs, trois bases, chaque rôle sur sa seule base, aucun accès réseau pour le superutilisateur, et retrait du rôle keycloak.

Critères d'acceptation

La pile est versionnée dans infra/compose/postgres/ : image, compose, configuration, scripts. Le fichier .env rempli et la clé TLS restent hors dépôt.
L'image épingle PostgreSQL 17.11, TimescaleDB 2.29.2, le toolkit 1.25.0 et les outils 0.19.0, et sa construction échoue si l'une des trois ne correspond pas ou si la locale fr_FR.UTF-8 manque.
Les trois bases sont en fr_FR.UTF-8, enervision_prod et enervision_preprod portent timescaledb 2.29.2.
Quatre rôles (enervision_prod, enervision_preprod, mlflow, grafana), aucun superutilisateur, aucun CREATEDB ni CREATEROLE. Le rôle et la base keycloak ne sont pas repris.
Chaque rôle ne joint que sa base, et le superutilisateur n'a aucun accès TCP.
grafana est en lecture seule sur enervision_prod, y compris sur les tables créées après coup.
Le schéma ops d'enervision_preprod est repris sans perte, vérifié par empreinte.
La sauvegarde tourne, lit la liste des bases au catalogue, et un contrôle dit si chaque vidage est lisible.
docs/POSTGRESQL.md et docs/runbooks/postgresql.md décrivent l'état et les gestes réels, et toute commande publiée a été exécutée.
Le cluster natif est arrêté et ne peut pas remonter au démarrage de la machine, mais reste disponible comme retour arrière.

Comment on le vérifie

Commande   docker compose ps ; batterie d'essais d'accès par paire (base, rôle)
Attendu    conteneur « Up (healthy) » ; les quatre rôles admis sur leur base,
           refusés partout ailleurs ; superutilisateur refusé en TCP
Preuve     sortie de la batterie, empreintes md5 du schéma ops avant et après,
           restauration à côté des trois bases, épreuve de redémarrage

Manuel d'exploitation à mettre à jour

docs/POSTGRESQL.md (état et configuration), docs/runbooks/postgresql.md (tous les gestes changent de forme), infra/compose/postgres/README.md (la pile), docs/runbooks/README.md et infra/compose/README.md (index).

Risque et retour arrière

Le risque principal est la perte d'écritures pendant la bascule : la base est en service et un coéquipier peut écrire au moment du vidage. Il faut geler l'accès réseau du cluster natif puis revider, et non l'inverse.

Retour arrière : le cluster natif, ses paquets et son répertoire de données sont conservés. Il suffit de démasquer l'unité, de remettre start.conf à auto et d'arrêter le conteneur pour retrouver l'état précédent. Un vidage complet d'avant migration est conservé hors rétention.

### Exigence couverte ENF-08, ENF-09, ENF-12, ENF-14 ### Épreuve servie EC04 · Cloud et sécurisation ### Charge estimée 0,5 j.h ### Ce qu'on veut obtenir Sortir PostgreSQL 17 et TimescaleDB des paquets Debian et les faire tourner dans un conteneur, pour que le service de base se décrive, se reconstruise et se relise depuis le dépôt comme le reste de l'infrastructure. Aujourd'hui l'installation ne vit que sur la machine : sa configuration est dans `/etc/postgresql/17/main`, éditée à la main, et le seul endroit qui la décrit est une page de documentation qui peut diverger sans que rien le détecte. Le port (5433), les noms de bases, la collation `fr_FR.UTF-8` et les valeurs de dimensionnement ne changent pas : un client existant ne doit voir aucune différence, hors accès distant (voir #65). Ce ticket porte aussi la mise en conformité des rôles et des bases avec la cible arrêtée : quatre rôles applicatifs, trois bases, chaque rôle sur sa seule base, aucun accès réseau pour le superutilisateur, et retrait du rôle `keycloak`. ### Critères d'acceptation - [x] La pile est versionnée dans `infra/compose/postgres/` : image, compose, configuration, scripts. Le fichier `.env` rempli et la clé TLS restent hors dépôt. - [x] L'image épingle PostgreSQL 17.11, TimescaleDB 2.29.2, le toolkit 1.25.0 et les outils 0.19.0, et sa construction échoue si l'une des trois ne correspond pas ou si la locale `fr_FR.UTF-8` manque. - [x] Les trois bases sont en `fr_FR.UTF-8`, `enervision_prod` et `enervision_preprod` portent `timescaledb 2.29.2`. - [x] Quatre rôles (`enervision_prod`, `enervision_preprod`, `mlflow`, `grafana`), aucun superutilisateur, aucun `CREATEDB` ni `CREATEROLE`. Le rôle et la base `keycloak` ne sont pas repris. - [x] Chaque rôle ne joint que sa base, et le superutilisateur n'a aucun accès TCP. - [x] `grafana` est en lecture seule sur `enervision_prod`, y compris sur les tables créées après coup. - [x] Le schéma `ops` d'`enervision_preprod` est repris sans perte, vérifié par empreinte. - [x] La sauvegarde tourne, lit la liste des bases au catalogue, et un contrôle dit si chaque vidage est lisible. - [x] `docs/POSTGRESQL.md` et `docs/runbooks/postgresql.md` décrivent l'état et les gestes réels, et toute commande publiée a été exécutée. - [x] Le cluster natif est arrêté et ne peut pas remonter au démarrage de la machine, mais reste disponible comme retour arrière. ### Comment on le vérifie ``` Commande docker compose ps ; batterie d'essais d'accès par paire (base, rôle) Attendu conteneur « Up (healthy) » ; les quatre rôles admis sur leur base, refusés partout ailleurs ; superutilisateur refusé en TCP Preuve sortie de la batterie, empreintes md5 du schéma ops avant et après, restauration à côté des trois bases, épreuve de redémarrage ``` ### Manuel d'exploitation à mettre à jour `docs/POSTGRESQL.md` (état et configuration), `docs/runbooks/postgresql.md` (tous les gestes changent de forme), `infra/compose/postgres/README.md` (la pile), `docs/runbooks/README.md` et `infra/compose/README.md` (index). ### Risque et retour arrière Le risque principal est la perte d'écritures pendant la bascule : la base est en service et un coéquipier peut écrire au moment du vidage. Il faut geler l'accès réseau du cluster natif **puis** revider, et non l'inverse. Retour arrière : le cluster natif, ses paquets et son répertoire de données sont conservés. Il suffit de démasquer l'unité, de remettre `start.conf` à `auto` et d'arrêter le conteneur pour retrouver l'état précédent. Un vidage complet d'avant migration est conservé hors rétention.

olivier added the

labels

2026-09-02 09:55:45 +00:00

olivier referenced this issue from a commit

2026-09-02 09:56:47 +00:00

infra: ferme l'acces distant a PostgreSQL et passe par un tunnel SSH

olivier referenced this issue from a pull request that will close it,