Run other websites on the same machine as Discourse

You will have to make changes by hand to make it work behind the reverse proxy. Assuming that you know how to do that and do it after you create the app.yml with
This might work:

./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup

Then you’d edit app.yml to be behind the reverse proxy.

2 Likes

Getting mixed content warnings when discourse is listening on a unix socket. Fresh install.

1 Like

If I remember correctly, that’s the cached logo (I assume you have enabled the force https parameter). Could you check it in the browser dev tool/network tab?

2 Likes

Kindly mark this as resolved. I had to force https setting and (also do a rake search replace to add the subdirectory path). The main is running Apache along with many other sites. For this one example.org we have WordPress installed and doing Apache reverse proxy for /forums with Discourse listening at a websocket.

2 Likes

Instead of @riking’s method at the top?
Do you have a link to a walkthrough on how to do it the “double NGNIX” way?
Sadly, I know nothing of NGINX, but the walk through by @riking seems simple enough, but if there’s a better way, I’d appreciate the details on that.

1 Like

Hi there!
We installed Discourse through cloning files from the Git repository and did what you suggested; but we handled the SSL protocol using Nginx proxy manager (We commented out the port 443 exposing part in app.yml ).
We are using portainer v2.11.0 in which we can see the Discourse container that is successfully created but we cannot run the website and receive a 502 bad gateway error.

Any idea how we can fix the error?

1 Like

Did you also remove the ssl and lets encrypt certificates?

1 Like

See:


Do you use socket install like this:

Then see: How to debug a sub-folder Discourse install

Wouldn’t it be reasonable to configure the outside proxy to connect to Discourse directly rather than to the Nginx proxy within the container (having everything double-proxied)? Or does the internal Nginx proxy serve an important task which an outside proxy cannot handle?

Hello, what can I do if there’s no nginx.sock file?

❯ ls /var/discourse/shared/standalone/
backups  postgres_backup  postgres_run  state  uploads
log      postgres_data    redis_data    tmp

Did you include the template?

3 Likes

I am trying to install Discourse on my Raspberry Pi 4 using Dietpi OS and some apps working with nginx like Nextcloud. I am trying to use Cloudflared service as a tunnel but after the Discourse installation is complete I can’t find Discourse service port for creating a tunnel. When I connect to localhost the Nginx starting page comes up. Where do I access the Discourse site?

FYI: I am not configured certbot because i want to use Cloudflared service.

1 Like

Hello, I am trying to install Discourse behind GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen but I can’t figure out how to do this.

I tried exposing discourse’s socket to the nginx-proxy container and adding a per virtual host location configuration without success.
I have successfully set up other services behind that proxy and I’m only missing discourse. Would you have some advice please ?

1 Like

Did you look at Using Nginx Proxy Manager to manage multiple sites with Discourse?

1 Like

Out of curiosity what are the pros and cons between the following two approaches?

  1. NGINX and exposing a port
  2. NGINX and templates/web.socketed.template.yml

For some reasons I can start NGINX and serve pages and start Discourse without NGINX without issues. But when I use the first approach I always get the following errors.

/var/discourse/shared/web-only/log/rails/production.log
Job exception: Error connecting to Redis on data:6379 (Redis::TimeoutError)

/var/discourse/shared/web-only/log/rails/unicorn.stderr.log
Failed to report error: Error connecting to Redis on data:6379 (Redis::TimeoutError) 3 heartbeat: Error connecting to Redis on data:6379

And when I use the second approach it wouldn’t even build when running ./launcher rebuild <app>. It’d give me an error like:

