eine zusätzliche Anmerkung, die direkt mit dem oben genannten HAProxy-Teil des Setups zusammenhängt.
Es gibt ein häufiges Verhalten bei HAProxy + Discourse, bei dem das Neuerstellen eines Web-Containers (z. B. mit ./launcher rebuild app1) kurzzeitig 503 Service Unavailable-Antworten zurückgibt, da HAProxy weiterhin Traffic an dieses Backend sendet, während es neu startet. Dies ist kein Fehler in Discourse selbst – es geschieht, weil das Backend während des Neuerstellungsvorgangs vorübergehend nicht verfügbar ist.
Die empfohlene Umgehung besteht darin, den HAProxy-Admin-Socket zu verwenden, um:
\t1.\tden Server in HAProxy vor dem Neuerstellen zu deaktivieren und
\t2.\tden Server nach Abschluss des Neuerstellens wieder zu aktivieren
Dies verhindert diese vorübergehenden 503er-Fehler.
Es gibt eine bestehende Meta-Diskussion, die dieses Verhalten und die Erklärung der Umgehung dokumentiert:
Wenn jemand hier HAProxy für Rolling Rebuilds verwendet, bietet dieser Thread nützlichen Kontext dafür, warum die Admin-Socket-Befehle in das Runbook aufgenommen wurden.