Installa Discourse per lo sviluppo usando Docker

Documentazione Guide per sviluppatori
, ,
168

Grazie per la guida.

Tuttavia, sto riscontrando problemi nella creazione di un backup dalla sezione di amministrazione.
L’errore che ricevo è:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".

Ho controllato il file pg_hba.conf e ho impostato tutte le opzioni su trust.

Sarebbe ottimo ricevere assistenza su come risolvere questo problema.

Ho provato sia su Ubuntu che su MacOSX. Tutto funziona correttamente su entrambi (creazione di post, API, ecc.) tranne la funzionalità di backup.

169

Grazie per questa fantastica soluzione Docker.

Per eseguire le specifiche dei plugin, questo funziona bene:

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

Esiste un modo per indirizzare test specifici del plugin, come in un ambiente di sviluppo non Docker? Ad esempio:

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

Ho provato, ad esempio:

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

Ma ottengo un errore.

170

LOAD_PLUGINS e RAILS_ENV devono precedere il comando per assegnare le variabili d’ambiente. Dopo il comando, vengono trattati come argomenti per rspec, che non li riconosce.

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

171

No, non sono convinto che funzioni: l’hai effettivamente provato?

Io ricevo:

NameError:
  uninitialized constant Follow

Sospetto che ciò sia dovuto al fatto che le variabili d’ambiente non vengono passate al processo Docker?

Era per questo motivo che le stavo rendendo argomenti.

172

Scusa, ho interpretato male i tuoi due comandi come “il primo funziona per questa specifica, il secondo non funziona per questa specifica”. Non ho un ambiente di sviluppo configurato per testare.

Dall’esame del file rspec su GitHub, penso che tu abbia ragione: le variabili d’ambiente non vengono passate. Sembra che tu possa eseguire d/shell per ottenere una shell all’interno del contenitore e poi eseguire lì il tuo comando rspec.

1 Mi Piace
173

Simon, è più di un ottimo workaround utilizzabile, grazie!

Ho appena provato e funziona, cioè:

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

Ho aggiunto questo e l’intera versione del plugin alla Wiki

1 Mi Piace
174

Dando un’occhiata più da vicino a d/exec, che viene utilizzato sia da d/shell che da d/rspec, credo che possa essere abbreviato anche così:

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

d/exec passa RAILS_ENV ma non LOAD_PLUGINS, motivo per cui si trovano su entrambi i lati di d/exec.

1 Mi Piace
175

Questo mi restituisce un errore:

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, immagino che le variabili d’ambiente non possano essere utilizzate con docker exec in quel modo. Pazienza, almeno aprire prima la shell funziona.

1 Mi Piace
177

Sto riscontrando esattamente lo stesso problema di Max. Ogni volta che provo a eseguire un backup o un ripristino sulla mia installazione locale di sviluppo Docker, ottengo lo stesso errore: Peer authentication failed for user "postgres"

Dopo aver indagato un po’, ho scoperto che nell’ambiente di sviluppo la configurazione del database appare così:

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

In qualche modo, l’ambiente di sviluppo non imposta il nome utente nelle variabili d’ambiente e il modulo BackupRestore imposta automaticamente il valore del nome utente su 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"]
    )

Dove possiamo impostare il nome utente corretto per il database?

1 Mi Piace
178

Come possiamo utilizzare Install the Discourse Theme CLI console app to help you build themes qui?

Abbiamo installato con successo il gem: d/exec sudo gem install discourse_theme … ora la sfida è creare un collegamento simbolico al tema locale …

@Simon_Manning nota l’uso di sudo per aggirare i problemi di permessi (grazie per il promemoria @fzngagan)

179

Sto cercando di testare un plugin utilizzando l’ambiente Docker. In modo casuale l’applicazione smette di caricarsi e mi viene mostrata una pagina vuota finché non elimino la cartella dei dati e ricostruisco tutto. Hai qualche consiglio su come risolvere il problema?

