Instalar Discourse para desarrollo usando Docker

Documentación Guías para desarrolladores
, ,
168

Gracias por la guía.

Sin embargo, tengo problemas al crear una copia de seguridad desde la sección de administración. El error que recibo es:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".

He verificado el archivo pg_hba.conf y tengo todas las opciones configuradas en trust.

Sería genial si pudieras ayudarme a solucionar esto.

Lo he probado tanto en Ubuntu como en MacOSX. Todo funciona correctamente en ambos (crear publicaciones, API…) excepto la funcionalidad de copia de seguridad.

169

Gracias por esta fantástica solución con Docker.

Para ejecutar las especificaciones de los plugins, esto funciona muy bien:

d/rake plugin:spec["discourse-follow"]

¿Existe alguna forma de dirigir pruebas específicas de plugins, como en un entorno de desarrollo sin Docker?, por ejemplo:

LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32

He intentado, por ejemplo:

d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10 LOAD_PLUGINS=1 RAILS_ENV=test

Pero obtengo un error.

170

LOAD_PLUGINS y RAILS_ENV deben ir antes del comando para asignar variables de entorno. Si se colocan después del comando, se interpretan como argumentos para rspec, el cual no los reconoce.

LOAD_PLUGINS=1 RAILS_ENV=test d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10

171

No, no me convence que funcione; ¿lo has probado realmente?

Recibo esto:

NameError:
  uninitialized constant Follow

Sospecho que se debe a que las variables de entorno no se están pasando al proceso de Docker.

Por eso las estaba convirtiendo en argumentos.

172

Disculpas, malinterpreté tus dos comandos como “el primero funciona para esta otra especificación, el segundo no funciona para esta especificación”. No tengo un entorno de desarrollo configurado para probar.

Al revisar el archivo rspec en GitHub, creo que tienes razón en que no se están pasando las variables de entorno. Parece que deberías poder ejecutar d/shell para obtener una shell dentro del contenedor y luego ejecutar tu comando rspec allí.

1 me gusta
173

Simon, eso es más que una solución alternativa excelente y utilizable, ¡gracias!

Acabo de probarlo y funciona, es decir:

my-blah-machine:~/discourse$ d/shell
discourse@discourse:/src$ LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

He añadido esto y toda la versión del plugin a la Wiki.

1 me gusta
174

Al observar más de cerca d/exec, que utilizan tanto d/shell como d/rspec, creo que también se puede acortar de la siguiente manera:

RAILS_ENV=test d/exec LOAD_PLUGINS=1 rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

d/exec sí pasa RAILS_ENV, pero no LOAD_PLUGINS, por eso aparecen a ambos lados de d/exec.

1 me gusta
175

Eso me genera un error:

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "LOAD_PLUGINS=1": executable file not found in $PATH: unknown
176

Ah, supongo que las variables de entorno no se pueden usar así con docker exec. Bueno, al menos abrir la shell primero funciona.

1 me gusta
177

Tengo exactamente el mismo problema que Max. Cada vez que intento hacer una copia de seguridad o una restauración en mi instalación local de desarrollo con Docker, obtengo el mismo error: Peer authentication failed for user "postgres".

Después de investigar un poco, descubrí que en el entorno de desarrollo la configuración de la base de datos aparece así:

BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration host=nil, port=nil, username="postgres", password=nil, database="discourse_development">

De alguna manera, el entorno de desarrollo no está estableciendo el nombre de usuario en las variables de entorno, y entonces el módulo BackupRestore asigna por defecto el valor del nombre de usuario a postgres.

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )

¿Dónde podemos establecer el nombre de usuario correcto de la base de datos?

1 me gusta
178

¿Cómo utilizamos Install the Discourse Theme CLI console app to help you build themes aquí?

Hemos instalado correctamente la gem: d/exec sudo gem install discourse_theme… ahora el desafío es crear un enlace simbólico al tema local…

@Simon_Manning, ten en cuenta el uso de sudo para evitar problemas de permisos (gracias por el recordatorio, @fzngagan).

179

Estoy intentando probar un plugin usando la configuración de Docker. De forma aleatoria, la aplicación deja de cargar y solo me aparece una página en blanco hasta que elimino la carpeta de datos y reconstruyo todo. ¿Alguna sugerencia sobre cómo depurar el problema?

180

¿Se han obtenido resultados al respecto? Todavía parece ser un problema.

181

