Sie müssen Änderungen von Hand vornehmen, damit es hinter dem Reverse-Proxy funktioniert. Vorausgesetzt, Sie wissen, wie das geht, und tun dies, nachdem Sie die app.yml erstellt haben.
Das könnte funktionieren:
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
Dann würden Sie die app.yml bearbeiten, um sie hinter dem Reverse-Proxy zu platzieren.
Beim Abhören von Discourse über einen Unix-Socket treten Warnungen zu gemischten Inhalten auf. Frische Installation.
Wenn ich mich recht erinnere, ist das das zwischengespeicherte Logo (ich gehe davon aus, dass Sie den Parameter force https aktiviert haben). Könnten Sie das im Browser-Entwicklertool/Netzwerk-Tab überprüfen?
Bitte markieren Sie dies als gelöst. Ich musste die HTTPS-Einstellung erzwingen und (auch eine Rake-Suche und -Ersetzung durchführen, um den Unterverzeichnispfad hinzuzufügen). Der Hauptserver läuft mit Apache zusammen mit vielen anderen Websites. Für dieses eine Beispiel.org haben wir WordPress installiert und Apache als Reverse-Proxy für /forums konfiguriert, wobei Discourse an einem WebSocket lauscht.
Anstelle von @rikings Methode oben?
Haben Sie einen Link zu einer Anleitung, wie man es auf dem “doppelten NGNIX”-Weg macht?
Leider weiß ich nichts über NGINX, aber die Anleitung von @riking scheint einfach genug zu sein, aber wenn es einen besseren Weg gibt, würde ich mich über die Details dazu freuen.
Hallo!
Wir haben Discourse durch Klonen von Dateien aus dem Git-Repository installiert und wie von Ihnen vorgeschlagen vorgegangen. Wir haben das SSL-Protokoll jedoch über den Nginx Proxy Manager gehandhabt (wir haben den Teil mit dem Port 443-Exponieren in app.yml auskommentiert).
Wir verwenden Portainer v2.11.0, in dem wir den erfolgreich erstellten Discourse-Container sehen können, aber wir können die Website nicht ausführen und erhalten die Fehlermeldung 502 Bad Gateway.
Haben Sie eine Idee, wie wir den Fehler beheben können?
Haben Sie auch die SSL- und Let’s Encrypt-Zertifikate entfernt?
Siehe:
Verwenden Sie eine Socket-Installation wie diese:
Dann siehe: How to debug a sub-folder Discourse install
Wäre es nicht sinnvoll, den externen Proxy so zu konfigurieren, dass er eine direkte Verbindung zu Discourse herstellt, anstatt zum Nginx-Proxy innerhalb des Containers (wodurch alles doppelt weitergeleitet wird)? Oder erfüllt der interne Nginx-Proxy eine wichtige Aufgabe, die ein externer Proxy nicht bewältigen kann?
Hallo, was kann ich tun, wenn keine nginx.sock-Datei vorhanden ist?
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
Hast du die Vorlage mit einbezogen?
Ich versuche, Discourse auf meinem Raspberry Pi 4 mit Dietpi OS und einigen Apps, die mit Nginx funktionieren, wie Nextcloud, zu installieren. Ich versuche, den Cloudflared-Dienst als Tunnel zu verwenden, aber nachdem die Discourse-Installation abgeschlossen ist, kann ich den Discourse-Dienst-Port nicht finden, um einen Tunnel zu erstellen. Wenn ich mich mit localhost verbinde, erscheint die Nginx-Startseite. Wo greife ich auf die Discourse-Website zu?
FYI: Ich habe certbot nicht konfiguriert, da ich den Cloudflared-Dienst nutzen möchte.
Hallo, ich versuche, Discourse hinter GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen zu installieren, aber ich kann nicht herausfinden, wie das geht.
Ich habe versucht, den Socket von Discourse für den nginx-proxy-Container verfügbar zu machen und eine per virtual host location configuration hinzuzufügen, ohne Erfolg.
Ich habe andere Dienste erfolgreich hinter diesem Proxy eingerichtet und vermisse nur noch Discourse. Haben Sie vielleicht einen Rat?
Hast du dir Nginx Proxy Manager zur Verwaltung mehrerer Sites mit Discourse angesehen?
Aus reiner Neugier, was sind die Vor- und Nachteile zwischen den folgenden beiden Ansätzen?
Aus irgendeinem Grund kann ich NGINX starten und Seiten ausliefern und Discourse ohne NGINX ohne Probleme starten. Aber wenn ich den ersten Ansatz verwende, bekomme ich immer die folgenden Fehler.
/var/discourse/shared/web-only/log/rails/production.log
Job exception: Error connecting to Redis on data:6379 (Redis::TimeoutError)
/var/discourse/shared/web-only/log/rails/unicorn.stderr.log
Failed to report error: Error connecting to Redis on data:6379 (Redis::TimeoutError) 3 heartbeat: Error connecting to Redis on data:6379
Und wenn ich den zweiten Ansatz verwende, würde er nicht einmal beim Ausführen von ./launcher rebuild <app> erstellen. Er würde einen Fehler wie diesen ausgeben:
I, [2022-09-12T08:54:16.483648 #1] INFO -- : cd /var/www/discourse & git fetch --depth 1 origin tests-passed
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com
I, [2022-09-12T08:54:56.561225 #1] INFO -- :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & git fetch --depth 1 origin tests-passed failed with return #<Process::Status: pid 35 exit 128>
Geben Sie hier den Code ein oder fügen Sie ihn ein
Verwenden Sie einen web_only-Container, aber keinen Datencontainer?
Ich habe das nicht, danke.
Ich habe meine app.yml so modifiziert, dass der Discourse-Container im Netzwerk mit demselben Namen wie mein Proxy läuft.
Dann habe ich die _location-Konfiguration wie im nginx-proxy-Dokument mit den Werten dieses Threads angegeben und den Discourse-Socket verfügbar gemacht (der Einfachheit halber am selben Pfad wie der Host).
Es scheint jedoch ein Berechtigungsproblem zu geben, aber ich weiß nicht wirklich, was es ist: Die Konfiguration wird von nginx übernommen, dann erhalte ich bei einer HTTPS-Anfrage diesen Fehler
[crit] 230#230: *21 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: <ip>, server: <domain>, request: "GET / HTTP/1.1", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
Innerhalb des Containers:
# ls -lah /var/discourse/shared/standalone/
total 12K
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 .
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 ..
drwxr-xr-x 2 root root 4.0K Sep 12 09:19 nginx.http.sock
Bearbeiten: Dies war ein Problem, das durch Container verursacht wurde, die mit und ohne sudo gestartet wurden.
Jetzt habe ich jedoch Folgendes:
[error] 219#219: *94 no live upstreams while connecting to upstream, client: <client-ip>, server: <domain>, request: "HEAD / HTTP/2.0", upstream: "http://<domain>/", host: "<domain>", referrer: "http://<domain>"
und einen 502 Bad Gateway-Fehler
Tatsächlich beides. Ich kann sehen, dass beide laufen, wenn ich docker ps verwende. Der einzige Unterschied besteht darin, den expose-Abschnitt zu aktivieren oder zu deaktivieren, obwohl ich mich jetzt frage, ob ich auch die Zeile expose: auskommentieren muss und nicht die Liste der Ports darin.
Entschuldigen Sie die doppelte Buchung, ich war zuvor durch eine andere, nicht zusammenhängende Angelegenheit verwirrt und der Socket wurde aufgrund eines Fehlers in meiner Konfiguration nicht mehr verwendet.
Hier ist mein aktueller Stand:
[crit] 274#274: *7 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
Ich habe chmod 777 shared/standalone/nginx.http.sock ausgeführt, um dieses Berechtigungsproblem vorübergehend zu umgehen, und jetzt erhalte ich:
[error] 203#203: *1 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
Offensichtlich mache ich einige Dinge falsch, aber ich weiß nicht, was. Bitte beachten Sie, dass ich NPM nicht verwende, sondern nginx-proxy, was etwas anders ist. Insbesondere erkennt es automatisch Docker-Container, die VIRTUAL_HOST definieren, um eine Konfiguration für sie zu generieren. Daher habe ich nur den location / { ... }-Teil hinzugefügt, der sich auf Discourse bezieht, und die Dateien in sites-available mit den listen-Direktiven nicht berührt.
Ich habe bemerkt, dass der Discourse-Container in einer Neustartschleife mit dem Status Restarting (100) 7 seconds ago steckt. Das liegt daran, dass er sich beschwert, dass er den Socket nicht löschen kann. Tatsächlich war es kein tatsächlicher Socket, sondern stattdessen ein Verzeichnis, vermutlich aufgrund schlechter Manipulationen beim Mounten von Volumes, um ihn für den nginx-proxy-Container verfügbar zu machen.
Ich habe das Verzeichnis entfernt, Discourse neu gestartet und es ist jetzt ein Socket. Allerdings kann ich ihn nicht als Volume für nginx-proxy verfügbar machen.
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting “/var/discourse/shared/standalone/nginx.http.sock” to rootfs at “/var/discourse/shared/standalone/nginx.http.sock”: mount /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
Es stellt sich heraus, dass ich den Socket nur nach /tmp/nginx.http.sock mounten musste, anstatt den gleichen Pfad beizubehalten. Endlich habe ich es anscheinend geschafft!
Das Problem wurde gefunden, warum das Öffnen eines Ports in /var/discourse/containers/web_only.yml wie folgt nicht funktionierte.
exponieren:
# - "443:443"
# - "80:80"
- "8080:80" # https
Laut Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All war SELinux im Spiel und es musste NGINX erlaubt werden, auf Discourse zuzugreifen, indem SELinux im permissiven Modus ausgeführt oder eingestellt wurde.
setsebool -P httpd_can_network_connect 1
Was interessant ist, ist, dass es funktioniert, wenn die NGINX-Konfiguration auf den Stammordner gesetzt ist, aber nicht, wenn sie auf einen Nicht-Stammordner gesetzt ist.
NGINX ist so eingestellt, dass / an Discourse weitergeleitet wird (funktioniert)
# Proxy-Anfragen an 443/discussions an Discourse weiterleiten, das auf 127.0.0.1:8080 lauscht
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
NGINX ist so eingestellt, dass /discussions/ an Discourse weitergeleitet wird (funktioniert nicht)
# Proxy-Anfragen an 443/discussions an Discourse weiterleiten, das auf 127.0.0.1:8080 lauscht
location /discussions/ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
In diesem Fall sehe ich Folgendes … Mein Bauchgefühl ist, dass, obwohl NGINX den Nicht-Stammordner /discussions/ erfolgreich an den Discourse-Docker weitergeleitet hat, Discourse selbst Seiten von sich selbst lädt und erwartet, dass Assets im Stammordner / liegen. Vermutlich ist es eine Voraussetzung, Discourse nur im Stammordner auszuführen? @pfaffman Hast du das schon einmal gesehen?
/var/log/nginx/example.com.error.log
2022/10/01 09:33:23 [error] 1954781#1954781: *1 open() "/etc/nginx/html/images/discourse-logo-sketch.png" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /images/discourse-logo-sketch.png HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/discussions/"
2022/10/01 09:33:25 [error] 1954781#1954781: *1 open() "/etc/nginx/html/service-worker.js" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /service-worker.js HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/service-worker.js"
