Gracias, Jay @pfaffman,
¡Sin duda, eres un recurso de primer nivel aquí!
¿Qué te parece esta idea quizás loca (basada en mi comprensión aún limitada)?
Configurar nginx como proxy inverso en el frontend; según este tutorial:
Luego, tener dos directorios / instancias con discourse_docker (standalone) configurados, por ejemplo:
- /var/discourse1
- /var/discourse2
En ambas instancias, configurar discourse_docker (standalone) para que escuche en un socket diferente, modificando esta plantilla en cada instancia:
- "templates/web.socketed.template.yml"
Así, en resumen, simplemente hemos reconstruido la producción (en un momento tranquilo) para que se ejecute en un contenedor diferente escuchando en un socket distinto (nginx.https.sock2), de modo que no haya conflicto de sockets; lo cual también podemos construir en modo standalone (con el objetivo de eliminar la necesidad de dos contenedores: data y web-only).
Por ejemplo (para discusión/ilustración), en web.socketed.template.yml en 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:;
y en 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:;
Sin embargo, en lugar de que la plantilla de Discourse haga la magia, simplemente cambiamos manualmente los sockets en /etc/nginx/conf.d/discourse.conf y reiniciamos nginx, por lo que eliminaríamos la directiva replace: en la plantilla web.socketed.template.yml.
En esta configuración propuesta (quizás una idea loca), podemos tener dos contenedores standalone escuchando en dos sockets diferentes (sin conflicto) y simplemente configurar nginx para que se conecte al socket que deseemos y reiniciar nginx.
Esto parece claro, sencillo y quizás útil (durante un periodo lento de cero nuevas publicaciones en la instancia en vivo) para quienes no quieran (o necesiten) la complejidad de dos contenedores (data y web-only) por una sola instancia de Discourse (aplicación).
Por supuesto, la configuración más robusta (desde una perspectiva de datos), sin embargo, para la perfección en sitios con mucho tráfico sería la solución de “dos contenedores”, ya que querríamos que las instancias data y web-only (ahora escuchando en dos sockets diferentes, sock y sock2) funcionen correctamente.
En la “solución de dos contenedores” con el frontend nginx, la “configuración estándar” es que ambos contenedores web-only escuchen en el mismo socket, por lo que no pueden ejecutarse simultáneamente; pero si (por ejemplo) los hiciéramos escuchar en un socket diferente, ambos podrían ejecutarse al mismo tiempo y simplemente usaríamos el archivo de configuración de nginx (y un reinicio de nginx) para alternar entre los dos.
¿Es esta la comprensión correcta?
¿Empiezo a (lenta pero seguramente) entender esto?
¡Gracias!
Nota solo de seguimiento: Tengo la configuración de “dos contenedores” funcionando en uno de mis Mac de escritorio:
La única salvedad en nuestra instalación fue la necesidad de crear manualmente estos directorios (y establecer la propiedad y los permisos), ya que por alguna razón los scripts no crean estos directorios:
~discourse/discourse/shared/data
~discourse/discourse/shared/web-only
y, por supuesto, al principio intenté con una contraseña vacía para la base de datos, y eso no funcionó (las instrucciones dicen establecer una contraseña, pero solo estaba experimentando).
A continuación, configuraré el frontend nginx y probaré el cambio a esa configuración con websocket para la aplicación web-only.