Obrigado, Jay @pfaffman,
Você é realmente um recurso valioso de primeira linha aqui, sem dúvida!
O que você acha dessa ideia talvez maluca (baseada no meu entendimento ainda limitado):
Configurar nginx como um proxy reverso na parte frontal; conforme este tutorial:
Em seguida, ter dois diretórios / instâncias com o discourse_docker (standalone) configurado, por exemplo:
- /var/discourse1
- /var/discourse2
Em ambas as instâncias, configure o discourse_docker (standalone) para escutar em um socket diferente, modificando este modelo em cada instância:
- "templates/web.socketed.template.yml"
Então, em resumo, nós simplesmente reconstruímos a produção (em algum momento tranquilo) para rodar em um container diferente, escutando em um socket diferente (nginx.https.sock2). Assim, não há conflito de sockets; o que podemos construir também em modo standalone (com o objetivo de eliminar a necessidade de dois containers, data e web-only).
Por exemplo (para discussão / ilustração), em web.socketed.template.yml no 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 no 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:;
No entanto, em vez de deixar o modelo do discourse fazer a mágica, nós simplesmente trocamos manualmente os sockets em /etc/nginx/conf.d/discourse.conf e reiniciamos o nginx. Assim, removeríamos a diretiva replace: no modelo web.socketed.template.yml.
Nesta configuração proposta (talvez ideia maluca), podemos ter dois containers standalone escutando em dois sockets diferentes (sem conflito) e simplesmente configurar o nginx para se conectar ao socket que desejamos e reiniciar o nginx.
Isso parece claro, fácil e talvez útil (durante um período lento de zero novas postagens na instância ao vivo) para aqueles que podem não querer (ou precisar) da complexidade de dois containers (data e web-only) por uma única instância do Discourse (app).
Claro, a configuração mais robusta (do ponto de vista dos dados), no entanto, para a perfeição em sites movimentados seria a solução de “dois containers”, pois quereríamos as instâncias data e web-only (agora escutando em dois sockets diferentes, sock e sock2).
Na solução de “dois containers” com o front-end nginx, a “configuração padrão” é fazer com que ambos os containers web-only escutem no mesmo socket, de modo que ambos não possam rodar ao mesmo tempo; mas se (por exemplo apenas) fizéssemos com que escutassem em sockets diferentes, ambos poderiam rodar ao mesmo tempo e poderíamos apenas usar o arquivo de configuração do nginx (e um reinício do nginx) para alternar entre os dois.
Essa é a compreensão correta?
Estou começando a (lentamente, mas espero que com certeza) entender isso?
Obrigado!
Nota de Acompanhamento Apenas: Tenho a configuração de “dois containers” funcionando em um dos meus Macs de desktop:
As únicas ressalvas na nossa instalação foram a necessidade de criar manualmente esses diretórios (e definir a propriedade e as permissões), pois esses diretórios não são criados por algum motivo pelos scripts:
~discourse/discourse/shared/data
~discourse/discourse/shared/web-only
e, claro, no início tentei com uma senha em branco para o banco de dados, e isso não funcionou (as instruções dizem para definir uma senha, mas eu estava apenas experimentando).
Em seguida, configurarei o front-end nginx e tentarei a migração para essa configuração com websocket para o app web-only.