Grazie Jay @pfaffman,
Sei davvero una risorsa di altissimo livello qui, senza dubbio!
Cosa ne pensi di questa idea, forse un po’ pazza (basata sulla mia ancora limitata comprensione):
Configurare nginx come reverse proxy sul front-end; seguendo questa guida:
Poi impostare due directory / istanze con discourse_docker (standalone), ad esempio:
- /var/discourse1
- /var/discourse2
In entrambe le istanze, configurare discourse_docker (standalone) per ascoltare su socket diversi, modificando questo template in ciascuna istanza:
- "templates/web.socketed.template.yml"
Quindi, in sintesi, abbiamo semplicemente ricostruito la produzione (in un momento tranquillo) per eseguire un contenitore diverso in ascolto su un socket diverso (nginx.https.sock2), in modo da non esserci conflitti di socket; che possiamo costruire anche in modalità standalone (con l’obiettivo di eliminare la necessità di due contenitori, data e web-only).
Ad esempio (per discussione / illustrazione), 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:;
e 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:;
Tuttavia, invece di far fare la magia al template di Discourse, semplicemente commutiamo manualmente i socket in /etc/nginx/conf.d/discourse.conf e riavviamo nginx, quindi rimuoveremmo la direttiva replace: nel template web.socketed.template.yml.
In questa configurazione proposta (forse un’idea pazza), possiamo avere due contenitori standalone in ascolto su due socket diversi (non in conflitto) e semplicemente configurare nginx per connettersi al socket desiderato e riavviare nginx.
Sembra chiaro, semplice e forse utile (durante un periodo di calma con zero nuovi post nell’istanza live) per coloro che potrebbero non voler (o aver bisogno) della complessità di due contenitori (data e web-only) per una singola istanza di Discourse (app).
Ovviamente, la configurazione più robusta (dal punto di vista dei dati), tuttavia, per la perfezione sui siti molto trafficati sarebbe la soluzione a “due contenitori” perché vorremmo avere l’istanza data e quella web-only (ora in ascolto su due socket diversi, sock e sock2).
Nella “soluzione a due contenitori” con il front-end nginx, la “configurazione standard” prevede che entrambi i contenitori web-only ascoltino sullo stesso socket, quindi non possono essere eseguiti contemporaneamente; ma se (ad esempio) li facessimo ascoltare su socket diversi, potrebbero essere eseguiti entrambi contemporaneamente e potremmo semplicemente utilizzare il file di configurazione nginx (e un riavvio di nginx) per passare da uno all’altro.
È questa la comprensione corretta?
Sto iniziando a (lentamente ma spero sicuramente) capire?
Grazie!
Nota di seguito solo: Ho la configurazione a “due contenitori” funzionante su uno dei miei Mac desktop:
L’unica accortezza nella nostra installazione è stata la necessità di creare manualmente queste directory (e impostare proprietà e permessi) poiché queste directory non vengono create per qualche motivo dagli script:
~discourse/discourse/shared/data
~discourse/discourse/shared/web-only
e naturalmente, all’inizio ho provato con una password vuota per il database, ma non ha funzionato (le istruzioni dicono di impostare una password, ma stavo solo sperimentando).
Prossimo passo: configurerò il front-end nginx e proverò il passaggio a quella configurazione con websocket per l’app web-only.