Vorübergehende 503er bei HAProxy-Proxy

Installation Hosting
1

Ich hatte ein Testforum mit zwei web_only-Containern, dem mail-receiver-Container, Postgres und Redis in einem Docker-Netzwerk erstellt. Die beiden Nginx-Webcontainer wurden von HAProxy bedient. Sie funktionierten gut, aber ich stellte fest, dass beim Neuerstellen eines der beiden Webcontainer immer eine kurze Ausfallzeit auftrat, bei der 503 zurückgegeben wurde.

Glücklicherweise fand ich einen mildernden Workaround, aber nichts Perfektes;

Bevor app1 neu erstellt wird, führen Sie aus:

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

und führen Sie dann nach Abschluss des Neuerstellungsprozesses von app1 aus:

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

Umgekehrt, um app2 neu zu erstellen, führen Sie aus:

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

und führen Sie dann nach Abschluss des Neuerstellungsprozesses von app2 aus:

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

Dies basiert darauf, dass /etc/haproxy/haproxy.cfg in Bezug auf be_discourse übereinstimmt. Ich werde die Konfigurationsdatei noch nicht in einem Codeblock einfügen, aber wenn eine kritische Masse sie wünscht, werde ich es vielleicht tun.

Dies mildert die 503, indem HAProxy angewiesen wird, den Datenverkehr umzuleiten, bevor es von dem ausgefallenen Container eine 503-Meldung erhält.

Sie können alternativ eine Fehlerseite erstellen, aber damit hatte ich nicht viel Glück und glaube, dass sie weiterer Forschung bedarf. Dies behebt jedoch nicht wirklich das Problem der Ausfallzeit.

2

Warum werden Sie bei einem 503-Fehler nicht an den nächsten Server weitergeleitet?

1 „Gefällt mir“
3

Schön! Das wäre gut. Haben Sie auch Vorschläge zu Sidekiq? Ich sehe Sidekiq überhaupt nicht unter discourse_docker/samples at main · discourse/discourse_docker · GitHub, was mich dazu veranlasst, die folgenden Änderungen an entweder yml vorzunehmen

app1.yml

## Denken Sie daran, dies ist YAML-Syntax - Sie können nur einen Block mit einem Namen haben
run:
  - exec: echo "Beginning of custom commands"
+  - exec: rm -f /etc/service/sidekiq/down
  ## Wenn Sie die Passwortanmeldung für root konfigurieren möchten, kommentieren Sie sie aus und ändern Sie sie:

app2.yml

## Denken Sie daran, dies ist YAML-Syntax - Sie können nur einen Block mit einem Namen haben
run:
  - exec: echo "Beginning of custom commands"
+  - exec: bash -lc 'mkdir -p /etc/service/sidekiq && touch /etc/service/sidekiq/down'
  ## Wenn Sie die Passwortanmeldung für root konfigurieren möchten, kommentieren Sie sie aus und ändern Sie sie:
4

Für alle, die mehrere Web-Container betreiben, ist wo Sidekiq läuft ein zusätzlicher Punkt, über den man nachdenken sollte.

503er beeinträchtigen nur Web-Anfragen, aber wenn Sidekiq ausfällt, hört Ihre Website stillschweigend auf, Hintergrundaufträge (E-Mails, Digests, Abzeichen, Webhooks) zu bearbeiten. Eine clevere Möglichkeit, dies zu handhaben, ist, Sidekiq einen eigenen Container zu geben und es auf den Web-Knoten deaktiviert zu lassen.

Discourse verwendet intern runit: Jeder Dienst in /etc/service/* startet, es sei denn, in seinem Verzeichnis befindet sich eine Datei namens down. Das ist alles, was an Steuerung benötigt wird.

Hier ist ein Beispiel für einen dedizierten Sidekiq-Worker:

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

expose: []   # keine HTTP-Ports

env:
  DISCOURSE_DB_HOST: data
  DISCOURSE_REDIS_HOST: data
  DISCOURSE_HOSTNAME: "forum.example.com"
  # stimmen Sie Ihre vorhandenen Geheimnisse / SMTP-Einstellungen ab

hooks:
  after_code:
    - exec:
        cd: $home
        cmd:
          # Web-Dienste deaktivieren
          - mkdir -p /etc/service/puma  && touch /etc/service/puma/down
          - mkdir -p /etc/service/nginx && touch /etc/service/nginx/down
          # Sidekiq aktivieren
          - rm -f /etc/service/sidekiq/down

run:
  - exec: echo "Starte Sidekiq-Worker-Container"

Auf den Web-Containern (app1/app2) sollte das Gegenteil getan werden – Puma und Nginx aktiviert lassen, aber hinzufügen:

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

Mit dieser Einrichtung balanciert HAProxy nur die Web-Container, während Sidekiq im Worker weiterläuft. Auf diese Weise werden Hintergrundaufträge nicht unterbrochen, wenn Sie Ihre Web-Knoten neu erstellen oder rotieren.

5

Ich habe dies nach Installation > Hosting verschoben, da es sich um eine offene Konversation zu handeln scheint. Lassen Sie uns diese nicht in Support erstellen.

1 „Gefällt mir“