Neuinstallation liefert 502 Bad Gateway

[NullUsername (NulledName)]

Hallo zusammen,

Ich habe Discourse zweimal eingerichtet, einmal in einem Container und das aktuelle in einer VM. Bei beiden Installationen ist Discourse nicht erreichbar. Ich bin mir nicht sicher, was falsch sein könnte.

Discourse VM:

• Kerne 4
• RAM 6 GB
• Speicher 50 GB
• Betriebssystem: Ubuntu 22.04.3

Befehle für eine saubere Post-OS-Installation:

apt update -y && apt upgrade -y && apt wget curl zip git docker.io -y && reboot

Dann habe ich die folgende Anleitung befolgt: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Nach Abschluss sehe ich, dass der Container läuft, aber er gibt 502 Bad Gateway zurück.

So habe ich es eingerichtet: Nginx Reverse Proxy (inklusive SSL) → VM. Das funktioniert nicht.
Es wird nicht einmal geladen, wenn ich es direkt in meine Hosts-Datei eintrage.

Aus den letzten Zeilen der Installation sehe ich, dass Docker ein neues Netzwerk erstellt hat:

DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443

Wie kann ich es dazu bringen, die IP des HOST-Rechners zu verwenden?
Ich brauche kein weiteres Netzwerk in einem Netzwerk. Ich bin damit zufrieden, dass Docker die HOST-IP verwendet, da dies der einzige Dienst auf dieser VM ist.

Jede Hilfe wäre sehr willkommen!

Gibt es eine offizielle Methode zur Installation ohne Docker?

[pfaffman (Jay Pfaffman)]

Hat der Container eine Maschine mit einer öffentlichen IP-Adresse? Hat diese öffentliche IP-Adresse einen zugewiesenen Domänennamen?

Haben Sie discourse-setup ausgeführt? Sind Sie über den Teil hinausgekommen, in dem geprüft wird, ob Ihre DNS-Einstellungen gültig sind und der Host verfügbar ist?

Haben Sie eine Reihe von Rebuilds ausgeführt, sodass Sie von Let’s Encrypt einer Ratenbegrenzung unterliegen und kein Zertifikat zugewiesen bekommen können?

[NullUsername (NulledName)]

@pfaffman

Befindet sich der Container auf einem Rechner mit einer öffentlichen IP? Hat diese öffentliche IP einen Domainnamen zugewiesen?

Nein, dieser Rechner hat eine lokale IP zugewiesen und der Datenverkehr wird über meine Firewall an die lokale IP weitergeleitet. Das ist nicht das Problem.
Die öffentliche IP hat einen A-Eintrag für den Server und wird korrekt weitergeleitet. forum.somedomain.com zeigt –> auf den richtigen Server.

@pfaffman

Haben Sie discourse-setup ausgeführt? Sind Sie an dem Punkt vorbeigekommen, an dem geprüft wird, ob Ihr DNS gültig und der Host verfügbar ist?

Ja, ich habe die Installation abgeschlossen. Habe sie 100% (3 Mal) bis zu dem Punkt abgeschlossen, an dem der Container läuft.
Sie besteht alle Domain-/DNS-Prüfungen. Sie wird als gültig angezeigt.

@pfaffman

Haben Sie eine Reihe von Rebuilds durchgeführt, sodass Sie von Let’s Encrypt rate-limited wurden und kein Zertifikat zugewiesen bekommen können?

Nein, dies kann nicht rate-limited werden, da das SSL-Zertifikat über meinen Reverse-Proxy ausgestellt wird. Ich habe das Zertifikat.

Diese Installation ist zu 100% abgeschlossen. Das Problem ist, dass Docker ein neues Netzwerk 172.17.0.1 erstellt, das nicht benötigt wird, da ich die lokale IP des HOST 192.xx.xx.xx verwenden möchte.

Der Container läuft, aber in einem anderen Netzwerk. Ich kann ihn nicht auf die HOST-IP bekommen.

@NullUsername

Aus den letzten Zeilen der Installation kann ich sehen, dass Docker ein neues Netzwerk erstellt hat:

DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443

Der Docker-Host sollte die IP des Host-Servers (192.xxx.xxx.xxx) sein und nicht ein neues Netzwerk. Es funktioniert wahrscheinlich, aber in diesem Netzwerk.
Wie sage ich der Installation, dass sie meine lokale IP und nicht 172.17.0.1 verwenden soll?

[NullUsername (NulledName)]

@pfaffman So etwas. Aus einem Kommentar von Ihnen

@pfaffman

Vielleicht versuchen Sie es so:

 ./launcher start app --docker-args '--network discourse_back --ip 192.168.1.4'

Wie stelle ich ./discourse-setup so ein, dass es während der Installation die Host-IP 192.168.1.X und das Netzwerk verwendet?

