Multisite vs múltiplos contêineres

Does anyone know the pros and cons of multisite vs multiple containers?

I currently have three Discourse instances as separate containers, and am thinking about converting two, maybe three more forums to Discourse - they’ll be on the same server (64GB RAM, running SSDs) so I’m wondering what might be the best way forward.

I’d prefer them to be as independent as possible, so each can be upgraded individually, backed up and restored individually, and issues with one should not affect another.

What do you suggest? Any pros and cons to look out for?

You won’t be able to upgrade individually with multisite, nor will you be able to segment plugins used. All of that is defined by the root multisite. Settings, themes, and backups can all happen separately, though.

Generally you’ll need a proxy in front to help with SSL certs, too.

3 curtidas

Actually, I’ve worked out a way to get let’s encrypt to get certs for multiple domains and not redirect to the primary domain. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, would you be interested in testing my howto? I’m 90% sure that it works, but it was some weeks ago that I last tested and I’m not entirely sure that the instructions “work” for someone who’s not me.

If you want all the sites to have the same plugins and be upgraded all at the same time, multisite is great.

3 curtidas

I could just switch off any unused plugins via the ACP (and I think there’s only one that one of the forums won’t need) so I guess it depends on are there any benefits to doing multisite? Specifically, performance and/or stability?

I think I read @Blake once post that it’s insane not to run PG in it’s own container (is that different to multisite?) hence why I’ve been thinking about doing this. Btw don’t quote me on what Blake said I could have well dreamt it :rofl:

I use HAProxy which deals with our SSL certs so I ‘think’ that may be ok.

I think it will depend on the benefits Jay - if there’s not much difference then I don’t mind carrying on as I have been as it’s become relatively easy to set-up and manage, but if there are some big advantages to going multisite I would definitely be interested :sunglasses:

The other advantage is that you’re running just one more copy of rails and nginx, so the additional RAM required is much less. You’ve got lots of RAM, though, so going with what works already is starting to sound like the best idea.

2 curtidas

Olá. É possível combinar usuários de um multisite para que um usuário possa ser registrado em todos os multisites ao mesmo tempo, registrando-se em um dos sites (como no Magento)? Ou uma supervariante de usar o Discourse, semelhante à federação. Para que os alertas funcionem de forma síncrona e o usuário do site nº 1 possa receber alertas do site nº 2? O mesmo vale para o chat.
Tenho 4 comunidades da mesma grande direção, mas com tópicos diferentes, e gostaria que essas comunidades fossem intimamente integradas umas às outras

Você pode fazer com que um site seja o servidor de autenticação do Discourse Connect e ter todos os outros autenticando contra ele.

2 curtidas

Estou tentando descobrir se preciso de uma configuração multi-site, múltiplos contêineres ou outra coisa.

Atualmente, tenho 3 comunidades independentes, duas delas semelhantes (ambas sobre esportes universitários, mas para duas escolas separadas) e a terceira sobre culinária e panificação.

Gostaria que todas estivessem no mesmo servidor (devido às limitações de endereço IP do meu provedor de internet), mas em URLs separadas, algo como isto:

foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking

team1.bar.com redirecionando para foo.bar.com/team1, etc., ou para servidores virtuais separados, também seria aceitável. (Sei que o Apache pode fazer isso, então presumo que o nginx também possa, diretamente ou com um servidor proxy na frente.)

Idealmente, o próprio foo.bar.com serviria como um gateway para essas comunidades independentes, explicando o que são e como acessá-las. Algumas categorias em cada comunidade podem ser lidas publicamente e acessíveis por rastreadores da web para que apareçam nas pesquisas da web.

Isso é uma configuração multi-site ou multi-contêiner, ou algo totalmente diferente?

Existem armadilhas de design de plugin conhecidas ao executar Multisite?

Parece que meu Chatbot não suporta Multisite (portanto, é um problema conhecido), mas eu gostaria de entender o porquê: ele está funcionando bem na instalação padrão.

Especificamente, parece haver problemas com a tarefa de configuração do banco de dados e potencialmente este job.

1 curtida

Vou dar uma atualização sobre minha situação.

Após algum estudo, decidi que precisava de uma configuração multissite (um contêiner neste momento) com um site nginx ‘externo’ para explicar a configuração e direcionar pessoas e tráfego para os sites discourse separados. Dessa forma, eu poderia tornar ambos os sites abertos para acesso somente leitura (e rastreadores da web) sem que as pessoas da lista1 tivessem que lidar com o conteúdo da lista2. Talvez eu precise mexer no robots.txt para deixar os rastreadores da web felizes.

Os exemplos de configuração multissite foram instrutivos, mas não consegui fazê-lo funcionar com um soquete unix (erro de gateway), então acabei redirecionando-os para outra porta e redirecionando essa porta para 443 dentro do contêiner.

No meu arquivo app.yml, ativei o template SSL, mas não o letsencrypt.

Consegui fazer o site de teste funcionar, agora estou procurando por quaisquer problemas que possam surgir ao converter o site de produção, espero que ainda este mês ou no próximo.

Estou cuidando da questão do certificado no lado do servidor externo, mas me deparei com o problema de ‘não seguro’ que corrigi exigindo https no contêiner. Tenho uma tarefa que executarei via cron para copiar o certificado e a chave mais recentes para o diretório /shared/ssl do contêiner (como ssl.crt e ssl.key). Não tenho certeza se precisarei forçar um recarregamento do nginx dentro do contêiner para garantir que um novo certificado seja carregado quando ele mudar (em julho, acho).

Encontrei um outro problema do discourse:

No arquivo /etc/nginx/conf.d/discourse.conf do contêiner, há este fragmento de código (nome do domínio alterado):

if ($http_host != ‘site1.my.domain’) {
rewrite (.*) https://site1.my.domain$1 permanent
}

Isso estava fazendo com que site2.my.domain fosse redirecionado para site1.my.domain, então tive que comentá-lo.

NOTA: Reconstruir o contêiner requer refazer esta edição, há alguma maneira de evitar isso?

E isso levou a um problema no navegador, porque agora o firefox havia sinalizado esse redirecionamento como permanente, então tive que excluir o cache do navegador. (Isso me levou muito tempo para descobrir!)

Consegui pensar em outra coisa estranha.

No meu site de teste, o parâmetro para exigir https não estava marcado para nenhum dos sites. No meu site de produção, esse parâmetro nem sequer está presente no arquivo de configurações. Estou imaginando que isso tem algo a ver com as diferenças entre os dois sites.