Beginners Guide to Install Discourse for Development using Docker

Technically you could get symlinks to work its just you would need to add another mount to the docker dev container. It would require a minor PR to discourse to add support to this, we could walk symlinks and smart mount or something in boot_dev.

1 Like

Does anyone know why the image from discourse is not loading in this mode?

I think this is why your image is not loading.

3 Likes

Thank you for your advice.

I wanted to install plugins, so based on your advice, I retried to google and I found this:


This works well.

Thank you again.

Need bunele install each shutdown_dev then boot_dev, it’s a problem?

I had problems running this on nixos, because the scripts were not POSIX complaint.
I solved the issue with these changes: make docker dev install posix compliant by spirobel · Pull Request #7995 · discourse/discourse · GitHub

4 Likes

Did you test all the helpers? It is quite a sweeping change

1 Like

I made a list of all the files and went through all of them. They all worked. Afterwards I ran the checkbashisms script on them and I discovered something very weird.

bin/docker/boot_dev x
possible bashism in bin/docker/boot_dev line 35 (should be VAR="${VAR}foo"):
what it is: ENV_ARGS+=" -e $2"

what would be sh complaint: ENV_ARGS="${ENV_ARGS} -e $2"

bin/docker/rails x
possible bashism in bin/docker/rails line 4 (alternative test command ([[ foo ]] should be [ foo ])):
if [[ $# = 1 ]] && [[ “$1” =~ “s” ]];
bin/docker/unicorn x
possible bashism in bin/docker/unicorn line 4 (alternative test command ([[ foo ]] should be [ foo ])):
if [[ $# = 1 ]] && [[ “$1” =~ “s” ]];

so why did the scripts still work even though they shouldnt?
nixos /bin/sh is actually bash. Probably its best to talk with the people at nixos what is going with this. They seem to be really strict about not having /bin/bash but whats the point if thats bash anyway? There seems to be an effort to get discourse to be a nix package aswell: https://github.com/NixOS/nixpkgs/pull/59981 Its probably really nice for deployment and testing (if it works). Anway…all I wanted to do is write a discourse plugin … and now I am reading about this. :laughing:

2 Likes

Yeah I am not against bin/sh but it needs to be ported and the scripts use bash-isms now.

Symlink bin/bash ?

1 Like

I will do that. I think this was all a waste of time. (sorry for that :upside_down_face: ) This problem is clearly on the side of nixos. It has many benefits and I like using it, but this thing was just weird.

3 Likes

The Docker development flow now supports plugin symlinks, with two caveats:

  1. The symlink must refer to its target with an absolute path:

    - ln -s ../../discourse-plugin
    + ln -s ~/src/discourse-plugin
    
  2. Whenever a new plugin symlink is created, the Docker container must be restarted:

    d/shutdown_dev; d/boot_dev
    

Hopefully someone else will also find this useful!

(Also updated the topic wiki)

4 Likes

This is awesome, thanks heaps for the new feature, real happy to have parity with this setup!

3 Likes

Trying to get to the rails console to run SiteSetting.enable_sso = false on a Mac Docker dev install. Where do I need to be to do that?

d/rails c

from the root directory of discourse.

3 Likes

Thanks so much, Sam.

For others seeing this, you have to follow the above exactly. e.g. you can’t use rails c from the the d directory.

From within the d directory you’d need to run ./rails c, rails c would give you whatever rails was in your path, not the one in d.

I am not sure if my issue is directly related to yours, but I had the same error message.
I was using the vagrant file mentioned at the bottom of GitHub - discourse/discourse_docker: A Docker image for Discourse

Then I was using the cloned discourse folder inside of /vagrant, e.g. part of my “outer host”. This was not working and I ended up with the above error message.

Once I cloned discourse into a folder outside of /vagrant (e.g. /home/vagrant/workspaces/discourse) everything worked as documented.

I hope that helps …

I’ve had a look through here and a quick google search to no avail: is there an obvious reason why a dev Discourse instance would close connections; and if not, is there a way to track down why it is doing so?

I have set up Docker and git clone'd as per the instructions in a new Virtualbox VM (two in fact, first Arch, then Ubuntu Server 19.10).

./bin/docker/boot_dev --init goes fine, admin account set up without complaints. I run ./bin/docker/unicorn (with or without sidekiq) and it reports I, [2019-11-01T17:24:29.121913 #234] INFO -- : listening on addr=127.0.0.1:9292 fd=33.

From there I browse to http://$VM_IP:9292, and it refuses to connect. Even trying telnet fails:

bertieb@ubunutu-vm:~/discourse$ telnet 127.0.0.1 9292
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.

There is no obvious error in the logs or reported in unicorn’s output.

This happens with docker versions:

  • Docker version 18.06.1-ce, build e68fc7a (Ubuntu system repo)
  • Docker version 19.03.3-ce, build a872fc2f86 (Docker repos)
  • Docker version 19.03.4-ce, build 9013bf583a (Arch)

Is the issue particular to VMs? The Docker versions? The versions of Ubuntu/Arch I’m using? Something else entirely?

(PS: I ran the tests on one of the VMs, they completed after 15 minutes with only one failure, something to do with a default favicon. I didn’t save the output as it seemed unrelated to the issue, but I can run the tests again if needed)

1 Like

This was an issue but is now resolved as of FEATURE: allow publishing docker dev either locally or net wide · discourse/discourse@ff33899 · GitHub.

Connectivity now works as intended. If like me you happened to install a dev version after ~28th Oct but before today, git pull to update. Note the new -p flag to d/boot_dev if you want to listen for remote connections.

6 Likes

The problem is that the user within the docker container has an id of 1000 so unless your user also has an id of 1000 you will get permission denied when it tries to make changes to the local files / create new files.

I think the directories are:

  • tmp
  • app/assets/javascripts/plugins
  • public
  • log
  • db
2 Likes