[pfaffman (Jay Pfaffman)]

Sie können discourse-setup nicht mit einem Reverse-Proxy verwenden. Sie müssen die yml-Datei selbst bearbeiten. Es gibt einige Themen zum Ausführen von Discourse mit anderen Websites auf derselben Maschine.

Sie müssen die SSL- und Let’s Encrypt-Vorlagen entfernen, wenn Sie einen Reverse-Proxy verwenden, der die SSL-Funktionen übernimmt.

[NullUsername (NulledName)]

@pfaffman

Es gibt einige Themen darüber, wie man Discourse mit anderen Websites auf derselben Maschine betreibt.

Das ist es ja, ich betreibe keine anderen Dienste auf dieser Maschine. Es ist eine eigenständige VM.

Ich glaube, es gibt ein Missverständnis.

Das ./docker-setup wird erfolgreich installiert. Es erstellt ein eigenes Netzwerk für die App 172.17.0.1.

Wie bekomme ich die Installation oder den Docker-Container dazu, die Host-IP 192.168.1.X zu verwenden, also ein Bridge-Netzwerk zu nutzen und kein eigenes Netzwerk zu erstellen?

[pfaffman (Jay Pfaffman)]

@NullUsername

Das ist es ja, ich betreibe keine anderen Dienste auf dieser Maschine. Es ist eine eigenständige VM.

Aber du hast das gesagt:

@NullUsername

Nein, das kann nicht ratenlimitiert werden, da das SSL-Zertifikat über meinen Reverse-Proxy ausgestellt wird. Ich habe das Zertifikat

Wenn du einen Reverse-Proxy verwendest, kannst du discourse-setup nicht verwenden.

[NullUsername (NulledName)]

@pfaffman

Aber Sie sagten das:

@NullUsername

Nein, dies kann nicht ratenlimitiert werden, da das SSL-Zertifikat über meinen Reverse-Proxy ausgestellt wird. Ich habe das Zertifikat

Wenn Sie einen Reverse-Proxy verwenden, können Sie discourse-setup nicht verwenden.

Ja, der Reverse-Proxy ist auf einem anderen Server, aber ich verstehe, was Sie sagen.

Ich habe eine Idee. Ich werde einfach den gesamten Datenverkehr von meinem Netzwerk zum Netzwerk der Docker-Container leiten.

Gibt es eine Installationsanleitung für den Betrieb von Discourse hinter einem Nginx-Reverse-Proxy?

Oder eine Möglichkeit, Discourse selbst zu bauen?

[Jagster (Jakke Lehtonen)]

Das ist ziemlich trivial. Sie erlauben den HTTP-Port in app.yml, wo Ngix den Traffic sendet. Und SSL ist deaktiviert. Diese beiden Dinge sind die einzigen, die Sie beheben müssen. Natürlich müssen Sie die echte IP-Adresse angeben, aber das muss man jedes Mal tun, wenn das Backend Discourse, Moodle, WordPress oder was auch immer ist. UFW versucht, den Zugriff nur zwischen Frontend und Backend einzuschränken, da kein direkter Zugriff auf das Backend erforderlich ist.

Wenn ich mich richtig erinnere, gibt es hier eine Dokumentation, wie man Apache2 einrichtet. Nginx macht dasselbe, aber natürlich auf seine eigene Weise.

Oder was übersehe ich jetzt?

[NullUsername (NulledName)]

Lassen Sie mich von vorne anfangen, damit Sie sehen können, dass es etwas Einfaches ist, das ich übersehe.

Ich habe Nginx Reverse Proxy. Läuft und verwaltet die öffentliche IP und leitet den Datenverkehr an Dienste weiter.

Bsp.: Client fordert cloud.domain.com an → Nginx Reverse Proxy (handhabt SSL) → Verweist auf cloud.domain.com

Jetzt habe ich eine VM für Discourse eingerichtet und Folgendes verwendet:
Ubuntu 23.04. Befehle nach der OS-Installation:

apt update -y \
apt upgrade -y \
apt install wget curl zip git docker.io -y

Dann habe ich dieser Anleitung von Discourse gefolgt: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

Die Installation wird erfolgreich abgeschlossen und dann beginnen die Probleme.

Ich kann aufgrund des docker0-Netzwerks nicht auf den Docker-Container vom Host aus zugreifen. Ich kann 172.17.0.2 anpingen und es läuft, aber von der Host-Maschine 192.168.1.10:80/443 wird kein Datenverkehr an den Container weitergeleitet.

Alles, was ich möchte, ist, dass der Docker-Container das Host-Netzwerk verwendet, da der Container die Ports 80 und 443 freigegeben hat.

