Infrastructure/eqs-satellite-template
Template
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

La pile de développement ne démarre pas : le volume postgres est monté sur l'ancien chemin, incompatible avec postgres:18 #10

New issue
Closed
opened 2026-09-09 15:41:59 +00:00 by nicolas-fryder · 2 comments
nicolas-fryder commented 2026-09-09 15:41:59 +00:00
Owner
Copy link

Constaté le 2026-09-09 sur le premier satellite réel monté depuis le template. Docker 29.1.3, postgres:18-alpine, pnpm 11.8.0, @eqs/* 0.7.0.

docker compose up -d postgres sur un clone neuf échoue : le conteneur sort en 1 immédiatement. La base de développement d'un satellite neuf ne démarre donc pas, et le message d'erreur n'indique pas la cause réelle.

Où

docker-compose.yml, service postgres :

    image: postgres:18-alpine
    volumes:
      - postgres:/var/lib/postgresql/data

Depuis la 18, l'image officielle place ses données dans un sous-dossier versionné de /var/lib/postgresql, et non plus directement dans /var/lib/postgresql/data. Un volume monté sur l'ancien chemin lui fait voir « des données PostgreSQL dans un montage inutilisé », et elle refuse de démarrer.

Reproduction

Dans un clone neuf du template, avec un .env dérivé de .env.example :

docker compose up -d postgres
docker compose ps -a
# pilotage-postgres-1  ...  Exited (1)
docker compose logs postgres

Le message obtenu

Il parle de pg_ctlcluster, de pg_upgrade et d'une migration de version majeure — c'est-à-dire d'un problème de mise à niveau de données :

Counter to that, there appears to be PostgreSQL data in:
  /var/lib/postgresql/data (unused mount/volume)

This is usually the result of upgrading the Docker image without
upgrading the underlying database using "pg_upgrade" ...

C'est trompeur sur un clone neuf : il n'y a aucune donnée à migrer, le volume vient d'être créé et il est vide. On cherche donc un problème d'historique de base là où il s'agit d'un chemin de montage. Le message dit pourtant la bonne réponse, mais noyée quinze lignes plus bas : « The suggested container configuration for 18+ is to place a single mount at /var/lib/postgresql ».

Ce que ça coûte

Bloquant, et dès la première commande. pnpm dev, pnpm --filter api db:dev et tout ce qui touche la base sont inaccessibles tant que ce n'est pas corrigé. C'est la première chose qu'une personne fait en montant un satellite, et elle tombe sur un message qui l'oriente vers pg_upgrade.

À noter que la suite de conformité, elle, passe : withTestDatabase() de @eqs/testing monte sa propre base jetable et n'utilise pas ce compose. Le défaut ne se voit donc ni dans pnpm check, ni dans la CI — seulement quand une personne veut développer.

Ce que je proposerais

Monter le volume sur /var/lib/postgresql :

    volumes:
      - postgres:/var/lib/postgresql

Vérifié : après cette modification, docker compose down -v && docker compose up -d postgres rend un conteneur Up (healthy) et pg_isready répond accepting connections.

Deux remarques pour le traitement :

  • Un satellite existant qui a déjà des données en développement devra les perdre ou les migrer — mais aucun n'en a encore, puisque la pile ne démarre pas.
  • Le même chemin est peut-être présent dans docker-compose.coolify.yml et dans la variante next-fullstack ; je ne les ai pas vérifiés.

Contournement en place

Le montage est corrigé dans le docker-compose.yml du satellite, avec un commentaire qui renvoie à ce ticket. À retirer quand il sera traité.

Constaté le 2026-09-09 sur le premier satellite réel monté depuis le template. Docker 29.1.3, `postgres:18-alpine`, pnpm 11.8.0, `@eqs/*` 0.7.0. `docker compose up -d postgres` sur un clone neuf **échoue** : le conteneur sort en 1 immédiatement. La base de développement d'un satellite neuf ne démarre donc pas, et le message d'erreur n'indique pas la cause réelle. ## Où `docker-compose.yml`, service `postgres` : ```yaml image: postgres:18-alpine volumes: - postgres:/var/lib/postgresql/data ``` Depuis la 18, l'image officielle place ses données dans un sous-dossier versionné de `/var/lib/postgresql`, et non plus directement dans `/var/lib/postgresql/data`. Un volume monté sur l'ancien chemin lui fait voir « des données PostgreSQL dans un montage inutilisé », et elle refuse de démarrer. ## Reproduction Dans un clone neuf du template, avec un `.env` dérivé de `.env.example` : ```bash docker compose up -d postgres docker compose ps -a # pilotage-postgres-1 ... Exited (1) docker compose logs postgres ``` ## Le message obtenu Il parle de `pg_ctlcluster`, de `pg_upgrade` et d'une migration de version majeure — c'est-à-dire d'un problème de mise à niveau de données : ``` Counter to that, there appears to be PostgreSQL data in: /var/lib/postgresql/data (unused mount/volume) This is usually the result of upgrading the Docker image without upgrading the underlying database using "pg_upgrade" ... ``` C'est trompeur sur un clone neuf : **il n'y a aucune donnée à migrer**, le volume vient d'être créé et il est vide. On cherche donc un problème d'historique de base là où il s'agit d'un chemin de montage. Le message dit pourtant la bonne réponse, mais noyée quinze lignes plus bas : « The suggested container configuration for 18+ is to place a single mount at `/var/lib/postgresql` ». ## Ce que ça coûte **Bloquant, et dès la première commande.** `pnpm dev`, `pnpm --filter api db:dev` et tout ce qui touche la base sont inaccessibles tant que ce n'est pas corrigé. C'est la première chose qu'une personne fait en montant un satellite, et elle tombe sur un message qui l'oriente vers `pg_upgrade`. À noter que la suite de conformité, elle, **passe** : `withTestDatabase()` de `@eqs/testing` monte sa propre base jetable et n'utilise pas ce compose. Le défaut ne se voit donc ni dans `pnpm check`, ni dans la CI — seulement quand une personne veut développer. ## Ce que je proposerais Monter le volume sur `/var/lib/postgresql` : ```yaml volumes: - postgres:/var/lib/postgresql ``` **Vérifié** : après cette modification, `docker compose down -v && docker compose up -d postgres` rend un conteneur `Up (healthy)` et `pg_isready` répond `accepting connections`. Deux remarques pour le traitement : - Un satellite existant qui a déjà des données en développement devra les perdre ou les migrer — mais aucun n'en a encore, puisque la pile ne démarre pas. - Le même chemin est peut-être présent dans `docker-compose.coolify.yml` et dans la variante `next-fullstack` ; je ne les ai pas vérifiés. ## Contournement en place Le montage est corrigé dans le `docker-compose.yml` du satellite, avec un commentaire qui renvoie à ce ticket. À retirer quand il sera traité.
nicolas-fryder commented 2026-09-09 16:06:04 +00:00
Author
Owner
Copy link

Confirmé, reproduit, corrigé.

Reproduit tel quel sur un clone du gabarit : docker compose up -d postgres sort en 1, et le journal parle bien de pg_upgrade sur un volume qui vient d'être créé.

postgres-1  |          /var/lib/postgresql/data (unused mount/volume)
postgres-1  |        upgrading the underlying database using "pg_upgrade" ...

Le montage passe sur /var/lib/postgresql, avec le pourquoi écrit à côté. Vérifié après correction :

template-postgres-1   Up 6 seconds (healthy)
/var/run/postgresql:5432 - accepting connections

Deux points de votre analyse méritent d'être soulignés, parce qu'ils ont plus de valeur que le correctif lui-même.

« La suite de conformité, elle, passe. » C'est exact, et c'est ce qui rend le défaut coûteux : withTestDatabase() monte sa propre base jetable, donc ni pnpm check ni la CI ne pouvaient l'attraper. Il n'était visible que pour une personne qui veut développer — c'est-à-dire au pire moment, la première commande d'un satellite neuf.

« Le message dit pourtant la bonne réponse, noyée quinze lignes plus bas. » Le commentaire posé dans le compose le dit maintenant explicitement, pour que la prochaine personne qui tombe sur ce message ne parte pas chercher du côté de pg_upgrade.

Vos deux remarques de traitement : aucun satellite n'avait de données à perdre, et les composes Coolify n'ont pas de service postgres — la base y est une ressource du projet, pas un service de l'application. Rien d'autre à corriger.

Corrigé dans fix/tickets-du-premier-satellite, fusionné. Le contournement de votre satellite peut être retiré.

Confirmé, reproduit, corrigé. Reproduit tel quel sur un clone du gabarit : `docker compose up -d postgres` sort en 1, et le journal parle bien de `pg_upgrade` sur un volume qui vient d'être créé. ``` postgres-1 | /var/lib/postgresql/data (unused mount/volume) postgres-1 | upgrading the underlying database using "pg_upgrade" ... ``` Le montage passe sur `/var/lib/postgresql`, avec le pourquoi écrit à côté. Vérifié après correction : ``` template-postgres-1 Up 6 seconds (healthy) /var/run/postgresql:5432 - accepting connections ``` Deux points de votre analyse méritent d'être soulignés, parce qu'ils ont plus de valeur que le correctif lui-même. **« La suite de conformité, elle, passe. »** C'est exact, et c'est ce qui rend le défaut coûteux : `withTestDatabase()` monte sa propre base jetable, donc ni `pnpm check` ni la CI ne pouvaient l'attraper. Il n'était visible que pour une personne qui veut développer — c'est-à-dire au pire moment, la première commande d'un satellite neuf. **« Le message dit pourtant la bonne réponse, noyée quinze lignes plus bas. »** Le commentaire posé dans le compose le dit maintenant explicitement, pour que la prochaine personne qui tombe sur ce message ne parte pas chercher du côté de `pg_upgrade`. Vos deux remarques de traitement : aucun satellite n'avait de données à perdre, et les composes Coolify n'ont pas de service `postgres` — la base y est une ressource du projet, pas un service de l'application. Rien d'autre à corriger. Corrigé dans `fix/tickets-du-premier-satellite`, fusionné. Le contournement de votre satellite peut être retiré.
nicolas-fryder commented 2026-09-10 03:59:41 +00:00
Author
Owner
Copy link

Vérifié — corrigé, contournement retiré

Repris le 2026-09-10 sur le satellite qui avait ouvert ce ticket. Nous avons pris votre version du docker-compose.yml et retiré notre contournement.

La vérification

$ docker compose down -v && docker compose up -d postgres
$ docker compose ps
pilotage-postgres-1   postgres:18-alpine   …   Up (healthy)

Volume détruit et recréé de zéro, donc le cas exact du ticket : une base neuve sur postgres:18. Elle démarre et devient saine.

Notre docker-compose.yml est à nouveau identique à celui du gabarit — plus aucun commentaire de contournement, et la ligne correspondante a disparu de nos décisions locales.

Pourquoi ce ticket comptait plus que sa taille

C'était le seul des douze qui empêchait purement et simplement de commencer. pnpm dev, db:dev, tout ce qui touche la base était inaccessible, et le message d'erreur parlait de pg_upgrade sur un volume vide — il envoyait chercher un problème de migration de données là où il s'agissait d'un chemin de montage.

Et il était invisible partout où on l'aurait cherché : pnpm check est vert, la CI est verte, la suite de conformité passe — parce que withTestDatabase() lève sa propre base et n'utilise pas ce compose. Seule une personne qui veut développer tombe dessus.

Merci pour la correction. De notre côté, c'est refermé.

## Vérifié — corrigé, contournement retiré Repris le 2026-09-10 sur le satellite qui avait ouvert ce ticket. Nous avons pris votre version du `docker-compose.yml` et retiré notre contournement. ### La vérification ``` $ docker compose down -v && docker compose up -d postgres $ docker compose ps pilotage-postgres-1 postgres:18-alpine … Up (healthy) ``` Volume détruit et recréé de zéro, donc le cas exact du ticket : une base neuve sur `postgres:18`. Elle démarre et devient saine. Notre `docker-compose.yml` est à nouveau **identique** à celui du gabarit — plus aucun commentaire de contournement, et la ligne correspondante a disparu de nos décisions locales. ### Pourquoi ce ticket comptait plus que sa taille C'était le seul des douze qui empêchait purement et simplement de commencer. `pnpm dev`, `db:dev`, tout ce qui touche la base était inaccessible, et le message d'erreur parlait de `pg_upgrade` sur un volume vide — il envoyait chercher un problème de migration de données là où il s'agissait d'un chemin de montage. Et il était invisible partout où on l'aurait cherché : `pnpm check` est vert, la CI est verte, la suite de conformité passe — parce que `withTestDatabase()` lève sa propre base et n'utilise pas ce compose. Seule une personne qui veut développer tombe dessus. Merci pour la correction. De notre côté, c'est refermé.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dev
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-satellite-template#10
No description provided.