Alta Disponibilidade do Discourse

Has anyone played with a HAProxy/nginx/etc?

I could have sworn there was a how-to guide for a way to do distributed hosting, either via Docker or via multiple instances of Discourse all hitting a single high availability database server, but I can’t seem to find a guide for it.

Any thoughts? I’m currently serving a small single Discourse site, but am interested in learning as much as I can about scaling and load balancing of Discourse.

5 curtidas

Found it, less than fifteen minutes after I posted. I’ll put any info on snags or clarifications that might be helpful into the conversation here.

The documentation is very fragmented. I’m going to attempt to pull it all together here.

Any chance I could get some input from @nx2zdk or @jspdng?

Info on avoiding port exposure:

Load balancing with nginx:

Enabling http2 on Debian:

Offline page setup:

Não consegui encontrar respostas próximas em outros lugares.
Entendi que a instalação autônoma do Discourse é recomendada por sua simplicidade e robustez em ambientes padrão. No entanto, para fornecer Alta Disponibilidade (HA), alguns sugerem expandir o modo autônomo para vários contêineres (29413), outros redesenham implantações totalmente separadas.

  1. Pergunta 1: Como HA é sobre duplicar serviços (web e banco de dados) com failover confiável, o Discourse propõe tal solução onde tanto os serviços web quanto os bancos de dados são replicados dentro de contêineres?
  2. Pergunta 2: Para os serviços web, um balanceador de carga seria necessário para garantir a equidade de carga entre as instâncias. Quais são as recomendações dos especialistas e da comunidade Discourse?
  3. Pergunta 3: Para HA de banco de dados em contêineres, qual é a maneira mais preferível de gerenciar a replicação do PostgreSQL?
  4. Pergunta 4: Mesma pergunta para o Redis.

Existem várias maneiras de lidar com o failover do postgres. Você pode usar o que quiser.

A hospedagem CDCK usa HA-proxy, pelo que me lembro. Você pode usar qualquer balanceador de carga que quiser e (na maioria das vezes) usar /srv/status como um indicador de prontidão.

1 curtida