Configuração do Discourse HA em ambiente com rede isolada

Obrigado antecipadamente.
Estou planejando configurar o Discourse com alta disponibilidade em um ambiente de produção. Abaixo estão meu plano de design e algumas condições ambientais.

  1. Configuração com 3 servidores de aplicação e 2 servidores de banco de dados Postgres. Sempre um servidor PG em modo de escrita e outro em modo somente leitura.

  2. Esses 3 servidores de aplicação apontarão para o mesmo servidor de banco de dados.

  3. Cada instância do banco de dados deve servir operações de leitura e escrita apenas, respectivamente.

  4. Servidores de produção não têm conectividade com a internet, mas posso baixar imagens do dockerHub.

  5. Temos nosso próprio servidor GitLab.

  6. É possível inicializar uma imagem Docker e essa imagem em vários servidores?

Por favor, alguém ajude a fazer essa configuração. Se houver links ou sugestões, envie-me uma mensagem privada.

2 curtidas

Após executar ./launcher bootstrap app em algum lugar, você precisará salvar essa imagem de contêiner resultante (geralmente feito enviando-a para um registro) e, em seguida, baixar e executá-la em seus três servidores de aplicativos.

Você também precisará de um servidor Redis central (e potencialmente réplicas para ele). Você também está perdendo um balanceador de carga para direcionar as solicitações para esses diferentes servidores de aplicativos.

3 curtidas

Obrigado pela resposta @Falco

Estamos usando o balanceador de carga HAProxy e o repositório Nexus para armazenar artefatos.

1 curtida

Olá @Falco
No meu ambiente de produção, não tenho acesso à internet, então o que estou planejando é realizar o bootstrap em uma máquina acessível pela internet, levando essa imagem de bootstrap para os servidores de produção. Ao fazer isso na VM de produção, o contêiner não está iniciando porque o servidor Unicorn está procurando um ID de processo pai, por isso ele não está em execução.
Por favor, me ajude aqui, preciso copiar o diretório /var/discourse após o bootstrap para o servidor de produção?

O que é “isto”? O bootstrap ou a execução da imagem de contêiner previamente inicializada?

1 curtida

Quando estou executando a imagem de contêiner previamente inicializada

Como você salvou e exportou a imagem para o servidor de produção?

Como, exatamente, você está tentando executar essa imagem salva em produção?

1 curtida

imagem previamente inicializada enviando para o repositório Nexus e, do repositório Nexus, puxando para o servidor de produção.

comando docker run gerado a partir de ./launcher start-cmd app e executando o mesmo comando no servidor de produção.

1 curtida

Você pode compartilhar o log de erros ao iniciá-lo em produção?

run-parts: executando /etc/runit/1.d/00-ensure-links
run-parts: executando /etc/runit/1.d/00-fix-var-logs
run-parts: executando /etc/runit/1.d/01-cleanup-web-pids
run-parts: executando /etc/runit/1.d/anacron
run-parts: executando /etc/runit/1.d/cleanup-pids
Limpando arquivos PID obsoletos
run-parts: executando /etc/runit/1.d/copy-env
Iniciado runsvdir, PID é 42
chgrp: grupo inválido: 'syslog'
ok: run: redis: (pid 51) 0s
ok: run: postgres: (pid 56) 0s
supervisor pid: 53 unicorn pid: 75
config/unicorn_launcher: linha 71: kill: (75) - Processo não encontrado
config/unicorn_launcher: linha 15: kill: (75) - Processo não encontrado
(53) saindo
ok: run: redis: (pid 51) 7s
ok: run: postgres: (pid 101) 0s
supervisor pid: 96 unicorn pid: 103
config/unicorn_launcher: linha 71: kill: (103) - Processo não encontrado
config/unicorn_launcher: linha 15: kill: (103) - Processo não encontrado
(96) saindo
ok: run: redis: (pid 51) 14s
ok: run: postgres: (pid 127) 0s
supervisor pid: 120 unicorn pid: 129
config/unicorn_launcher: linha 71: kill: (129) - Processo não encontrado
config/unicorn_launcher: linha 15: kill: (129) - Processo não encontrado
(120) saindo
ok: run: redis: (pid 51) 22s
timeout: down: postgres: 0s, normalmente ativo, quer ativo
ok: run: redis: (pid 51) 30s
timeout: down: postgres: 1s, normalmente ativo, quer ativo
ok: run: redis: (pid 51) 37s
ok: run: postgres: (pid 174) 0s
supervisor pid: 165 unicorn pid: 176
config/unicorn_launcher: linha 71: kill: (176) - Processo não encontrado
config/unicorn_launcher: linha 15: kill: (176) - Processo não encontrado
(165) saindo
ok: run: redis: (pid 51) 48s
ok: run: postgres: (pid 196) 1s
supervisor pid: 191 unicorn pid: 198
config/unicorn_launcher: linha 71: kill: (198) - Processo não encontrado
config/unicorn_launcher: linha 15: kill: (198) - Processo não encontrado
(191) saindo
ok: run: redis: (pid 51) 54s
timeout: down: postgres: 1s, normalmente ativo, quer ativo

Você está usando PostgreSQL, Redis e Object Storage externos? Isso é esperado ao fazer HA, e tanto seus servidores de produção quanto os servidores de build precisam ter acesso a esses serviços externos.

Apenas testando o cenário, bootstrap executando em um servidor e executando a imagem de contêiner inicializada em outro servidor com configuração independente.

Essa é uma maneira que certamente não funcionará.

Alguma razão para mencionar o armazenamento de objetos, não podemos usar o armazenamento interno do servidor?

Na configuração de HA, precisamos copiar o diretório discourse inicializado em todos os servidores de aplicativos?

Como você vai lidar com vários servidores de aplicativos e uploads de usuários? Uma unidade de rede compartilhada entre todos os servidores? Isso pode funcionar, mas nossa solução oficial para isso é o Armazenamento de Objetos usando a API S3.

Não há necessidade disso, desde que você

Sim, estou usando um servidor Postgres e um cluster Redis externos

3 servidores de aplicativos usando para cluster Redis junto com o aplicativo.

Então, preciso usar um diretório/armazenamento compartilhado para o diretório de build do discourse. Obrigado @Falco, agora está claro para mim.

Desculpe incomodar você @Falco, tenho uma última dúvida.

Ao realizar a etapa de reconstrução, isso afetará os dados existentes no banco de dados Postgres? Se sim, como lidar com isso?

Sim, existem migrações que serão executadas durante uma reconstrução, que alterarão tanto os dados quanto a estrutura.

Em um ambiente de HA, você precisará seguir as orientações que temos aqui: Introducing Post Deployment Migration

1 curtida

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.