I, [2022-09-12T08:54:16.483648 #1]  INFO -- : > cd /var/www/discourse && git fetch --depth 1 origin tests-passed
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com
I, [2022-09-12T08:54:56.561225 #1]  INFO -- : 


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && git fetch --depth 1 origin tests-passed failed with return #<Process::Status: pid 35 exit 128>

type or paste code here

1 Like

Are you using a web_only container but not running a data container?

1 Like

I did not, thanks.
I modified my app.yml so that the discourse container runs in the same named network as my proxy.

Then I added the _location configuration as advised by the nginx-proxy doc with this thread’s values, and made the discourse socket available (at the same path as the host for simplicity).
However it seems there’s a permissions issue somewhere but I don’t really know what : the configuration is picked up by nginx, then when doing an https request I have this error

[crit] 230#230: *21 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: <ip>, server: <domain>, request: "GET / HTTP/1.1", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"

Inside the container:

# ls -lah /var/discourse/shared/standalone/
total 12K
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 .
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 ..
drwxr-xr-x 2 root root 4.0K Sep 12 09:19 nginx.http.sock

Edit : this was an issue due to containers started with and without sudo.
However now I have this:

[error] 219#219: *94 no live upstreams while connecting to upstream, client: <client-ip>, server: <domain>, request: "HEAD / HTTP/2.0", upstream: "http://<domain>/", host: "<domain>", referrer: "http://<domain>"

and a 502 bad gateway error

1 Like

Actually both. I can see both running when using docker ps. Literally the only difference is just enabling or disabling the expose section although now that I think about it I wonder if I need to comment the line expose: as well and not the list of ports within it.

1 Like

Sorry for the double post, I got confused previously by another unrelated matter and the socket was not used anymore because of an error in my configuration.
Here’s where I’m at:

[crit] 274#274: *7 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"

I did chmod 777 shared/standalone/nginx.http.sock to temporarily workaround this permission issue, and now I got

[error] 203#203: *1 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"

Obviously I am doing some things wrong but I don’t know what. Please note that I’m not using NPM but nginx-proxy which is a bit different, in particular it automatically detects docker containers that define VIRTUAL_HOST to generate a config for them. Hence I only added the location / { ... } part related to discourse and did not touch the sites-available files with the listen directives.

I noticed the discourse container is in a restart loop with status Restarting (100) 7 seconds ago. This is because it complains about not being able to delete the socket. Indeed, it was not an actual socket but a directory instead, I guess because of bad manipulations of mounting volumes to expose it to the nginx-proxy container.
I removed the directory, restarted discourse and it is now a socket. However I can’t expose it as a volume to nginx-proxy

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting “/var/discourse/shared/standalone/nginx.http.sock” to rootfs at “/var/discourse/shared/standalone/nginx.http.sock”: mount /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type

Turns out, I just needed to mount the socket in /tmp/nginx.http.sock instead of keeping the same path. Finally managed it it seems!

2 Likes

Found the issue of why exposing a port in /var/discourse/containers/web_only.yml as follow wasn’t working.

expose:
  # - "443:443"
  # - "80:80"
  - "8080:80"  # https

Per Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All it was SELinux at play and need to permit NGINX to access Discourse by running or setting SELinux to Permissive mode.
setsebool -P httpd_can_network_connect 1

Now what’s interesting is that if NGINX’s config is set to root path it is working fine but not when it’s set to a non root path.

NGINX set to forward / to Discourse (working)

    # Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
    location / {
        proxy_pass          http://127.0.0.1:8080;
        proxy_set_header    Host $http_host;
        proxy_http_version  1.1;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_set_header    X-Real-IP $remote_addr;
    }

NGINX set to forward /discussions/ to Discourse (not working)

    # Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
    location /discussions/ {
        proxy_pass          http://127.0.0.1:8080;
        proxy_set_header    Host $http_host;
        proxy_http_version  1.1;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_set_header    X-Real-IP $remote_addr;
    }

In this case I’m seeing the following … My gut feeling is that even though NGINX have successfully forwarded the non root path /discussions/ to the Discourse docker, Discourse itself is still loading pages from itself and expecting assets are at the root path /. Guess it’s a requirement to run Discourse at only root path? @pfaffman have you seen this before?

/var/log/nginx/example.com.error.log

2022/10/01 09:33:23 [error] 1954781#1954781: *1 open() "/etc/nginx/html/images/discourse-logo-sketch.png" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /images/discourse-logo-sketch.png HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/discussions/"
2022/10/01 09:33:25 [error] 1954781#1954781: *1 open() "/etc/nginx/html/service-worker.js" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /service-worker.js HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/service-worker.js"

1 Like