Mi “parche” fue reemplazar el nombre de usuario de postgres por discourse en el siguiente bloque de código:

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )
182

He cambiado de mi Mac local a una VM con Ubuntu esperando que esto facilitara la ejecución, pero desafortunadamente, hasta ahora no ha sido así.

Ya estoy luchando con algunos problemas extraños de permisos en las primeras etapas. d/bundle install indica que necesita derechos de sudo para instalar algunos paquetes, y d/rails s también devuelve errores de permisos.

Traceback (most recent call last):
        8: from /src/bin/unicorn:70:in `<main>'
        7: from /src/bin/unicorn:38:in `ensure_cache_clean!'
        6: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'
        5: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'
        4: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'
        3: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'
        2: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'
        1: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
/usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permiso denegado @ dir_s_mkdir - /src/tmp (Errno::EACCES)

¿Alguna idea de qué está fallando? Esta máquina ejecutaba anteriormente un Discourse de producción sin problemas. Solo detuve y eliminé esos contenedores y cloné el repositorio git de desarrollo en un directorio diferente. Lo estoy ejecutando todo a través de tmux para manejar las diferentes instancias de shell.

183

Aún no estoy en M1, pero espero cambiar muy pronto, y realmente prefiero la conveniencia de la configuración de Docker.

Ese enlace a la PR apunta a https://github.com/docker/for-mac/issues/5321, donde dicen:

la única solución es cambiar a imágenes multiarquitectura compatibles con arm64. Estas también serán mucho más rápidas y, en general, más confiables. Recomiendo investigar qué imágenes base están utilizando y cambiar a imágenes multiarquitectura donde sea posible. Pueden ver qué arquitecturas son compatibles con cada imagen en Docker Hub: […]

Para construir una imagen multiarquitectura usted mismo, recomiendo docker buildx; consulte esta publicación del blog: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

¿Está el equipo de Discourse dispuesto a apoyar una imagen multiarquitectura? Parece que la imagen base de Discourse se basa en debian:buster-slim, que sí es multiarquitectura, por lo que no debería ser excesivamente difícil hacer que la imagen base de Discourse sea multiarquitectura, pero eso podría ponerlos en la posición de tener que apoyar ARM (¡en producción!). Alguien (¿el equipo de Discourse?) tendría que ejecutar las pruebas de Discourse tanto en x86_64 como en ARM, solucionar problemas cuando fallen, etc.

¿Sería bienvenido incluso un PR aquí?

(En mi opinión, parece que ARM es la arquitectura del futuro, incluso en entornos alojados en la nube.)

2 Me gusta
Install Discourse on Arm-Based Compute
184

Estoy intentando configurar esto en WSL2.

He llegado hasta el punto de iniciar ember_cli, pero Chrome me muestra el siguiente error:

No hay errores visibles ni en la terminal ni en el registro de desarrollo. ¿Alguna sugerencia?

1 me gusta
Trouble setting up dev Discourse on WSL2 with Docker - solved
185

esto es realmente útil

186

Hola a todos,

Me encuentro con los mismos problemas, así que pensé en plantearlo como un error. Por favor, vean a continuación.

La restauración de copias de seguridad falla en un entorno docker de desarrollo limpio: FATAL: Peer authentication failed for user “postgres”

Avísenme si puedo proporcionar más información o ser de ayuda.

Koen

187

No puedo hacer que esto funcione en openSUSE Leap 15. Supongo que no es un sistema operativo compatible, aunque como usamos Docker, realmente no debería importar…

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/app/assets/javascripts/plugins
/src/lib/plugin/instance.rb:441:in `ensure_directory'
/src/lib/plugin/instance.rb:713:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Intenté crear manualmente “app/assets/javascripts/plugins” y eso me llevó a

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/tmp
lib/discourse.rb:94:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Así que haré mkdir tmp en la carpeta fuente…

Pero entonces llego aquí:

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /src/tmp/5ad4443faf817dc922116f8df65ae5c3
lib/discourse.rb:97:in `initialize'
lib/discourse.rb:97:in `open'
lib/discourse.rb:97:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Parece que boot_dev está ejecutando docker exec como el usuario discourse… pero los directorios son propiedad de un usuario 1016 (el uid del usuario de mi host).

Imagino que muchos desarrolladores no se encuentran con este problema en sus portátiles personales donde su usuario tiene un uid de 1000 y coincide casualmente…

1 me gusta