180

Ci sono state novità in merito? Sembra ancora un problema.

181

Il mio “sporco” workaround è stato sostituire il nome utente da postgres a discourse nel seguente blocco di codice:

# 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

Sono passato dal mio Mac locale a una VM Ubuntu sperando che questo rendesse più semplice far funzionare tutto, ma purtroppo finora non è stato così.

Sto già affrontando alcuni strani problemi di permessi nelle fasi iniziali. d/bundle install segnala la necessità di privilegi sudo per installare alcuni componenti, e anche d/rails s restituisce errori relativi ai permessi.

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': Permission denied @ dir_s_mkdir - /src/tmp (Errno::EACCES)

Hai idea di cosa stia andando storto? Questa macchina aveva in precedenza eseguito una produzione di Discourse senza problemi. Ho semplicemente fermato e rimosso quei container e clonato il repo git di sviluppo in una directory diversa. Sto eseguendo tutto tramite tmux per gestire le diverse istanze della shell.

183

Non sono ancora su M1, ma prevedo di passare molto presto, e preferisco davvero la praticità della configurazione Docker.

Quel link alla PR punta a https://github.com/docker/for-mac/issues/5321, dove dichiarano:

l’unica soluzione è passare a immagini multi-architettura compatibili con arm64. Queste saranno anche molto più veloci e generalmente più affidabili. Consiglio di verificare quali immagini base state utilizzando e di passare a quelle multi-architettura dove possibile. Potete vedere quali architetture sono supportate da ciascuna immagine su Docker Hub: […]

Per costruire un’immagine multi-architettura da soli, consiglio docker buildx; consultate questo articolo del blog: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

Il team di Discourse è aperto a supportare un’immagine multi-architettura? Sembra che l’immagine base di Discourse sia basata su debian:buster-slim, che è multi-architettura, quindi non dovrebbe essere eccessivamente difficile rendere l’immagine base di Discourse multi-architettura, ma ciò potrebbe mettervi nella posizione di dover supportare ARM (in produzione!). Qualcuno (il team di Discourse?) dovrebbe eseguire i test di Discourse sia su x86_64 che su ARM, risolvere i problemi quando falliscono, ecc.

Una PR sarebbe anche benvenuta qui?

(A mio avviso, sembra che ARM sia l’architettura del futuro, anche negli ambienti ospitati nel cloud.)

2 Mi Piace
Install Discourse on Arm-Based Compute
184

Sto cercando di configurarlo su WSL2.

Sono arrivato a avviare ember_cli, ma Chrome mi restituisce il seguente errore:

Non sono visibili errori né nel terminale né nel registro di sviluppo. Accolgo con piacere qualsiasi suggerimento, grazie.

1 Mi Piace
Trouble setting up dev Discourse on WSL2 with Docker - solved
185

Questo è davvero utile

186

Ciao a tutti,

Sto riscontrando gli stessi problemi, quindi ho pensato di segnalarlo come bug. Si prega di vedere sotto.

Ripristino del backup non riuscito in un ambiente docker dev pulito: FATAL: Peer authentication failed for user “postgres”

Fatemi sapere se posso fornire ulteriori informazioni o essere d’aiuto.

Koen

187

Impossibile farlo funzionare su openSUSE Leap 15. Suppongo che non sia un sistema operativo supportato, anche se dato che usiamo Docker non dovrebbe fare molta differenza…

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)

Ho provato a creare manualmente “app/assets/javascripts/plugins” e questo mi ha portato 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)

Quindi farò mkdir tmp nella cartella sorgente…

Ma poi arrivo qui:

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)

Sembra che boot_dev stia eseguendo docker exec come utente discourse… ma le directory sono di proprietà di un utente 1016 (l’uid dell’utente host).

Immagino che molti sviluppatori non incontrino questo problema sui loro laptop personali dove il loro utente ha un uid di 1000 e coincide casualmente…

1 Mi Piace