# 503s transitórios quando precedidos por HAProxy

**URL:** <https://meta.discourse.org/t/transient-503s-after-launcher-rebuild-appn-when-they-re-fronted-by-haproxy/383179>\
**Category:** Self-hosting\
**Tags:** advanced-setup, hosting\
**Created:** [18 Setembro , 2025 19:34 UTC](https://meta.discourse.org/t/transient-503s-after-launcher-rebuild-appn-when-they-re-fronted-by-haproxy/383179 "2025-09-18T19:34:16Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\
**Post date:** [18 Setembro , 2025 20:32 UTC](https://meta.discourse.org/t/transient-503s-after-launcher-rebuild-appn-when-they-re-fronted-by-haproxy/383179/4 "2025-09-18T20:32:41Z")

</div>

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**
>
> ```yml
> 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:

```yml
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.

---

_[View the full topic](https://meta.discourse.org/t/transient-503s-after-launcher-rebuild-appn-when-they-re-fronted-by-haproxy/383179)._