503s transitórios quando precedidos por HAProxy

Instalação Hospedagem
1

Eu criei um fórum de teste com dois contêineres web_only, o contêiner mail-receiver, Postgres e Redis em uma rede Docker. Os dois contêineres web nginx foram precedidos pelo HAProxy. Eles funcionaram bem, mas descobri que, ao reconstruir um dos dois contêineres web, sempre havia uma pequena quantidade de tempo de inatividade onde 503 era retornado.

Felizmente, encontrei uma solução alternativa mitigadora, mas nada perfeita;

antes de reconstruir app1, execute

echo \"disable server be_discourse/app1\" | socat stdio /run/haproxy/admin.sock

e então, após o término do processo de reconstrução de app1, execute

echo \"enable server be_discourse/app1\" | socat stdio /run/haproxy/admin.sock

Inversamente, para reconstruir app2 execute

echo \"disable server be_discourse/app2\" | socat stdio /run/haproxy/admin.sock

e então, após o término do processo de reconstrução de app2, execute

echo \"enable server be_discourse/app1\" | socat stdio /run/haproxy/admin.sock

isso é baseado em /etc/haproxy/haproxy.cfg corresponder em relação a be_discourse, eu não vou colar o arquivo de configuração em um bloco de código ainda, mas se uma massa crítica quiser, eu posso.

então isso mitiga o 503 dizendo ao HAProxy para desviar o tráfego antes que ele saiba que haveria um 503 do contêiner que está inativo.

você pode alternativamente criar uma página de erro, mas eu não tive muita sorte com isso e sinto que precisa de mais pesquisa. No entanto, isso realmente não resolve o problema do tempo de inatividade.

2

Por que você não redespacha para o próximo servidor em um 503?

1 curtida
3

Legal! Isso seria bom. Você também tem alguma sugestão sobre o Sidekiq? Não vejo o Sidekiq em lugar nenhum em discourse_docker/samples at main · discourse/discourse_docker · GitHub, o que me levou a fazer as seguintes alterações em qualquer um dos arquivos YML

app1.yml

## Lembre-se, esta é a sintaxe YAML - você só pode ter um bloco com um nome
run:
  - exec: echo "Beginning of custom commands"
+  - exec: rm -f /etc/service/sidekiq/down
  ## Se você quiser configurar o login com senha para root, descomente e altere:

app2.yml

## Lembre-se, esta é a sintaxe YAML - você só pode ter um bloco com um nome
run:
  - exec: echo "Beginning of custom commands"
+  - exec: bash -lc 'mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down'
  ## Se você quiser configurar o login com senha para root, descomente e altere:
4

Para quem executa vários contêineres web, uma consideração adicional é onde o Sidekiq é executado.

Os erros 503 afetam apenas as requisições web, mas se o Sidekiq estiver inativo, seu site simplesmente parará de processar trabalhos em segundo plano (e-mails, resumos, distintivos, webhooks). Uma maneira elegante de lidar com isso é dar ao Sidekiq seu próprio contêiner e mantê-lo desabilitado nos nós web.

O Discourse usa o runit internamente: cada serviço em /etc/service/* inicia, a menos que haja um arquivo chamado down dentro de seu diretório. Esse é todo o controle necessário.

Aqui está um exemplo de um worker Sidekiq dedicado:

worker.yml — Apenas Sidekiq 
templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/sshd.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"

expose: []   # nenhuma porta HTTP

env:
  DISCOURSE_DB_HOST: data
  DISCOURSE_REDIS_HOST: data
  DISCOURSE_HOSTNAME: "forum.example.com"
  # corresponda aos seus segredos existentes / configurações SMTP

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          # desabilitar serviços web
          - mkdir -p /etc/service/puma  && touch /etc/service/puma/down
          - mkdir -p /etc/service/nginx && touch /etc/service/nginx/down
          # habilitar Sidekiq
          - rm -f /etc/service/sidekiq/down

run:
  - exec: echo "Iniciando contêiner worker Sidekiq"

Nos contêineres web (app1/app2), o oposto deve ser feito - mantenha o Puma e o Nginx habilitados, mas adicione:

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          - mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down

Com essa configuração, o HAProxy balanceia apenas os contêineres web, enquanto o Sidekiq continua em execução no worker. Dessa forma, os trabalhos em segundo plano não são interrompidos quando você reconstrói ou rotaciona seus nós web.

5

Movi isto para Installation > Hosting, pois parece ser uma conversa em aberto. Vamos evitar criá-las em Support.

1 curtida