Der erste Nginx Reverse Proxy leitet den Datenverkehr von außen ab und leitet ihn korrekt an die VM weiter. Wenn dies nicht der Fall wäre, hätte ./discourse-setup den Domainnamen nicht korrekt erkannt und es wäre nicht in der Lage, SSL-Zertifikate für den Container abzurufen.

Am Ende weiß ich, dass der Container zu 100 % funktioniert, ich kann nur aufgrund des Docker-Netzwerks nicht darauf zugreifen.

Wenn Sie Informationen benötigen, lassen Sie es mich bitte wissen.

[merefield (Robert)]

Ein anderer Ansatz ist die Verwendung des Discourse-Basis-Images
https://hub.docker.com/r/discourse/base
und die Erstellung Ihrer eigenen Orchestrierung mit z. B. Docker Compose (denken Sie daran, dass Sie andere Dienste wie Redis und PostgreSQL benötigen)

[Jagster (Jakke Lehtonen)]

Ich kann das mit Nginx oder Nginx+Varnish für Discourse auf demselben VPS oder VPS mit unterschiedlicher IP machen. Sie sagen nicht, was Sie tatsächlich mit Ihrem Nginx als Reverse-Proxy tun. Ihre Beispiele sind etwas schwierig, da es keine Möglichkeit gibt zu wissen, ob es sich um Beispiele handelt oder ob Sie tatsächlich versuchen, ein privates Netzwerk zu nutzen.

Aber:

@NullUsername

Host-Maschine 192.168.1.10:80/443 leitet keinen Datenverkehr an den Container weiter.

Natürlich nicht, denn das kümmert sich um den eingehenden Datenverkehr. Sie müssen einen anderen Port für das Backend verwenden.

So etwas wie das hier (das tatsächlich mit Varnish verwendet wird, aber das Prinzip ist dasselbe und sehr viel 101-Niveau-Zeug):

proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Real-IP  $remote_addr;
proxy_set_header X-Forwarded-For
 $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_pass_header Server;

[NullUsername (NulledName)]

@Jagster

Ihre Beispiele sind etwas schwierig, da man nicht weiß, ob es sich um Beispiele handelt oder ob Sie tatsächlich versuchen, ein privates Netzwerk zu nutzen.

Verständlich, danke für die Genauigkeit :).

@Jagster

Aber:

@NullUsername

Host-Maschine 192.168.1.10:80/443 leitet keinen Datenverkehr an den Container weiter.

Natürlich nicht, denn das verarbeitet eingehenden Datenverkehr. Sie müssen einen anderen Port für das Backend verwenden.

Ich bin mir nicht sicher, welcher, da dieses Docker-Netzwerk verwirrend ist.

@Jagster

So etwas (das tatsächlich mit Varnish verwendet wird, aber das Prinzip ist genau dasselbe und sehr viel 101-Zeug):

Absolut, deshalb bin ich frustriert von Docker, lol.

Unten ist genau, wie das WAN-Netzwerk den Datenverkehr von meinem Nginx-Reverse-Proxy an den richtigen Host weiterleitet und weiterleitet.

map $scheme $hsts_header {
    https   "max-age=63072000;includeSubDomains; preload";
}

server {
  set $forward_scheme https;
  set $server         "10.10.1.38";
  set $port           443;

  listen 80;
listen [::]:80;

  listen 443 ssl http2;
listen [::]:443 ssl http2;


  server_name forum.domainname.com;

  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /srv/ssl/domainname.pem;
  ssl_certificate_key /srv/ssl/domainname-ke.pem;


# Asset Caching
include conf.d/include/assets.conf;

# Block Exploits
include conf.d/include/block-exploits.conf;

# HSTS (ngx_http_headers_module ist erforderlich) (63072000 Sekunden = 2 Jahre)
add_header Strict-Transport-Security $hsts_header always;

# SSL erzwingen
include conf.d/include/force-ssl.conf;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;


access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;

proxy_set_header  X-Real-IP $remote_addr;
proxy_set_header  X-Forwarded-For $http_x_forwarded_for;
proxy_set_header  X-Forwarded-Proto $scheme;

location / {

  # HSTS (ngx_http_headers_module ist erforderlich) (63072000 Sekunden = 2 Jahre)
  add_header Strict-Transport-Security $hsts_header always;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    
    # Proxy!
    include conf.d/include/proxy.conf;
  }
}

Was seltsam ist, ich habe einmal einen Docker-Container für einen Kunden eingerichtet, der einen Nginx Reverse Proxy Manager wollte, und es war extrem einfach.

docker-compose up -d
Das war’s. Die private IP 192.168.1.3 konnte die exponierten 80/443 der Container erreichen und der ausgehende Datenverkehr wurde korrekt an 192.168.1.3 weitergeleitet.

[Jagster (Jakke Lehtonen)]

