- Traefik grabs the first port it sees, which on the dev image is 1080- we want port 9292. Use
- You need to set a dev host using en env var in the container:
-e DISCOURSE_DEV_HOSTS=your_dev_hostname \
With the dev version of Discourse working, I wanted to let its connectivity be managed by the traefik proxy. But whichever way I sliced it, I would get a
Bad Gateway error. The usual suspect for this is not setting a port, or having the service on a different network from traefik itself. However, this issue persisted for me.
I had to add the following to
(discourse_source_root)/bin/docker/boot_dev, in the
docker run ... section:
DEVHOST=<my dev host> earlier in the file, or you can use the host there directly. The last line points traefik at the correct port (9292) in the discourse-dev container.
Accessing by host then produces a page with a blocked host error:
Blocked host: discourse_dev_host
To allow requests to discourse_dev_host, add the following to your environment configuration:
config.hosts << “discourse_dev_host”
DISCOURSE_DEV_HOSTS permits access on those hosts. We need to do this in the container, so add the following to the same section in the same file:
-e DISCOURSE_DEV_HOSTS=$DEVHOST \
Which permits access via that (or those) hostname(s).
tl;dr: this was a temporary issue solved by a later commit, if you checked out discourse after 28 Oct but before 4 Nov,
git pull to update
Having installed a production Discourse forum, I wanted to get a local dev instance up and running for testing.
There are good instructions for doing just that using Docker. Don’t do what I did: follow the production install method and assume that will work by pointing the prod hostname at it in
Unfortunately, when I followed the instructions to set up the dev instance, I was greeted with an ‘Unable to connect’ screen. (
ERR_FAILED). Even using telnet from the same host failed:
bertieb@ubunutu-vm:~/discourse$ telnet 127.0.0.1 9292
Connected to 127.0.0.1.
Escape character is '^]'.
Connection closed by foreign host.
Dang. I tried this across fresh Arch and Ubuntu Server (19.10 + 18.04.3 LTS) installs and got the same thing.
Installing the non-Docker version worked but only for localhost; then a comment on that guide’s topic pointed me at a recent change to interface binding. Checking out the commit before that change let me connect from other hosts in both the Docker and non-Docker versions.
As of 2019-11-04 a later commit sorted this issues and added a specific flag (
-b) for permitting connections from other hosts.
I set up a Discourse server today. It was pleasantly straightforward. The official docs work well enough, though there are a few things I did:
- integrated with existing nginx sites by cribbing from this guide (short version: forward Discourse requests to a socket)
- set up email delivery via MailJet- their admin interface makes getting credentials and setting up + verifying SPF and DKIM records simple
- set up
certbot to generate LetsEncrypt certs (thanks Arch wiki) and get HTTPS rolling (bonus: https for existing sites for free!)
- added SSO for GitHub and Discord (short version: create the applications on the respective sites, support for these Oauth is baked in)
DenyUser, locking myself out of ssh access
Maybe skip the last one if you’re doing the install yourself?