Instalar Discourse para desarrollo usando Docker

La causa raíz puede ser que pg15 modificó las reglas de autenticación predeterminadas.

Ruta del archivo de configuración: /etc/postgresql/15/main/pg_hba.conf

Contenido del archivo:

# 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

El comando de respaldo ejecutado es:

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

El comando anterior falla debido a la regla local all postgres peer: Peer authentication failed for user "postgres"

Idea de solución: Cambiar peer a trust para permitir todos los comandos en el entorno local. Es decir, todos los comandos ya no requerirán autenticación (ni requerirán ingresar una contraseña).

Pasos específicos:

  1. Copiar /etc/postgresql/15/main/pg_hba.conf del contenedor a la máquina local

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

Otorgar permisos 644

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

Modificar la configuración en data/pg_hba.conf

# Database administrative login by Unix domain socket
local   all   postgres   trust
  1. Modificar el archivo d/boot_dev para montar data/pg_hba.conf en el contenedor, sobrescribiendo el archivo de configuración predeterminado 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 siguiente línea es la nueva, monta el archivo de configuración en el contenedor y solo le da permisos de solo lectura al contenedor
    -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
  1. Detener y eliminar el contenedor actual, luego reconstruir el nuevo contenedor
d/shotdown_dev
d/boot_dev
  1. Después de la reconstrucción, iniciar las aplicaciones frontend y backend y probar si la copia de seguridad funciona correctamente
d/rails s

# Ejecutar en otra línea de comandos
d/ember-cli

En la página de copias de seguridad, haga clic en realizar copia de seguridad, espere unos segundos y luego verifique la lista de archivos de copia de seguridad.

1 me gusta

Basado en la experiencia anterior, ahora es posible conectar un cliente de base de datos local a la base de datos postgreSQL dentro de Docker.

Modificar la configuración en el archivo d/boot_dev de la siguiente manera:

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 \
    # Mapeo de puertos añadido
    -p $local_publish:55432:5432 \
    -v "$DATA_DIR:/shared/postgres_data:delegated" \
    # Mantener el mapeo del archivo de configuración
    -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

Permitir todas las solicitudes de conexión a pg:

En el archivo data/pg_hba.conf, modificar la configuración de la siguiente manera:

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

Reconstruir

d/shutdown_dev
d/boot_dev

Ahora se puede conectar con un cliente de base de datos local

Estoy usando DBeaver aquí.

  1. El puerto de la base de datos es 55432, lo que coincide con el de d/boot_dev. Se utiliza 55432 para evitar conflictos con los puertos locales existentes.
  2. Nombre de la base de datos
  3. Se recomienda marcar “Mostrar todas las bases de datos”
  4. Nombre de usuario
  5. Probar si la conexión es exitosa
  6. Hacer clic en Aceptar para guardar

Finalmente, puedo ver los datos en la base de datos local felizmente.

1 me gusta

¿Es normal que esta instalación no muestre el menú correctamente?

Hola, aunque todo parece funcionar después de seguir este tutorial en una máquina Ubuntu 26.04, no parece que se envíe ningún correo.

He iniciado d/mailhog en una terminal dedicada y veo el código HTML/CSS del correo enviado tras el registro de un usuario de prueba, pero este no recibe nada en la dirección de correo que proporcioné…

¿Qué me he perdido y cómo puedo solucionarlo? :folded_hands:

El correo debería aparecer en http://localhost:8025, creo (puerto de MailHog).

Esta no es una instalación de producción, por lo que no se enviará ningún correo a través de internet. Para eso necesitas una instalación completa de producción y un servicio de correo compatible (que hoy en día suele costar dinero real, ya que gestionar la confianza tiene un coste :money_bag:).

1 me gusta

Gracias @merefield, vi correctamente localhost:8025, pero por alguna razón que no conozco no funcionaba, y ahora todo está bien.

1 me gusta

¿Funciona esta solución? No pude ir más allá de d/boot_dev --init.

Actualización:
Veo que si tu UID de desarrollador no es 1000, como el usuario discourse en el contenedor discourse_dev, esto simplemente falla.

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

Varios problemas que encontré
nastee@station ~/vendsrc/discourse > ./d/boot_dev --init
Usando el origen en: /home/nastee/vendsrc/discourse
Usando los datos en:   /home/nastee/vendsrc/discourse/data/postgres
release: Extrayendo desde discourse/discourse_dev
.....
Digest: sha256:e118af085d4be0486d4d9bfa83ac1c519d9975bed9a08180d10d5ad7c508632c
Estado: Se descargó una imagen más reciente para discourse/discourse_dev:release
docker.io/discourse/discourse_dev:release
f517752802e70b8a9110972bb3ddc0e9343d0c430603e4a9ae3eacc5ec69a2cf
Instalando gems...
Hubo un error al intentar escribir en `/src/Gemfile.lock`. Es probable que necesites conceder permisos de escritura para esa ruta.

Gracias a: 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

Establecí ese archivo en 777 (qué asco), lo hice, y al menos ahora instala las Gems, pero el siguiente proceso docker exec intenta escribir en el directorio de origen y no puede, ya que no se está ejecutando como mi usuario, por lo que obtengo:

 EACCES  EACCES: permiso denegado, open '/src/_tmp_82_62be1aeb82e80c1d1054dac8bdbc5923'

Bueno, ¿por qué no? sudo chmod 4777 ., donde . es el directorio de origen clonado desde el que estoy ejecutando d/.

Lo cual me lleva a:

 EACCES  Error al intentar crear un enlace simbólico de "../../../node_modules/.pnpm/prettier@3.8.1/node_modules/prettier" a "/src/docs/developer-guides/node_modules/prettier". El error ocurrió al intentar crear el directorio padre para el objetivo del enlace simbólico. Detalles: Error: EACCES: permiso denegado, mkdir '/src/docs/developer-guides/node_modules'

Después de tropezar con otro problema de permisos y simplemente ceder ante chmod 777 -R ..

Finalmente culminando en:

connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory