Der Container auf dem Host führt install-nginx wie oben erwähnt niemals aus.
Ich bin mir nicht sicher, ob dieses Thema besonders nützlich ist.
Du stößt die Architektur von Discourse ab, akzeptierst nicht die Aussagen der Entwickler bezüglich der Optimierungen des Produkts, scheinst mit Docker nicht vertraut zu sein und gibst selbst zu, in deinen Fragen zu lügen, was unsere gemeinsame Zeit verschwendet.
Dieses Thema trägt bereits das #unsupported-install-Label, da du weit vom Rahmen der kostenlosen Unterstützung für die Community abweichst. Wenn dir diese Dinge wirklich wichtig sind, warum eröffnest du dann nicht ein neues Thema im Marketplace? So kannst du dein eigenes Geld investieren, um einen Berater zu bezahlen, der dich schult, anstatt unsere Zeit zu beanspruchen.
Nein, tut mir leid. Ich muss also die oben genannten sed-Befehle im Hooks-Abschnitt der app.yml platzieren? Gibt es irgendwo ein Beispiel, wie man das macht, um eine Datei im docker_discourse-Repository beim Bootstrapping zu ändern? Derzeit enthält dieser Abschnitt nur einen git clone-Befehl für Plugins.
Ich könnte diese sed-Befehle wahrscheinlich in einen cmd-Abschnitt einfügen, ähnlich wie den git clone-Befehl, aber ich weiß nicht, in welchem Verzeichnis das install-nginx-Skript liegt.
Außerdem: Wo befindet sich die app.yml? Ich konnte nicht auf den oben genannten hooks-Abschnitt verlinken, da das containers-Verzeichnis im Repository leer ist 
Die gesamte Dokumentation für diese Aufgaben findet sich hier auf Meta. Wir überspringen zwar gerne das Lesen des Handbuchs, aber in diesem Fall solltest du wirklich zu den Grundlagen zurückkehren.
Du gehst das Ganze ehrlich gesagt falsch an.
Ich verweise erneut auf das Tag unsupported-install – die Erwartungshaltung ist, dass du, wenn du von der Standardinstallation abweichst, die zusätzliche technische Verantwortung selbst übernimmst.
Wie hast du die Instanz installiert?
Entschuldigung, aber ich bemühe mich, vor dem Posten nach Dokumentation zu suchen. Ich würde mir sehr gerne ein Discourse-Handbuch wünschen, und ich habe bereits viele der mit #howo getaggten Themen durchgelesen. Leider scheint es kein Discourse-Handbuch zu geben.
Ich schätze deine Hilfe dabei sehr, und ich bin sicher, dass sie anderen in der Zukunft helfen wird, die nach Dokumentation suchen, um diese Dinge zu tun…
Zuerst discourse-setup, was letztendlich eine defekte Installation zur Folge hatte. Dann manuelles Bearbeiten von app.yml, gefolgt von ./launcher rebuild app
Ich finde, das ist eine interessante Diskussion, um Discourse besser kennenzulernen.
Ich würde mich für nginx entscheiden, vielleicht die app.yml so anpassen, dass das mod_security-Modul während des Kompilierungsprozesses hinzugefügt wird, und mein eigenes Basis-Image erstellen.
Discourse ist eine komplexe Software, die auf Rails läuft, was die Bereitstellung noch komplizierter und schwieriger macht, um sie einfach und konsistent zu deployen. Deshalb hat das Team bei der Erstellung des Docker-Images besonders viel Aufwand betrieben.
Das Image enthält jede Menge Black Magic mit unzähligen Optimierungen, um im unterstützten Installationsmodus so gut wie möglich zu laufen.
Wenn man das weiß und alle Puzzleteile zusammenfügen kann (z. B. die 2–3 Repositories, die für den Betrieb von Discourse benötigt werden), ist es nicht unmöglich, das zu erreichen, was du möchtest.
Da dein Setup nginx -> varnish -> apache ist, warum stellst du es nicht auf nginx -> varnish -> Discourse um, wobei mod_security zum Basis-Image hinzugefügt und über Hooks eingerichtet wird?
Die Wahrscheinlichkeit, dass mod_security Ihre Sicherheit erhöht, ist verschwindend gering. Diejenigen, die Discourse warten, legen großen Wert auf Sicherheit, sodass die Probleme, die mod_security beheben soll, höchstwahrscheinlich bereits behoben sind. Zudem ist die Wahrscheinlichkeit, dass die Installation von mod_security in Ihrem Image Discourse unbrauchbar macht, deutlich größer als null. Falls Sie mod_security installieren und feststellen, dass Discourse nicht mehr funktioniert, müssen Sie Discourse selbst so anpassen, dass es mit mod_security kompatibel ist. Anschließend müssen Sie entweder die Discourse-Maintainer davon überzeugen, dass Sie ein legitimes Sicherheitsproblem gefunden haben, oder Sie sind gezwungen, Ihren eigenen Fork dauerhaft zu pflegen.
Davon kann nichts Gutes kommen. Es ist höchst unwahrscheinlich, dass davon etwas Gutes kommt.
Zustimmung, eine weitere WAF grenzt an Sicherheit durch Verschleierung.
Es werden echte proaktive Anstrengungen unternommen, um die Diskussionsplattform sicher zu halten:
Dieses Thema hat sich von der ursprünglichen Frage nach dem Betrieb von Discourse auf Apache (anstatt als Proxy-Weiterleitung zu Nginx) entfernt.
Ich finde jedoch, dass eine Diskussion darüber, eine WAF (mod_security oder eine andere) vor Discourse zu platzieren, für die Community nützlich ist. Daher habe ich ein separates Thema erstellt, um speziell Discourse + WAF hier zu diskutieren: