Kann jemand bitte seine funktionierende Konfiguration für die Rate-Limiting in Nginx außerhalb eines Docker-Containers teilen (Setup mit Discourse über den Socket)? Danke..
Ich scheine nicht in der Lage zu sein, es richtig anzupassen, und limitiere trotzdem gültigen Verkehr.
Meinst du, dass Datenverkehr eingeschränkt wird, obwohl er es nicht sollte, oder dass du keinen Datenverkehr einschränkst, obwohl du es solltest?
Genau. Als Erstes habe ich eine Vorlage aus dem Container nach draußen verlagert. Ich weiß nicht, ob es eine empfohlene Konfiguration für die Ratenbegrenzung des externen Nginx gibt.
Emojis und Avatare scheinen andere Grenzwerte zu benötigen als der übrige Datenverkehr.
Bump.. Will wirklich niemand seine Tipps für die Arbeit mit Ratenbegrenzungen im externen Nginx teilen? Vielen Dank im Voraus!
Bitte heben Sie Themen nicht hoch. Wenn jemand eine Antwort für Sie hätte, wäre er sicher darauf eingegangen.
Unter der Annahme, dass Sie die anderen Anleitungen hier im Meta-Bereich befolgt haben und nginx korrekt konfiguriert ist, um Client-IPs an den Container weiterzuleiten, handelt es sich hier wirklich um ein Discourse-Problem?
a) AFAIK wird empfohlen, nginx außerhalb des Containers zu betreiben
b) Es sollte maßgeschneidert auf die Anforderungen von Discourse sein
Also, ja, ich sehe dies als ein Discourse-bezogenes Problem.
Stimmt das wirklich und ist es eine empfohlene Praxis?
Die Rate-Limit-Vorlage templates/web.ratelimited.template.yml sollte aus der Docker-Konfiguration entfernt werden, und das Rate Limit sollte stattdessen in der äußeren nginx-Instanz konfiguriert werden.
Nein, Discourse benötigt außerhalb des Containers keinen Nginx.
Nginx ist bereits innerhalb des Containers vorhanden und wird automatisch konfiguriert. Es ist eine Null-Touch-Lösung, sofern Sie die Standardinstallation befolgt haben.
Wenn Sie auf dem Host keine anderen Dienste ausführen, benötigen Sie überhaupt keine externe Nginx-Instanz.
Entschuldigung, aber ich denke nicht, dass eine 20+ Minuten dauernde Neukompilierung der App ohne eine Offline-Seite gute Praxis ist (für eine Website mit hohem Verkehrsaufkommen).
Manuelle Neubuilds, die eine Downtime erfordern, finden ein- bis zweimal pro Jahr statt. Wenn Sie über /admin/upgrade aktualisieren, verlaufen die Updates nahtlos.
Sie können Ihre Neubuild-Zeiten mit einer Zwei-Container-Installation erheblich verkürzen. Ich empfehle Ihnen, dies unabhängig davon, ob Sie nginx verwenden, zu prüfen.
Die Zwei-Container-Installation klingt gut. Aber ich kann hier im Forum keine Dokumentation dazu finden 
Nein, das ist nicht der Fall. Es ist möglich, aber keine Standardempfehlung.
Hier ist die Anleitung.
Wenn Ihr Hauptanliegen Ausfallzeiten während der Neuaufbauten sind, ist das Ihre beste Option. Falls Sie Hilfe beim Einrichten benötigen, kann Ihnen jemand im #marketplace-Kanal unterstützen.