Hallo zusammen,
ich habe die Dokumentation durchgearbeitet, die vorgestellten Konfigurationsaufbauten und Empfehlungen gelesen und versucht, diese an meine einzigartige Situation anzupassen.
Für etwas, das relativ einfach zu sein scheint, ist es unglaublich frustrierend, dass keine der vorgeschlagenen Lösungen funktioniert hat.
Unsere Umgebung:
- Wir betreiben eine AWS EC2-Instanz, genauer gesagt ein AWS Linux 2 AMI;
- Wir haben Apache2 installiert und konfiguriert;
- Die Instanz ist Teil einer AWS-Zielgruppe (Target Group), auf die sich unser AWS-Load-Balancer bezieht;
- Unser SSL-/TLS-Zertifikat wird von AWS bereitgestellt und ist mit dem Load-Balancer verknüpft;
- Unser Domain-Provider ist
name.com; - Als Teil unserer Einrichtung haben wir mehrere Subdomains, die über CNAME-Einträge geleitet werden, die alle auf den AWS-Load-Balancer zeigen, welcher dann den Verkehr zur EC2-Instanz verwaltet;
- Der gesamte Verkehr, der zum Load-Balancer geleitet und dem Webnutzer bereitgestellt wird, ist sicher;
- Auf unserem Server betreiben wir drei separate Node-Express-Anwendungen;
- Die Ports sind in Express als Teil des Express-Server-Aufbaus definiert, aktuell die Ports 3000, 4000 und 5000;
- Der Verkehr wird von Apache basierend auf der Subdomain zur entsprechenden Web-App geleitet, zum Beispiel:
<VirtualHost *:80>
ServerName subdomain.domain.io
ProxyPreserveHost On
ProxyPass "/" "http://localhost:4000/"
ProxyPassReverse "/" "http://localhost:4000/"
</VirtualHost>
-
Obwohl nicht besonders relevant: Wir verwenden PM2, um unsere Express-Apps zu verwalten, sodass sie nach einem Server-Neustart automatisch gestartet werden.
-
Auf demselben Server haben wir Docker installiert;
-
Anschließend haben wir Discourse mit einer Kopie der app.yaml installiert (unter Verwendung von Run other websites on the same machine as Discourse - #182 by angus als Leitfaden).
Aktueller Status:
- Docker läuft
- Die Discourse-App (Container) läuft
- Die Express-Apps laufen alle und werden ordnungsgemäß von Apache geleitet
Hinweise:
- Ich habe versucht, die App zunächst ohne Freigabe der Ports gemäß der Dokumentation zu bauen. Als das nicht funktionierte, habe ich Port 8000 über HTTP-Port 80 freigegeben;
- In meinem einfachen Verständnis ist Docker wie ein Haus und die verschiedenen Container sind die Räume. Docker bestimmt, wie auf die App zugegriffen wird, also welcher Raum accessed wird. Meine Idee beim Freigeben von Port 8000 war, dass ich dann Port 8000 referenzieren könnte, so wie ich es jetzt mit meinen anderen Express-Apps tue, da 8000 freigegeben war. Das funktioniert jedoch nicht. Unten ist ein Beispiel dafür, was ich in Apache versucht habe:
# FAQ (DISCOURSE ROUTES)
<VirtualHost *:80>
ServerName discourse.domain.io
ProxyPreserveHost On
ProxyPass "/" "http://localhost:8000/"
ProxyPassReverse "/" "http://localhost:8000/"
</VirtualHost>
- Der einfache Test bestand darin, localhost:8000 im Browser auf dem Server einzugeben und zu testen. Der Server ist die AWS-Instanz mit installiertem Chromium. Die Tatsache, dass dies nicht sofort aufgelöst wird, sagt mir, dass es ein Problem gibt und mein Verständnis etwas Fundamentales vermisst. Meine Web-Apps laufen und sind auf den Ports verfügbar, die ich im Express-Setup angebe. Meine Erwartung war, dass es für den Docker-Container genauso ist.
Zusätzliche Hinweise:
- Ich erkenne, dass es eine potenzielle Lösung gibt, indem man NGINX „vor“ Apache und Docker platziert, um den Verkehr von
discourse.domain.iozu einem bestimmten Port 8000 auf dem lokalen Server zu leiten, also dem Port, der für den Docker-Container freigegeben ist, und gleichzeitig den gesamten anderen Verkehr von *.domain.io zu Apache auf einem anderen Port, sagen wir Port 9000, zu leiten. Anschließend würde ich meine VirtualHost-Konfiguration ändern, um den Verkehr von Port 9000 entsprechend zu leiten, also:
# EXPRESS APP ROUTING IN APACHE
<VirtualHost *:9000>
ServerName other_sub_domains.domain.io
ProxyPreserveHost On
ProxyPass "/" "http://localhost:4000/"
ProxyPassReverse "/" "http://localhost:4000/"
</VirtualHost>
- Für mich scheint dies völlig unnötig. Wenn die Domain
discourse.domain.iozu Apache geleitet wird und Apache die Anfrage erhält und versucht, sie weiterzuleiten, sollte es so einfach sein, sie auf den freigegebenen Port des Docker-Containers zu zeigen. - Außerdem würde dies ohnehin nicht funktionieren, wenn localhost:8000 auf dem Server selbst nicht aufgelöst wird.
Derzeit erhalte ich in Chrome einen 502-Fehler, wenn ich versuche, zu meinem Discourse-Docker-Container zu navigieren. (Siehe Screenshot oben).
Auszug aus app.yml
## Dies ist die All-in-One, eigenständige Discourse Docker-Container-Vorlage
##
## Nach Änderungen an dieser Datei MÜSSEN Sie neu bauen
## /var/discourse/launcher rebuild app
##
## SEien Sie *SEHR* VORSICHTIG beim Bearbeiten!
## YAML-Dateien sind SUPER SUPER empfindlich gegenüber Fehlern in Leerzeichen oder Ausrichtung!
## Besuchen Sie http://www.yamllint.com/, um diese Datei bei Bedarf zu validieren
templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml"
## Deaktivieren Sie diese beiden Zeilen, wenn Sie Lets Encrypt (https) hinzufügen möchten
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
## Welche TCP/IP-Ports soll dieser Container freigeben?
## Wenn Sie Discourse einen Port mit einem anderen Webserver wie Apache oder nginx teilen möchten,
## siehe https://meta.discourse.org/t/17247 für Details
expose:
- "8000:80" # http
#- "443:443" # https
params:
db_default_text_search_config: "pg_catalog.english"
## Setzen Sie db_shared_buffers auf maximal 25 % des gesamten Speichers.
## wird automatisch vom Bootstrap basierend auf dem erkannten RAM gesetzt, oder Sie können es überschreiben
#db_shared_buffers: "256MB"
## kann die Sortierleistung verbessern, erhöht aber den Speicherverbrauch pro Verbindung
#db_work_mem: "40MB"
## Welche Git-Revision soll dieser Container verwenden? (Standard: tests-passed)
#version: tests-passed
env:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## Wie viele gleichzeitige Webanfragen werden unterstützt? Hängt vom Speicher und den CPU-Kernen ab.
## wird automatisch vom Bootstrap basierend auf den erkannten CPUs gesetzt, oder Sie können es überschreiben
#UNICORN_WORKERS: 3
## TODO: Der Domainname, auf den diese Discourse-Instanz antworten soll
## Erforderlich. Discourse funktioniert nicht mit einer reinen IP-Nummer.
DISCOURSE_HOSTNAME: 'discourse.domain.io'
## Deaktivieren Sie dies, wenn Sie möchten, dass der Container mit demselben
## Hostnamen (-h-Option) wie oben angegeben gestartet wird (Standard "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: Liste der durch Komma getrennten E-Mail-Adressen, die bei der ersten Anmeldung zu Administratoren und Entwicklern werden
## Beispiel 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'user@domain.io'
## TODO: Der SMTP-Mailserver, der zur Validierung neuer Konten und zum Senden von Benachrichtigungen verwendet wird
## SMTP-Adresse, Benutzername und Passwort sind erforderlich
## WARNUNG: Das Zeichen '#' im SMTP-Passwort kann Probleme verursachen!
DISCOURSE_SMTP_ADDRESS: email-smtp.us-east-1.amazonaws.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: ******
DISCOURSE_SMTP_PASSWORD: ******
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, Standard true)
#DISCOURSE_SMTP_DOMAIN: ****** # (von einigen Anbietern erforderlich)
#DISCOURSE_NOTIFICATION_EMAIL: ****** # (Adresse, von der Benachrichtigungen gesendet werden sollen)
## Wenn Sie die Lets Encrypt-Vorlage hinzugefügt haben, deaktivieren Sie unten, um ein kostenloses SSL-Zertifikat zu erhalten
#LETSENCRYPT_ACCOUNT_EMAIL: me@example.com
## Die http- oder https-CDN-Adresse für diese Discourse-Instanz (konfiguriert zum Abrufen)
## siehe https://meta.discourse.org/t/14857 für Details
#DISCOURSE_CDN_URL: https://discourse-cdn.example.com
## Der MaxMind-Geolokalisierungs-IP-Schlüssel für die IP-Adresssuche
## siehe https://meta.discourse.org/t/-/137387/23 für Details
#DISCOURSE_MAXMIND_LICENSE_KEY: 1234567890123456
## Der Docker-Container ist zustandslos; alle Daten werden in /shared gespeichert
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
## Plugins gehen hier
## siehe https://meta.discourse.org/t/19157 für Details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
## Beliebige benutzerdefinierte Befehle, die nach dem Build ausgeführt werden sollen
run:
- exec: echo "Beginn der benutzerdefinierten Befehle"
## Wenn Sie die 'Von'-E-Mail-Adresse für Ihre erste Registrierung festlegen möchten, deaktivieren Sie und ändern Sie:
## Nach Erhalt der ersten Anmelde-E-Mail den Kommentar wiederherstellen. Es muss nur einmal ausgeführt werden.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "Ende der benutzerdefinierten Befehle"
Meine Domain, E-Mail-Adresse und E-Mail-Konfiguration sind korrekt. Wie erwähnt, benötige ich keine SSL/TLS-Konfiguration.
Anfrage:
- Ist die NGINX-Lösung der einzige Weg, um diese Einrichtung zum Laufen zu bringen, und falls ja, gibt es eine klarere Erklärung bezüglich der Einrichtungsschritte? Ich bin nicht in der Lage, den Server von Grund auf neu zu starten, nur um Discourse zum Laufen zu bringen, und das ohne Garantien.
- In Discourse behind reverse proxy and https - #2 by itsbhanusharma hat @Dark Matter folgende Apache2-Lösung bereitgestellt, aber ich glaube nicht, dass diese Lösung eine Node-Express-Umgebung im Sinn hat, und da mein localhost:8000 nicht aufgelöst wird, bin ich mir nicht sicher, ob dies funktionieren würde:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
ServerName discourse.example.com
DocumentRoot /website/discourse
RewriteEngine On
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / unix:/var/discourse/shared/socket-only/nginx.http.sock|http://localhost/
ProxyPassReverse / unix:/var/discourse/shared/socket-only/nginx.http.sock|http://localhost/
ErrorLog /var/log/apache2/discourse.error.log
LogLevel warn
CustomLog /var/log/apache2/discourse.access.log combined
RewriteCond %{SERVER_NAME} =discourse.example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
- Liegt das Problem hier in meiner Discourse-Konfiguration? Liegt das Problem vielleicht in meiner Apache-Routing-Konfiguration (ich vermute)? Oder fehlt mir etwas Fundamentales?
- Ich denke, dass die Lösung dieses Problems vielen Nutzern in der Zukunft helfen wird.
- Die erste Wahl wäre, Discourse lokal auf dem Server zu leiten.
- Dann wäre die Weiterleitung über die URL die zweite Wahl.
Mit freundlichen Grüßen
Matthew Lucas
