Installer Discourse pour le développement avec Docker

[singi2016cn]

La cause profonde pourrait être que pg15 a modifié les règles de vérification par défaut.

Chemin du fichier de configuration : /etc/postgresql/15/main/pg_hba.conf

Contenu du fichier :

# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host all all 0.0.0.0/0 md5
# IPv6 local connections:
host all all ::/0 md5
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

La commande d’exécution de la sauvegarde est la suivante :

pg_dump --schema=public -T public.pg_* --file=‘/src/tmp/backups/default/2026-02-02-063003/dump.sql.gz’ --no-owner --no-privileges --verbose --compress=4 --username=postgres discourse_development

La commande ci-dessus génère une erreur en raison de la règle local all postgres peer : Peer authentication failed for user "postgres"

Idée de résolution : Changer peer en trust pour autoriser toutes les commandes en environnement local. Cela signifie qu’aucune vérification ne sera nécessaire pour toutes les commandes (et aucun mot de passe ne sera requis).

Étapes spécifiques :

1. Copier /etc/postgresql/15/main/pg_hba.conf du conteneur vers la machine locale

sudo docker cp discourse_dev:/etc/postgresql/15/main/pg_hba.conf ~/discourse/data/pg_hba.conf

Donner les permissions 644

sudo chmod 644 ~/discourse/data/pg_hba.conf

Modifier la configuration dans data/pg_hba.conf

# Database administrative login by Unix domain socket
local   all   postgres   trust

2. Modifier le fichier d/boot_dev pour monter data/pg_hba.conf dans le conteneur, écrasant le fichier de configuration par défaut de pg.

docker run -d \
    -p $local_publish:8025:8025 \
    -p $local_publish:3000:3000 \
    -p $local_publish:4200:4200 \
    -p $local_publish:9292:9292 \
    -p $local_publish:9405:9405 \
    -v "$DATA_DIR:/shared/postgres_data:delegated" \
    # La ligne ci-dessous est ajoutée, elle monte le fichier de configuration dans le conteneur, et donne uniquement des droits de lecture au conteneur
    -v "$SOURCE_DIR/data/pg_hba.conf:/etc/postgresql/15/main/pg_hba.conf:ro" \
    -v "$SOURCE_DIR:/src:delegated" \
    -e UNICORN_BIND_ALL=true \
    $mount_plugin_symlinks \
    $ENV_ARGS \
    --hostname=discourse \
    --name=discourse_dev \
    --restart=always \
    discourse/discourse_dev:release /sbin/boot

3. Arrêter et supprimer le conteneur actuel, puis reconstruire le nouveau conteneur

d/shotdown_dev
d/boot_dev

4. Après la reconstruction, démarrer les applications front-end et back-end, et tester si la sauvegarde fonctionne correctement

d/rails s

# Exécuter dans une autre invite de commande
d/ember-cli

Dans la page de sauvegarde, cliquez sur Sauvegarder, attendez quelques secondes, puis vérifiez la liste des fichiers de sauvegarde.

[singi2016cn]

Sur la base de l’expérience ci-dessus, le souhait de pouvoir se connecter à la base de données postgreSQL dans Docker avec un client de base de données local est désormais réalisable.

Modifier la configuration dans le fichier d/boot_dev comme suit :

docker run -d \
    -p $local_publish:8025:8025 \
    -p $local_publish:3000:3000 \
    -p $local_publish:4200:4200 \
    -p $local_publish:9292:9292 \
    -p $local_publish:9405:9405 \
    # Ajouter le mappage de port
    -p $local_publish:55432:5432 \
    -v "$DATA_DIR:/shared/postgres_data:delegated" \
    # Conserver le mappage du fichier de configuration
    -v "$SOURCE_DIR/data/pg_hba.conf:/etc/postgresql/15/main/pg_hba.conf:ro" \
    -v "$SOURCE_DIR:/src:delegated" \
    -e UNICORN_BIND_ALL=true \
    $mount_plugin_symlinks \
    $ENV_ARGS \
    --hostname=discourse \
    --name=discourse_dev \
    --restart=always \
    discourse/discourse_dev:release /sbin/boot

Autoriser toutes les requêtes de connexion à pg :

Dans le fichier data/pg_hba.conf, modifier la configuration comme suit :

# IPv4 local connections:
host all all 0.0.0.0/0 trust
# IPv6 local connections:
host all all ::/0 trust

