Install Discourse for development using Docker

Hi, i think we should make a description about the Ember-CLI here, and a shourcut for below command without enter into docker container.

And i can’t get it work by execute above commands into container, seems container didn’t expose the 4200 port.

Manual expose the port 4200 by edit d/boot_dev:
Screenshot from 2021-05-02 16-09-16

After reboot container I access localhost:4200 got this:

discourse@discourse:/tmp$ cat error.dump.cab4cc444229d44fc0fce2deb8695880.log 
=================================================================================

ENV Summary:

  TIME: Sun May 02 2021 08:01:12 GMT+0000 (Coordinated Universal Time)
  TITLE: ember
  ARGV:
  - /usr/bin/node
  - /src/app/assets/javascripts/node_modules/.bin/ember
  - server
  - --proxy
  - http://localhost:3000
  EXEC_PATH: /usr/bin/node
  TMPDIR: /tmp
  SHELL: /bin/bash
  PATH:
  - /tmp/yarn--1619942449179-0.1910991449592403
  - /src/app/assets/javascripts/discourse/node_modules/.bin
  - /home/discourse/.config/yarn/link/node_modules/.bin
  - /src/app/assets/javascripts/node_modules/.bin
  - /home/discourse/.yarn/bin
  - /usr/libexec/lib/node_modules/npm/bin/node-gyp-bin
  - /usr/lib/node_modules/npm/bin/node-gyp-bin
  - /usr/bin/node_modules/npm/bin/node-gyp-bin
  - /usr/local/sbin
  - /usr/local/bin
  - /usr/sbin
  - /usr/bin
  - /sbin
  - /bin
  PLATFORM: linux x64
  FREEMEM: 8603062272
  TOTALMEM: 41962496000
  UPTIME: 612639
  LOADAVG: 3.32177734375,2.19580078125,1.47900390625
  CPUS:
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3301
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3300
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3300
  - Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz - 3301
  ENDIANNESS: LE
  VERSIONS:
  - ares: 1.15.0
  - brotli: 1.0.7
  - cldr: 35.1
  - http_parser: 2.9.3
  - icu: 64.2
  - modules: 64
  - napi: 7
  - nghttp2: 1.41.0
  - node: 10.23.0
  - openssl: 1.1.1g
  - tz: 2019c
  - unicode: 12.1
  - uv: 1.34.2
  - v8: 6.8.275.32-node.59
  - zlib: 1.2.11

ERROR Summary:

  - broccoliBuilderErrorStack: [undefined]
  - code: ECONNREFUSED
  - codeFrame: [undefined]
  - errorMessage: connect ECONNREFUSED 127.0.0.1:3000
  - errorType: [undefined]
  - location:
    - column: [undefined]
    - file: [undefined]
    - line: [undefined]
  - message: connect ECONNREFUSED 127.0.0.1:3000
  - name: Error
  - nodeAnnotation: [undefined]
  - nodeName: [undefined]
  - originalErrorMessage: [undefined]
  - stack: Error: connect ECONNREFUSED 127.0.0.1:3000
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1107:14)

=================================================================================

After edit bin/ember-cli PORT to 3000 to 9292 all working.

Seems the ember-cli bash unable work with ENV["UNICORN_PORT"] .

1 Like

The Ember CLI is a new (and hard fought) development; @eviltrout should be able to comment on that soon.

3 Likes

Yes this will have to be updated. In the meantime you can disable that by setting the NO_EMBER_CLI environment variable to 1.

5 Likes

Probably obvious but could you clarify where you set the env variable @eviltrout ?

I tried in the d/unicorn file like this:

docker exec -it -u discourse:discourse discourse_dev /bin/bash -c "$CMD" -e NO_EMBER_CLI=1

…but that didn’t work (still getting " Ember CLI is Required in Development Mode" message at localhost:9292).

d/boot_dev -e NO_EMBER_CLI=1

I tried this today, and also ran into issues. The error I saw was because Docker’s architecture emulation doesn’t support inotify (which we use a lot in Discourse development). For now, I’ve added a warning to d/boot_dev when a non-x86_64 architecture is detected:

❯ d/boot_dev 
WARNING: Docker architecture is not x86_64.
Discourse development is unlikely to work using Docker's architecture emulation.
Please try a native development installation.

I’ve now added a d/ember-cli helper, and forwarded port 4200 by default. The info at the top of this topis has also been updated. Once you’ve updated, run d/rails s in one terminal, and d/ember-cli in another. I’ve also set NO_EMBER_CLI as one of the variables which is passed through to Docker, so that is available if needed.

6 Likes

@david probs inconsequential but just FYI: The boot_dev script prints out a false error finding on the x86_64 check when I accidentally ran without Docker on…(but the ‘Is the docker daemon running’ part is right)…

WARNING: Docker architecture is not x86_64.
Discourse development is unlikely to work using Docker's architecture emulation.
Please try a native development installation.
  ...(snip)...
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
1 Like

Thanks for this image, and the super-clear instructions!

I got psql: error: FATAL: Peer authentication failed for user "postgres" when running d/boot_dev --init.

Although the pg_hba.conf in data/postgres/ had all the authentication methods set to “trust”, there was another one in /etc/postgresql/13/main/ which had the defaults (“peer” / “md5”).

I edited /etc/postgresql/13/main/pg_hba.conf, changed all the methods to trust, did d/shell and ran sv restart postgres to pick up the changes – and was able to continue by running d/bundle install; d/rake db:migrate RAILS_ENV=development; d/rake admin:create manually.

Leaving here in case it’s helpful for anyone else!

1 Like

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.

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.

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

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.

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 Like

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 Like

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 Like

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

Ah, I guess environment variables can’t be used with docker exec like that. Oh well, at least opening the shell first works.

1 Like

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?

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)

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?