Running other websites on the same machine as Discourse

(Brahn) #23

Can you include the binding address in app.yml expose?

  - ""

(Kane York) #24

Even better - it can be done with just a Unix socket and no ports exposed. I’m working on getting instructions to do that.

(Helmi) #25

any news on that topic? Probably a chance to just bind to localhost?

Tried playing around with ufw (which basically is of course only a frontend to iptables) and seeing the same problem of ports getting exposed to the public even though blocked in ufw.

(blaumeer) #26

@helmi I believe it is possible to include the binding address in app.yml expose stanza, but did not try myself on a test instance yet. In this way you could do without iptables/ufw.

(Kane York) #27

Yes, this is possible and… might be the correct syntax.

(Jonathas Spalding) #28

Yes, this is the correct syntax. I’m running Discourse with separated app and data (postgres/redis) containers plus another container linked to the data accessing the postgres database.

Check it here: How to use Docker multiple containers without exposing ports

(Helmi) #29

funny, that didn’t work this morning. Got an error when rebuilding. Now it works. Thanks, guys.

(Stefan) #30

I’m trying to follow the instructions in this topic to setup a multi-container instance with other websites running on the same droplet, but it seems that web_only still binds to even if I edit web_only.yml and use

 - ""

Is there anything else I need to do beside editing the yml file and running ./launcher rebuild web_only?

(Stefan) #31

I’m sorry, I’m being stupid. I should have other port in web_only.yml, not 80. I’ll give it another try.

(Christopher Heald) #32

I use Digital Ocean’s self-supported Discourse hosting, and followed a slightly different procedure to get Wordpress hosted and running on the same server, with Discourse accessible through a subdomain, using Nginx.

This Need help with installing Discourse and Wordpress | DigitalOcean will take you through all the steps.

The tl;dr version: set Discourse to serve on another port than 80 (I used 8080), and the Nginx ‘site’ config to have Wordpress on the root domain, and Discourse on a ‘community.’ subdomain, is as follows:

upstream community {
    server fail_timeout=0;

server {
        listen 80 default_server;

        root /var/www/html/wordpress;
        index index.php index.html index.htm;

        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;

        error_page 404 /404.html;

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
                root /usr/share/nginx/html;

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;

server {
      listen 80;

      root /usr/share/nginx/html;
      index index.html index.htm;

      client_max_body_size 10G;

      location / {
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_redirect off;
          proxy_pass http://community;

(Timmmmyboy) #33

Hmmm, had this working for several months and then when Linode had an outage and came back I’m getting gateway errors. Looking at the logs for Discourse I see a bunch of lines that read:

nginx: [emerg] bind() to unix:/shared/nginx.http.sock failed (98: Address already in use)

I’ve tried stopping nginx and restarting the containers as well as rebuilding them but doesn’t seem to make a difference. Any idea where I’ve gone wrong?

(Kane York) #34

Try killall nginx and start it again?

(Timmmmyboy) #35

No go, even when I killall nginx and rebuild the server from the logs as soon as unicorn workers start I get multiple errors that the nginx address is already in use. What’s odd is that this server has been rebooted before without issues. I don’t know what changed to suddenly block nginx from working inside any of the containers but even when it’s killed at the server level it’s still not able to get the containers working.

(Kane York) #36

What happens if you do this?

  • stop the server
  • rm /var/discourse/shared/standalone/nginx.http.sock

Also remember to restart your outer nginx server because you just killed it :stuck_out_tongue:

(Timmmmyboy) #37

Ah, deleting the nginx.http.sock file in each of the Discourse shared folders did it. Thank you so much! I had thought about that but was too afraid of deleting anything without reaching out first.

(Kane York) #38

I was too, which is why it wasn’t the first thing I had you do :wink:


Yeah, this issue has plagued me as well. Maybe we can have some sort of failsafe to ensure that this doesn’t break Discourse?

(Robert) #40

I cannot access the discourse.conf.txtfile. Would you mind to paste it somewhere? i have a similar setup.

Thanks for sharing! :thumbsup:

(Kane York) #41

I think that’s a bug, where uploaded files are 404ing… @zogstrip?

(Robert) #42

If I remember correctly I checked the server response and it’s just an empty 200.