Tijdelijke 503-fouten bij front-end door HAProxy

Installatie Hosting
1

Ik had een testforum gemaakt met twee web_only containers, de mail-receiver container, Postgres en Redis op een Docker-netwerk. De twee webcontainers nginx werden voorgezeten door HAProxy. Ze werkten goed, maar ik merkte bij het herbouwen van een van de twee webcontainers dat er altijd een kleine hoeveelheid downtime was waarbij 503 werd geretourneerd.

Gelukkig vond ik een mitigerende oplossing, maar niets perfects;

voordat je app1 herbouwt, voer je uit:

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

en daarna, nadat het herbouwproces van app1 is voltooid, voer je uit:

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

Vise versa, om app2 te herbouwen, voer je uit:

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

en daarna, nadat het herbouwproces van app2 is voltooid, voer je uit:

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

dit is gebaseerd op /etc/haproxy/haproxy.cfg die overeenkomt met betrekking tot be_discourse, ik zal het configuratiebestand nog niet in een codeblok plakken, maar als een kritieke massa het wil, misschien wel.

dus dit mitigeert de 503 door HAProxy te vertellen verkeer om te leiden voordat het een 503 van de container die down is zou weten.

je kunt ook een foutpagina maken, maar daar had ik niet veel succes mee, en ik vind dat het verder onderzoek nodig heeft. Dit lost het probleem van downtime echter niet echt op.

2

Why don’t you redispatch to the next server on a 503 ?

1 like
3

nice! that would be good. Also, do you have any suggestions about sidekiq? I don’t see sidekiq at all in discourse_docker/samples at main · discourse/discourse_docker · GitHub which lead to me making the following changes to either yml

app1.yml

## Remember, this is YAML syntax - you can only have one block with a name
run:
  - exec: echo "Beginning of custom commands"
+  - exec: rm -f /etc/service/sidekiq/down
  ## If you want to configure password login for root, uncomment and change:

app2.yml

## Remember, this is YAML syntax - you can only have one block with a name
run:
  - exec: echo "Beginning of custom commands"
+  - exec: bash -lc 'mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down'
  ## If you want to configure password login for root, uncomment and change:
4

Voor iedereen die meerdere webcontainers draait, is er nog een extra punt om over na te denken: waar Sidekiq draait.

503s hebben alleen invloed op webverzoeken, maar als Sidekiq uitvalt, stopt je site stilzwijgend met het verwerken van achtergrondtaken (e-mails, samenvattingen, badges, webhooks). Een nette manier om dit af te handelen is door Sidekiq zijn eigen container te geven en het uitgeschakeld te houden op de webknooppunten.

Discourse gebruikt runit onder de motorkap: elke service in /etc/service/* start, tenzij er een bestand met de naam down in de directory staat. Dat is alle controle die nodig is.

Hier is een voorbeeld van een speciale Sidekiq worker:

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

expose: []   # geen HTTP-poorten

env:
  DISCOURSE_DB_HOST: data
  DISCOURSE_REDIS_HOST: data
  DISCOURSE_HOSTNAME: "forum.example.com"
  # pas je bestaande geheimen / SMTP-instellingen aan

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          # webservices uitschakelen
          - mkdir -p /etc/service/puma  && touch /etc/service/puma/down
          - mkdir -p /etc/service/nginx && touch /etc/service/nginx/down
          # Sidekiq inschakelen
          - rm -f /etc/service/sidekiq/down

run:
  - exec: echo "Sidekiq worker container starten"

Op de webcontainers (app1/app2) moet het tegenovergestelde worden gedaan - houd Puma en Nginx ingeschakeld, maar voeg toe:

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

Met deze opstelling balanceert HAProxy alleen de webcontainers, terwijl Sidekiq blijft draaien in de worker. Op die manier worden achtergrondtaken niet onderbroken wanneer je je webknooppunten opnieuw opbouwt of roteert.

5

Ik heb dit verplaatst naar Installation > Hosting, aangezien dit een open gesprek lijkt te zijn. Laten we voorkomen dat deze in Support worden aangemaakt.

1 like