Hat jemand Discourse bereits erfolgreich auf einem Apache-Virtualhost statt des standardmäßigen Nginx eingerichtet?
Es scheint, als ginge der Großteil der Diskussionen zu Apache in diesen Foren nur darum, Discourse auf einem Host zu betreiben, auf dem bereits Apache läuft. In allen bisher gesehenen Fällen haben die Nutzer Apache lediglich als Proxy auf Nginx zurückgeschaltet. Zur Klarstellung: Ich möchte, dass der Docker-Backend-Container, auf dem Discourse läuft, den Virtualhost in Apache und nicht in Nginx betreibt.
Konkret hoffe ich, den Discourse-Backend-Container in Apache statt in Nginx laufen zu lassen, um mod_security zu aktivieren. Die Einrichtung von Nginx mit mod_security erfordert das Kompilieren von Nginx aus dem Quellcode – eine Komplexität, die ich gerne vermeiden möchte.
Mein aktueller Produktionsserver hostet bereits mehrere Websites (WordPress, MediaWiki usw.). Wir nutzen Nginx zur Terminierung von HTTPS und für eine grundlegende DDoS-Ratenbegrenzung → Varnish-Cache → Apache-Backend mit mod_security. Falls möglich, möchte ich diese Architektur auch für Discourse beibehalten – mit dem Discourse-Docker-Backend-Container, der Apache mit mod_security und nicht Nginx ausführt.
Hat jemand Discourse bereits erfolgreich in Apache laufen lassen?
Entschuldigung, ich bin neu bei Docker. Ich habe große Schwierigkeiten herauszufinden, wie die Datei ‘/etc/nginx/conf.d/discourse.conf’ überhaupt in den Docker-Container eingefügt wird. Kann jemand die Schritte erläutern, wie diese Datei von dem Skript ‘./launcher’ generiert und im Container platziert wird?
EDIT: Warte, wird Nginx von Discourse bereits aus dem Quellcode kompiliert?
Nein, das hat noch niemand geschafft. Discourse ist eng mit nginx verknüpft. Es wird schwierig bis unmöglich sein, es durch Apache zu ersetzen. Und da du als Einziger das machst, wird sich niemand darum kümmern, wenn es kaputtgeht.
Verwende einfach den Docker-Container, den jeder auf dem Planeten nutzt, und stelle Apache davor, falls du denkst, das würde die Sicherheit irgendwie erhöhen.
Es sieht so aus, als würde /etc/nginx/conf.d/discourse.conf im Container durch die Vorlagendatei /var/docker/templates/web.template.yml generiert – diese kopiert sie aus $home/config/nginx.sample.conf an den entsprechenden Ort und führt anschließend Änderungen mit den replace-YAML-Blöcken durch (die in nachfolgenden Vorlagen wie templates/web.socketed.template.yml weiter aktualisiert werden).
Ich ging davon aus, dass die Datei nginx.sample.conf einfach beim Kompilieren aus dem Quellcode in image/base/install-nginx von nginx an den entsprechenden Ort installiert wird. Die einzige nginx.sample.conf-Datei, die ich im Container fand (/var/www/discourse/config/nginx.sample.conf), enthielt jedoch bereits diskussspezifische Direktiven.
Ich hätte lieber nicht nginx → Varnish → Apache → nginx
Zur Klarstellung: Glaubst du, es wäre sicherer für mich, das Skript ‘image/base/install-nginx’ so zu aktualisieren, dass nginx im Discourse-Docker-Container mit Mod-Security-Unterstützung kompiliert wird, anstatt den Container so zu aktualisieren, dass er den Discourse-Vhost hinter Apache (statt hinter Nginx) ausführt? Wenn ja, welche Risiken bestehen darin, das install-nginx-Skript zu ändern? Wie könnte das meine Discourse-Installation in Zukunft beschädigen?
PSA: Alles, was Sie vorhaben, ist technisch zwar machbar, wird aber überhaupt nicht unterstützt. Wir können nicht jede denkbare Kombination unterstützen, die sich Leute ausdenken, um Discourse im Web bereitzustellen. Daher beschränkt sich die Unterstützung in diesem Forum auf Installationen, die sich an den Leitfaden unter discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub halten.
Es wird früher oder später auf vielfältige Weise kaputtgehen. Sie werden dafür verantwortlich sein, kontinuierlich Änderungen aus dem Upstream zu mergen und Ihre Fork dauerhaft zu pflegen.
@ledimeo Das hat @pfaffman vorgeschlagen, und ich denke, das wäre in diesem Fall besser, um zukünftige Probleme bei neuen Versionen zu vermeiden. Aber es scheint, dass er bereits einen anderen Nginx als Reverse-Proxy vorne verwendet und dies nicht möchte:
Trotzdem denke ich, dass das Proxyen von Apache zu Nginx (selbst wenn es am Ende diese vier Schichten ergeben würde) zumindest wartbarer wäre als der Versuch, die Funktionsweise von Discourse in der offiziellen Installation zu ändern.
Also, Apache als Proxy vor Discourse nginx einzurichten, ist definitiv eine Option.
Ich stimme zu, dass ein Profi damit zukünftige Updates erleichtern würde – das ist ein wichtiger Punkt.
Aber ein weiterer Hop in der Architektur würde nicht nur die Fehlersuche in der Zukunft erschweren – ich habe zudem Bedenken hinsichtlich der Leistung von Apache als Proxy für eine Webanwendung, die Long Polling verwendet, wie @sam in diesem Beitrag von 2016 angemerkt hat.
Im Allgemeinen bevorzuge ich nginx gegenüber Apache, außer wenn es um mod_security geht. Es wäre fantastisch, wenn die Paketquellen des Betriebssystems Pakete zur Aktivierung von mod_security in nginx bereitstellen würden, wie dies für Apache der Fall ist. Derzeit erfordert die Aktivierung von mod_security in nginx jedoch die Kompilierung von nginx aus dem Quellcode sowohl unter RHEL/Cent als auch unter Debian. Und ich vermeide es, in der Produktion auf aus dem Quellcode kompilierte Pakete angewiesen zu sein, wie die Pest.
Betreffend: Ich habe mich etwas mit dem install-nginx-Skript beschäftigt und einen kleinen Logikfehler gefunden: Die Bereinigungszeile, die sollte eigentlich die nginx-Quelldateien aus /tmp/ löschen, bewirkt nichts.
Es gibt kein Verzeichnis /tmp/nginx/: Es ist /tmp/nginx-$VERSION/ (derzeit /tmp/nginx-1.17.4/), und es gibt auch das Tarball /tmp/nginx-1.17.4.tar.gz.
Leider wird mein aktualisiertes Skript /var/discourse/image/base/install-nginx nicht ausgeführt, wenn ich /var/discourse/launcher destroy app && /var/discourse/launcher rebuild app starte.
Gibt es einen Grund, warum dieser rebuild-Befehl das aktualisierte install-nginx-Skript nicht erneut ausführt?
Wenn du mit Docker nicht vertraut bist, wird dies ein schwieriger Weg sein…
discourse_docker enthält den Quellcode für unser Basis-Docker-Image, das im öffentlichen Docker-Registry liegt und niemals lokal ausgeführt wird. Der gesamte Grund dafür ist die Verfügbarkeit eines wiederverwendbaren Images.
Ok. Nun, ich habe bezüglich Vim der Einfachheit halber gelogen. Ich führe diese Befehle tatsächlich aus, um das Skript idempotent und robust zu aktualisieren.
cd /var/discourse/image/base
cp install-nginx install-nginx.`date "+%Y%m%d_%H%M%S"`.orig
# Fügt einen Block hinzu, um das ModSecurity-Nginx-Modul kurz vor dem Herunterladen der Nginx-Quellen auszuchecken
grep 'ModSecurity' install-nginx || sed -i 's%\(curl.*nginx\.org/download.*\)%# mod_security --maltfield\napt-get install -y libmodsecurity-dev modsecurity-crs\ncd /tmp\ngit clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git\n\n\1%' install-nginx
# Aktualisiert die Konfigurationszeile, um das oben ausgecheckte ModSecurity-Modul einzubeziehen
sed -i '/ModSecurity/! s%^[^#]*./configure \(.*nginx.*\)%#./configure \1\n./configure \1 --add-module=/tmp/ModSecurity-nginx%' install-nginx
# Fügt eine Zeile zum Bereinigungsbereich hinzu
grep 'rm -fr /tmp/ModSecurity-nginx' install-nginx || sed -i 's%\(rm -fr.*/tmp/nginx.*\)%rm -fr /tmp/ModSecurity-nginx\n\1%' install-nginx
Wo sollte ich diese Befehle ablegen, damit das tatsächlicheinstall-nginx-Skript, das vom Container beim Booten verwendet wird, geändert wird?
