Install Discourse for development using Docker

Dokumentation Entwicklerhandbücher
, ,
168

Thank you for the guide.

However I’m having issues with creating a backup from the admin section.
The error I’m getting is:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".

I checked the pg_hba.conf file, and have all options set to trust.

Would be great i could get some assistance on how to get this to work.

I tried on Ubuntu as well as on MacOSX. Everything is working fine on both (creating Posts, API…) except for the backup functionality.

169

Thanks for this fantastic docker solution.

For running plugin specs, this works nicely:

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

Is there a way to target specific plugin tests, as per a non-docker dev?, e.g.:

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

I’ve tried e.g.:

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

But getting an error.

170

LOAD_PLUGINS and RAILS_ENV must precede the command to assign environment variables. Following the command, they’re being treated as arguments to rspec, which it doesn’t understand.

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

171

No, I’m not convinced that works - have you actually tried it?

I get:

NameError:
  uninitialized constant Follow

I suspect this is because the environment variables are not being passed into the docker process?

That was why I was making them arguments.

172

Apologies, I misinterpreted your two commands as “the first works for this other spec, the second doesn’t work for this spec”. I don’t have a development environment set up to test.

Looking at the rspec file in Github, I think you’re right that it’s not passing in the environment variables. It looks like you should be able to run d/shell to get a shell inside the container, then run your rspec command there though.

1 „Gefällt mir“
173

Simon, that’s more than an excellent useable workaround, thanks!

Just tried that and it works, ie:

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

Have added this and the whole plugin version to the Wiki

1 „Gefällt mir“
174

Taking a closer look at d/exec, which both d/shell and d/rspec use, I think it can also be shortened like so:

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

d/exec does pass in RAILS_ENV but not LOAD_PLUGINS, hence them being on either side of d/exec.

1 „Gefällt mir“
175

That gives me an 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, I guess environment variables can’t be used with docker exec like that. Oh well, at least opening the shell first works.

1 „Gefällt mir“
177

I’m having the exact same problem as Max. Whenever I try to make a backup or a restore on my local development docker install I get the same error: Peer authentication failed for user "postgres"

After some digging around I found that in the development environment the database configuration shows up like this:

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

Somehow the dev environment is not setting the username on the environment variables and then the BackupRestore module just defaults the username value to 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"]
    )

Where can we set the right database username?

1 „Gefällt mir“
178

How do we use the Discourse Theme CLI (console app to help you build themes) here?

We’ve successfully installed the gem: d/exec sudo gem install discourse_theme … now the challenge is to symlink to local theme …

@Simon_Manning note use of sudo to get around permissions (thanks for reminder @fzngagan)

179

I’m trying to test a plugin using the docker setup. Randomly the app stops loading and I’m just presented with a blank page until I delete the data folder and rebuild everything. Any tips on how to debug the issue?

180

Have there been any findings on that one? Still seems to be an issue.

181

My “dirty” workaround was to replace the username from postgres to discourse on the following block of code:

# 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

I switched from my local Mac to a Ubuntu VM hoping this would make it easier to get this running but unfortunately so far it’s not.

Already fighting some weird permission problems in the early stages. d/bundle install reports it needs sudo rights to install some, d/rails s also comes back with permission problems

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)

Any idea what’s going wrong? This machine previously ran a production discourse without issues. I just stopped and removed those containers and cloned the dev git repo into a different directory. Running it all through tmux to handle the differen shell instances.

183

I’m not on M1 yet, but I’m expecting to switch very soon, and I really prefer the convenience of the Docker setup.

That PR link links to https://github.com/docker/for-mac/issues/5321 where they say:

the only solution is to switch to arm64-capable multi-arch images. These will also be a lot faster and generally more reliable. I recommend investigating which base images you’re using and to switch to multi-arch ones where possible. You can see which architectures are supported by each image on Docker Hub: […]

To build a multi-arch image yourself, I recommend docker buildx , check out this blog post: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

Is the Discourse team open to supporting a multi-arch image? It looks like the Discourse base image is based on debian:buster-slim, which is multi-arch, so it seems like it shouldn’t be outrageously difficult to make the Discourse base image be multi-arch, but that might put y’all in the position of having to support ARM (in production!). Somebody (the Discourse team?) would need to run the Discourse tests on both x86_64 and ARM, fix issues when they fail, etc.

Would a PR even be welcome here?

(IMO, it seems like ARM is the architecture of the future, even on cloud-hosted environments.)

2 „Gefällt mir“
184

I’m trying to set this up on WSL2.

I’ve got down to starting ember_cli but Chrome give me the following error:

There are no errors visible in either terminal or the development log. Any suggestions welcome, please?

1 „Gefällt mir“
185

this is really helpful

186

Hallo zusammen,

Ich stoße auf dieselben Probleme und dachte daher, ich melde es als Fehler. Bitte siehe unten.

Backup-Wiederherstellung schlägt in sauberer Dev-Docker-Umgebung fehl: FATAL: Peer-Authentifizierung fehlgeschlagen für Benutzer „postgres“

Lassen Sie mich wissen, wenn ich weitere Informationen bereitstellen oder behilflich sein kann.

Koen

187

Ich bekomme das unter openSUSE Leap 15 nicht zum Laufen. Ich nehme an, das ist kein unterstütztes Betriebssystem, obwohl es, da wir Docker verwenden, eigentlich keine Rolle spielen sollte…

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)

Ich habe versucht, “app/assets/javascripts/plugins” manuell zu erstellen, und das hat mich zu Folgendem geführt:

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)

Ich werde also tmp im Quellordner erstellen…

Aber dann komme ich hierher:

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)

Es sieht so aus, als ob boot_dev docker exec als discourse-Benutzer ausführt… aber die Verzeichnisse gehören einem Benutzer 1016 (der uid meines Host-Benutzers).

Ich stelle mir vor, dass viele Entwickler dieses Problem auf ihren persönlichen Laptops nicht haben, wo ihr Benutzer eine uid von 1000 hat und es zufällig übereinstimmt…

1 „Gefällt mir“