503 transitori quando preceduti da HAProxy

Installazione Ospitare
1

Ho creato un forum di test con due container web_only, il container mail-receiver, Postgres e Redis su una rete Docker. I due container web nginx erano preceduti da HAProxy. Hanno funzionato bene, ma ho scoperto che ricostruendo uno dei due container web c’era sempre una piccola quantità di tempo di inattività in cui veniva restituito 503.

Fortunatamente, ho trovato una soluzione mitigante, ma niente di perfetto;

prima di ricostruire app1, esegui

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

e poi, dopo che il processo di ricostruzione di app1 è terminato, esegui

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

Viceversa, per ricostruire app2 esegui

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

e poi, dopo che il processo di ricostruzione di app2 è terminato, esegui

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

questo si basa sul fatto che /etc/haproxy/haproxy.cfg corrisponde per quanto riguarda be_discourse, non incollerò il file di configurazione in un blocco di codice per ora, ma se una massa critica lo desidera potrei farlo

quindi questo mitiga il 503 dicendo ad HAProxy di deviare il traffico prima che sappia che ci sarebbe stato un 503 dal container che è giù.

puoi creare alternativamente una pagina di errore, ma non ho avuto molta fortuna con quella e ritengo che necessiti di ulteriori ricerche. Tuttavia, questo non risolve realmente il problema del tempo di inattività.

2

Perché non ridistribuire al server successivo in caso di 503?

1 Mi Piace
3

Ottimo! Sarebbe un bene. Hai anche qualche suggerimento su Sidekiq? Non vedo Sidekiq affatto in discourse_docker/samples at main · discourse/discourse_docker · GitHub, il che mi ha portato a apportare le seguenti modifiche a yml

app1.yml

## Ricorda, questa è sintassi YAML - puoi avere solo un blocco con un nome
run:
  - exec: echo "Inizio dei comandi personalizzati"
+  - exec: rm -f /etc/service/sidekiq/down
  ## Se vuoi configurare l'accesso tramite password per root, decommenta e cambia:

app2.yml

## Ricorda, questa è sintassi YAML - puoi avere solo un blocco con un nome
run:
  - exec: echo "Inizio dei comandi personalizzati"
+  - exec: bash -lc 'mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down'
  ## Se vuoi configurare l'accesso tramite password per root, decommenta e cambia:
4

Per chiunque gestisca più container web, un aspetto aggiuntivo da considerare è dove viene eseguito Sidekiq.

I 503 interessano solo le richieste web, ma se Sidekiq è inattivo, il tuo sito smetterà silenziosamente di gestire i processi in background (email, digest, badge, webhook). Un modo intelligente per gestire questo è dedicare a Sidekiq il proprio container e mantenerlo disabilitato sui nodi web.

Discourse utilizza runit internamente: ogni servizio in /etc/service/* si avvia a meno che non ci sia un file chiamato down all’interno della sua directory. Questo è tutto il controllo necessario.

Ecco un esempio di un worker Sidekiq dedicato:

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

expose: []   # nessuna porta HTTP

env:
  DISCOURSE_DB_HOST: data
  DISCOURSE_REDIS_HOST: data
  DISCOURSE_HOSTNAME: "forum.example.com"
  # corrispondi ai tuoi segreti esistenti / impostazioni SMTP

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          # disabilita i servizi web
          - mkdir -p /etc/service/puma  && touch /etc/service/puma/down
          - mkdir -p /etc/service/nginx && touch /etc/service/nginx/down
          # abilita Sidekiq
          - rm -f /etc/service/sidekiq/down

run:
  - exec: echo "Avvio del container worker Sidekiq"

Sui container web (app1/app2), dovrebbe essere fatto il contrario: mantenere Puma e Nginx abilitati, ma aggiungere:

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

Con questa configurazione, HAProxy bilancia solo i container web, mentre Sidekiq continua a funzionare nel worker. In questo modo, i processi in background non vengono interrotti quando ricostruisci o ruoti i tuoi nodi web.

5

Ho spostato questo in Installation > Hosting poiché sembra essere una conversazione aperta. Evitiamo di crearne altre in Support.

1 Mi Piace