Postgres ne semble pas fonctionner lorsque vous exécutez Discourse localement avec Docker

Soutien
1

Pour mon entreprise, je dois développer des fonctionnalités pour l’API REST de notre instance Discourse. Pour le développement et les tests locaux, j’ai suivi avec succès Install Discourse for development using Docker pendant un certain temps.

Cela fait quelques semaines que je n’ai pas développé. Hier, j’ai voulu relancer Discourse localement, j’ai donc fait ma commande habituelle git pull && d/boot_dev && d/bundle install && d/rails s. Cependant, la dernière commande d/rails s échoue avec l’erreur suivante :

URGENT: Failed to initialize site default: ActiveRecord::ConnectionNotEstablished connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

/home/discourse/.bundle/gems/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:69:in `rescue in new_client'
[...etc.]

Lorsque j’ouvre un terminal dans le conteneur discourse_dev et que je tape ls -la /var/run/postgresql/, je vois qu’il n’y a effectivement pas de socket .s.PGSQL.5432 ici.

Ok, j’ai donc pensé que je n’aurais peut-être pas dû faire aveuglément un git pull en premier, alors j’ai vérifié le tag v4.4.0 et même le tag v3.3.0 et j’ai réessayé. Mais j’obtiens exactement la même erreur.

Il me semble que la base de données Postgres ne tourne pas à l’intérieur du conteneur discourse_dev ?

La chose étrange est la suivante : si je clone le dépôt discourse dans un nouveau dossier (oui, même le dernier code de la branche main) et que je lance Discourse en utilisant Docker, je n’obtiens pas cette erreur et Discourse démarre avec succès. Mais bien sûr, j’ai une base de données vide, ce qui est un peu dommage. Je comprends que les données sont persistées dans tmp/postgres, que je peux copier de l’ancien dossier vers le nouveau. Mais je ne peux plus le faire car je ne le savais pas hier, et lors de mes tentatives de dépannage hier, j’ai supprimé tous les dossiers temporaires et les dossiers node_modules et .pnpm-store et ainsi de suite. Mais le problème persiste.

Quelqu’un a-t-il une idée de ce qui se passe ici ou de ce que je peux faire pour résoudre ce problème ?

2

Il semble que quelque chose soit complètement cassé dans mes données locales, empêchant postgres de démarrer.

Lorsque je fais sudo cp -pr discourse/data/postgres discourse2/data/postgres, j’obtiens exactement le même problème en essayant de démarrer Discourse à partir du dossier discourse2. Inversement, lorsque je supprime discourse/data/postgres, mon instance Discourse d’origine démarre correctement, mais sans données bien sûr :frowning:

3

Désolé pour le désagrément. Cela était probablement dû à la récente mise à jour de PostgreSQL 15 vers PostgreSQL 15. Les anciens fichiers de données PG 13 sont incompatibles avec l’image discourse_dev qui exécute maintenant PG 15, mais notre procédure automatisée de mise à jour de la base de données n’était pas destinée aux environnements de développement.

Y a-t-il une raison particulière pour laquelle vous souhaitez conserver les anciens fichiers de données ?

Vous pouvez exécuter rake dev:populate à l’intérieur du conteneur pour générer des données de test.

1 « J'aime »
4

N’utilisez pas ce guide. Il doit être mis à jour ou supprimé.

Utilisez celui-ci : Developing Discourse using a Dev Container

2 « J'aime »
5

Oh, cela a beaucoup de sens. Merci beaucoup pour l’explication. J’apprends aujourd’hui qu’il est de toute façon une mauvaise idée de faire aveuglément un git pull sur la branche main car tant de choses peuvent être involontairement cassées :slight_smile:

Uniquement en raison de certains paramètres d’administration, spécifiquement concernant Discourse Connect. Également certains paramètres de l’API REST, certains paramètres de plugin et certains groupes d’utilisateurs manuels spécifiques. Nous avons une configuration SSO particulière en place qui gère les catégories et les groupes d’utilisateurs (+ appartenance aux groupes) via l’API REST. Le contenu réel comme les messages et les réponses ne m’intéresse pas du tout pendant le développement, c’est pourquoi rake dev:populate ne m’aiderait pas, je suppose.

Aucun ressentiment ici.

6

Si votre site de staging/production est déjà mis à jour vers PG 15, vous pouvez en extraire une sauvegarde.

Alternativement, vous pourriez essayer de mettre à jour manuellement vos fichiers de données locaux. Ceci pourrait aider :

cd discourse
mkdir data/postgres_new
docker run --rm \
	--entrypoint=/bin/bash \
	-v "$(pwd)/data/postgres":/var/lib/postgresql/13/data \
	-v "$(pwd)/data/postgres_new":/var/lib/postgresql/15/data \
	tianon/postgres-upgrade:13-to-15 \
	-c "apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector &&
	docker-upgrade"
mv data/postgres data/postgres_old
mv data/postgres_new data/postgres
docker run --rm -v "$(pwd)/data/postgres":/postgres \
discourse/discourse_dev:release chown -R postgres:postgres /postgres

(Si vous utilisez un processeur basé sur ARM, vous devrez construire votre propre image.)

1 « J'aime »
7

Merci beaucoup pour votre réponse constructive !

Cela sera utile lorsque mes collègues et moi mettrons à niveau notre instance locale de discourse vers une version ultérieure à la 3.4.0.

Pour l’instant, j’ai commencé avec un nouvel ensemble de données et j’ai réappliqué la configuration nécessaire. Heureusement, nous avions déjà un guide interne écrit qui explique à nos collègues développeurs comment démarrer le développement contre discourse :slight_smile:

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.