Reconstruire

d/shutdown_dev
d/boot_dev

Vous pouvez maintenant vous connecter avec un client de base de données local

J’utilise DBeaver ici

1. Le port de la base de données est 55432, ce qui correspond à celui dans d/boot_dev. Ici, c’est 55432 pour éviter les conflits avec les installations locales existantes.
2. Nom de la base de données
3. Il est recommandé de cocher « Afficher toutes les bases de données »
4. Nom d’utilisateur
5. Tester la connexion
6. Cliquer sur OK pour enregistrer

Enfin, vous pouvez consulter joyeusement les données de la base de données localement.

[pean]

Est-il normal que cette installation n’affiche pas le menu correctement ?

[manu-p]

Bonjour, bien que tout semble fonctionner après avoir suivi ce tuto sur une machine Ubuntu 26.04, aucun mail ne semble partir.

J’ai bien lancé d/mailhog dans un terminal dédié, et j’y vois le code HTML/CSS du mail envoyé suite à l’inscription d’un utilisateur de test, mais celui-ci ne reçoit rien à l’adresse mail que j’ai donné…

Qu’ai-je raté et comment y remédier ?

[merefield (Robert)]

Le courriel devrait apparaître à l’adresse http://localhost:8025, je crois (port de Mailhog).

Il ne s’agit pas d’une installation de production, donc aucun courriel ne sera envoyé sur Internet. Pour cela, vous avez besoin d’une installation complète de production et d’un service de courriel compatible (qui, de nos jours, coûte généralement de l’argent réel, car la gestion de la confiance a un coût ).

[manu-p]

Merci @merefield j’avais bien vu localhost:8025 mais pour je ne sais quelle raison ça ne marchait pas, et là tout bien.

[dubwoc]

Cette solution fonctionne-t-elle ? Je n’ai pas réussi à aller au-delà de d/boot_dev --init.

Mise à jour :
Je vois, si votre UID de développeur n’est pas 1000, comme l’utilisateur discourse dans le conteneur discourse_dev, cela semble tout simplement échouer.

uid=1000(discourse) gid=1000(discourse) groups=1000(discourse)

Une série de problèmes rencontrés

nastee@station ~/vendsrc/discourse > ./d/boot_dev --init
Utilisation de la source dans : /home/nastee/vendsrc/discourse
Utilisation des données dans :   /home/nastee/vendsrc/discourse/data/postgres
release : Extraction depuis discourse/discourse_dev
.....
Digest : sha256:e118af085d4be0486d4d9bfa83ac1c519d9975bed9a08180d10d5ad7c508632c
Statut : Nouvelle image téléchargée pour discourse/discourse_dev:release
docker.io/discourse/discourse_dev:release
f517752802e70b8a9110972bb3ddc0e9343d0c430603e4a9ae3eacc5ec69a2cf
Installation des gems...
Une erreur s'est produite lors de l'écriture dans `/src/Gemfile.lock`. Il est probable que vous deviez accorder des permissions d'écriture pour ce chemin.

Merci à : There was an error while trying to write to `/src/Gemfile.lock`. It is likely that you need to grant write permissions for that path - #2 by jacque006

J’ai défini ce fichier en 777 (bouh), je l’ai fait, et au moins les Gems s’installent maintenant, mais le processus suivant docker exec tente d’écrire dans le répertoire source et ne peut pas car il ne s’exécute pas en tant que mon utilisateur, donc j’obtiens :

 EACCES  EACCES : permission refusée, ouverture de '/src/_tmp_82_62be1aeb82e80c1d1054dac8bdbc5923'

Bon, pourquoi pas, sudo chmod 4777 . où . est le répertoire source cloné dans lequel j’exécute d/

Ce qui m’amène à :

 EACCES  Erreur lors de la tentative de création du lien symbolique "../../../node_modules/.pnpm/prettier@3.8.1/node_modules/prettier" vers "/src/docs/developer-guides/node_modules/prettier". L'erreur s'est produite lors de la tentative de création du répertoire parent pour la cible du lien symbolique. Détails : Erreur : EACCES : permission refusée, création du répertoire '/src/docs/developer-guides/node_modules'

après avoir rencontré un autre problème de permissions et simplement cédé face à chmod 777 -R .

culminant éventuellement avec :

connection au serveur sur le socket "/var/run/postgresql/.s.PGSQL.5432" échouée : Aucun fichier ou répertoire de ce type