Discourse doppelter nginx-Fehler: Modul `handlebars` nicht gefunden, importiert aus `discourse-common/lib/raw-handlebars`

Installation
,
1

Hallo!
Meine Website verwendet Version 2.9 von Discourse. Aus irgendeinem Grund musste ich doppelte Nginx für Discourse verwenden. Ich habe zwei Discourse web_only Container-Knoten bereitgestellt und einen Nginx davor geschaltet, um Anfragen weiterzuleiten. Mein Systemarchitekturdiagramm:

image
image718×978 12.1 KB

Ich war verwirrt, als mein benutzerdefinierter Nginx zwei web_only Container-Knoten weiterleitete und Anfragen zufällig an jeden web_only Knoten verteilte. Meine Discourse-Website meldete manchmal Fehler: “Could not find module ‘handlebars’ imported from ‘discurse-common /lib/raw-handlebars’”, diesmal wurde die Website im Browser mit einem leeren Bildschirm angezeigt. Aber als ich einen benutzerdefinierten Nginx verwendete, um alle Anfragen an nur einen der web_only Knoten weiterzuleiten, trat dieser Fehler nicht auf. Ich habe nach diesem Problem gesucht, es gab einige Commits zuvor, um diesen gleichen Fehler zu beheben. Ich habe bestätigt, dass meine Version diesen Commit-Code enthält.

Could not find module 'handlebars' imported from 'discourse-common/lib/raw-handlebars'

Broken instance after updating to 2.9.0.beta2 - #11 by david

Weiß jemand, warum das so ist? Vielen Dank

image
image1728×1566 176 KB

2

Übrigens, teilen Sie ein Problem, bei dem die Verwendung von doppeltem Nginx dazu führt, dass die echte Benutzer-IP-Adresse nicht abgerufen werden kann.
Dies liegt daran, dass mein benutzerdefiniertes Nginx das X-Forwarded-For-Headerfeld aktiviert, um die Client-IP-Adresse abzurufen, aber X-Forwarded-For des Nginx von Discourse nicht deaktiviert. Dies führt dazu, dass die X-Forwarded-For-Konfiguration des benutzerdefinierten Nginx durch das Nginx von Discourse überschrieben wird.

3

Und es spielt keine Rolle, welchen Sie verwenden? Und sie führen dasselbe Image aus? Das ist verwirrend.

Der einzige Vorteil, den ich darin sehe, zwei Container auf demselben Host so auszuführen, ist, null-Ausfall-Upgrades zu ermöglichen. Da Sie nicht sehr oft ein Upgrade durchführen, scheint dies unnötige Komplexität zu sein.

Sie benötigen etwas wie das in Ihrer web_only.yml:

after_bundle_exec:
  - replace:
    filename: /etc/nginx/conf.d/discourse.conf
    from: "types {"
    to: |
      set_real_ip_from 172.16.0.0/12;
      set_real_ip_from 10.0.0.0/8;
      real_ip_recursive on;
      real_ip_header X-Forwarded-For;
      types {
4

Vielen Dank für Ihre Antwort.

Ja, es spielt keine Rolle, welches ich verwende. Sie führen dasselbe web_only-Image aus. Ich werde weiterhin nach Problemen im abgesicherten Modus suchen und wenn es Schlussfolgerungen gibt, werde ich hier berichten.

Entschuldigen Sie das Missverständnis in meinem Systemarchitekturdiagramm, ich habe eine andere Maschine verwendet, um web_only bereitzustellen. Der Grund, warum ich doppelte web_only verwende, ist, dass mein web_only-Container einmal aufgrund zu vieler Verbindungen abgestürzt ist, ich aber zu diesem Zeitpunkt den Grund nicht herausgefunden habe. Also habe ich versucht, doppelte web_only zu verwenden, um dasselbe Problem erneut zu vermeiden.

Danke, das hat mir geholfen, das Problem mit der Ermittlung der echten Benutzer-IP zu lösen.

1 „Gefällt mir“
6

Das ergibt Sinn.

Es gibt eine Einstellung, um die Anzahl der Verbindungen zu erhöhen.

Ich würde ein Upgrade durchführen. Es sollte ein Problem mit dieser Version geben und ich bin ziemlich sicher, dass seitdem mehrere Sicherheitsprobleme behoben wurden.

1 „Gefällt mir“
7

Danke. Derzeit erhalte ich beim Debuggen im abgesicherten Modus immer noch denselben Fehler. Ich werde bereit sein, mein Discourse-System zu aktualisieren, um zu sehen, ob es funktioniert.

1 „Gefällt mir“
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.