@NullUsername

Ich bin mir nicht sicher, woran das liegt, da dieses Docker-Netzwerk verwirrend ist.

Es ist verwirrend, weil es sich um ein Paketierungssystem handelt, das in seiner eigenen Sandbox spielt. Das ist es im Grunde.

Aber Docker zu verstehen ist etwas anderes, als es zu benutzen (und jetzt haben eine Menge Entwickler angefangen zu weinen ). Ihr Reverse-Proxy leitet den Datenverkehr über eine Firewall an eine IP-Adresse weiter, und Sie müssen diese IP-Adresse und den lauschenden Port angeben. Und Sie haben Discourse, alias Docker, auf dieser IP-Adresse, und der Port, den Sie in app.yml angeben. Das innere Nginx, das mit Discourse selbst arbeitet, kümmert sich um den Rest.

Discourse sollte nicht auf 443 lauschen, da Sie SSL bereits beendet haben.

Und Sie können im Grunde kein Caching auf dem Reverse-Proxy verwenden. Das Backend, Discourse, ist keine Webseite. Es ist eine Webanwendung, die Javascript und JSON sendet.

[NullUsername (NulledName)]

@Jagster

Es ist verwirrend, weil es ein Paketierungssystem ist, das in seiner eigenen Sandbox läuft. Im Grunde ist es das.

Das habe ich irgendwie herausgefunden.

[quote=“Jakke Lehtonen, post:16, topic:298564, username:Jagster”]
Aber Docker zu verstehen ist etwas anderes, als es zu benutzen (und jetzt haben eine Menge Entwickler angefangen zu weinen )
[/quote]Dem kann ich zustimmen. Ich würde nicht sagen weinen, es ist nur nutzlos für Sysadmins und Entwickler, die sich tatsächlich mit Linux auskennen. Ein LxC oder eine VM zu erstellen, die isoliert ist, und dann Docker eine weitere isolierte Umgebung erstellen zu lassen, ist redundant und sinnlos.

@Jagster

Ihr Reverse-Proxy leitet den Verkehr über die Firewall an die IP weiter und Sie müssen diese IP und den lauschenden Port angeben. Und Sie haben Discourse, alias Docker, auf dieser IP und dem Port, den Sie in app.yml angeben. Der innere Nginx, der mit Discourse selbst arbeitet, kümmert sich um den Rest.

Discourse sollte nicht auf 443 lauschen, da Sie SSL bereits beendet haben.

Das ist der Teil, der verwirrend ist. app.yml exponiert 80:80 und 443:443 auf 172.17.0.2, was sich im Docker-Netzwerk 172.17.0.1/16 befindet, wobei die IP der VM 10.10.1.38 ist.

Wie bekomme ich Discourse/Docker dazu, allen Verkehr, der auf 10.10.1.38 ankommt, an 172.17.0.2 weiterzuleiten, und allen ausgehenden Verkehr an 10.10.1.38 weiterzuleiten? Das ist alles, was benötigt wird, um dieses Problem zu lösen. Buchstäblich.

Mein Reverse-Proxy kümmert sich um das Routing vom WAN zu forum.domainname.com

@Jagster

Und Sie können im Grunde kein Caching auf dem Reverse-Proxy verwenden. Das Backend, Discourse, ist keine Webseite. Es ist eine Webanwendung, die Javascript und JSON sendet.

Caching wurde entfernt.

[Jagster (Jakke Lehtonen)]

@NullUsername

app.yml gibt 80:80 und 443:443 preis

Nur wenn Sie diese nicht ändern. Wie Sie es tun sollten und nur einen Port verwenden.

80:80 und 443:443 sind Standardeinstellungen und werden per se nur verwendet, wenn kein Reverse-Proxy oder etwas anderes als Frontend fungiert.

[NullUsername (NulledName)]

Du hast mir eine Idee gegeben.

Ich war damit beschäftigt, alle Basisdateien zu überprüfen, und ich glaube, ich habe es herausgefunden.

So einfach lol. Ich bin mit dem Wiederaufbau beschäftigt, das könnte 100%ig funktionieren, wenn ich die standardmäßigen, offiziell unterstützten Installationsmethoden verwende.

[NullUsername (NulledName)]

Erfolg Das Forum wurde nun installiert und funktioniert.

Verwendung der Standard- und unterstützten Installationsmethode

[NullUsername (NulledName)]

@pfaffman Sie können dies in die Installation verschieben, da es sich jetzt um eine unterstützte Installation handelt.

[Jagster (Jakke Lehtonen)]

Es ist da. Es ist nur als nicht unterstützt markiert

Was war Ihr Problem, warum haben Sie nicht mit der Installation ohne Reverse Proxy begonnen? Ich bin nur neugierig.