Thank you Jay @pfaffman,
You are really a top-shelf valuable resource here, without a doubt!
What do you think about this maybe crazy idea (based on my still limited understanding):
Set up nginx as a reverse proxy on the front end; per this tutorial:
Then have two directories / instances with discourse_docker (standalone) set up, for example:
- /var/discourse1
- /var/discourse2
In both of these instances set up discourse_docker (standalone) to listen on a different socket, modifying this template in each instance:
- "templates/web.socketed.template.yml"
So, in a nutshell, we have simply rebuilt production (at some quiet time) to run in a different container on listening on different socket (nginx.https.sock2), so there is no socket conflict; which we can build in standalone mode as well (with the goal of eliminating the need need for two containers, data and web-only).
For example (for discussion / illustration), in web.socketed.template.yml in discourse1:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 80;/
to: |
listen unix:/shared/nginx.http.sock;
set_real_ip_from unix:;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen unix:/shared/nginx.https.sock ssl http2;
set_real_ip_from unix:;
and in discourse2:
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 80;/
to: |
listen unix:/shared/nginx.http.sock2;
set_real_ip_from unix:;
- replace:
filename: "/etc/nginx/conf.d/discourse.conf"
from: /listen 443 ssl http2;/
to: |
listen unix:/shared/nginx.https.sock2 ssl http2;
set_real_ip_from unix:;
However, instead of having the discourse template do the magic, we simply manually
switch sockets in /etc/nginx/conf.d/discourse.conf and restart nginx, so we would remove the replace: directive in the web.socketed.template.yml template.
In this proposed (maybe crazy idea) configuration, we can have two standalone containers listening on two different sockets (not in conflict) and simply configure ngnix to connect to the socket we wish to connect to and restart nginx.
This seems clear, easy and perhaps useful (during a slow period of zero new posts in the live instance) for those who might not want (or need) the complexity two containers (data and web-only) per a single discourse instance (app)
Of course, the most robust configuration (from a data perspective) however, for perfection for busy sites would be the “two container” solution because we would want the data and the web-only instance (now listening on two different sockets, sock and sock2.
In the “two container solution” with the nginx front-end, the “standard configuration” is to have both web-only containers listen on the same socket, so both cannot run at the same time; but if (for example only) we had them listen on a different socket, they could both run at the same time and we could just use the nginx config file (and a nginx restart) to switch between the two.
Is this the right understanding?
Am I starting to (slowly but hopefully surely) understand this?
Thanks!
Followup Note Only: I have the “two container” config working on one of my desktop macs:
The only caveats in our install was the need to manually create these directories (and set ownership and perms) as these directories get not get created for some reason by the scripts:
~discourse/discourse/shared/data
~discourse/discourse/shared/web-only
and of course, at first I tried with a blank password for the database, and that did not work (the instructions do say to set a password, but I was just experimenting).
Next, will set up the nginx frontend and try the move to that configuration with websocket for the web-only app.