Nach einer Woche der Suche nach einer Lösung, um Discourse neben Apache zu installieren, bitte ich widerwillig um Rat zu meinen nächsten Schritten, da es scheint, dass die Aktivierung von SSL für Discourse hinter Apache aufgrund der Nginx-lastigen Architektur von Discourse praktisch unmöglich ist.
Aktuelle Struktur meiner Hosting-Umgebung:
Digital Ocean $10 Droplet
Ubuntu 18.04
Apache mit Let’s Encrypt SSL für die HTML-Startseite
PHP, MySQL und phpMyAdmin
Webmin (ohne SSL)
Discourse
Ich möchte die Flexibilität behalten, WordPress zu installieren, daher bin ich nicht überzeugt, dass Nginx der richtige Weg ist, da ich gelesen habe, dass Apache eine bessere Kompatibilität mit WordPress bietet.
Mein Ziel: SSL für meine gesamte Domain aktivieren, einschließlich Discourse, ohne Discourse auf einen eigenen Droplet auszulagern. Wenn dies eine begrenzte Nutzung von Nginx erfordert, ist das in Ordnung. Ich brauche lediglich eine Orientierungshilfe, welche Tutorials ich mir ansehen sollte, um dieses Durcheinander zu lösen.
Ich suche nach etwas Ähnlichem, aber Sie sind im Prozess schon weiter. Ich habe ein paar Fragen zu Ihrer Konfiguration, bei denen ich mir nicht ganz sicher bin – wenn Sie nichts dagegen haben, sie zu beantworten:
Verwenden Sie einen Reverse-Proxy?
Übernimmt der Reverse-Proxy die SSL-Verschlüsselung?
Verschlüsseln die anderen Server nicht selbst und verlassen sich stattdessen auf den Reverse-Proxy für SSL, oder setzen Sie auf Defense in Depth mit SSL auf jedem einzelnen Server?
Erfolgt die Kommunikation zwischen Reverse-Proxy und Servern ausschließlich über Sockets und nicht über Ports?
FWIW: Ich habe umfangreiche Tests sowohl mit Apache2 als auch mit nginx als Reverse-Proxy vor Discourse in der Produktion durchgeführt (unter Verwendung von Unix-Sockets), und nginx ist nicht „viel schneller“.
In dieser Konfiguration ist nginx „etwas schneller“, aber der Geschwindigkeitsunterschied ist für den Benutzer nicht spürbar.
Darüber hinaus zeigen Google PageSpeed-Tests in den Webmaster-Tools (Lightspeed), über die Zeit gemittelt, keine signifikanten Unterschiede zwischen den beiden Reverse-Proxys.
Dieser FWIW-Kommentar basiert nicht auf Theorien oder darauf, was andere geschrieben haben; er beruht auf realen Produktionstests.
Wir betreiben alle unsere Discourse-Instanzen hinter Apache2-Reverse-Proxys (ursprünglich waren es nginx-Reverse-Proxys), da wir es bevorzugen, viele Websites (Virtual Hosts) auf unseren Servern zu betreiben, auf denen bereits LAMP-Anwendungen gehostet werden.
Jeder, der Apache2 als Reverse-Proxy anstelle von nginx verwenden möchte, wird problemlos zurechtkommen! Diese Tatsache macht Discourse einer breiten Benutzer- und Hosting-Basis (Apache2 und nginx) leicht zugänglich.
@fzngagan Ich fange nicht von vorne an, und dieses Tutorial ist für CentOS, obwohl ich in meinem Beitrag deutlich gemacht habe, dass ich Ubuntu verwende.
@EricGT Schau dir die Lösung an, die ich in meinem eigenen Thread geteilt habe, denn Support zu finden, wenn du etwas anderes als Nginx oder CentOS verwendest, ist praktisch unmöglich – wie dieser Thread beweist, in dem ich keine Antworten auf meine Frage erhalten habe, sondern stattdessen eine themenfremde Debatte über Apache gegen Nginx.
Das mag durchaus der Fall sein, aber Apache wird breiter unterstützt. Discourse ist die einzige Forensoftware, die ihre Nutzer im Grunde zu Nginx zwingt. Deshalb bevorzuge ich es, bei Apache zu bleiben, da es verbreiteter ist, für neue Benutzer einfacher zu handhaben ist und Support viel leichter zu finden sein wird. „Tuning
Wie wir mehrfach deutlich gemacht haben, gibt es aufgrund von Zeit- und Gesundheitsgründen eine Grenze dessen, was wir hier kostenlos unterstützen können. Deshalb bieten wir eine standardisierte Installation an, die für 95 % der Nutzer, die sie ausprobieren, gut funktioniert, und wir unterstützen diese vollständig.
Wenn Sie sich für kostenpflichtige Supportoptionen für angepasste Installationen interessieren, empfehle ich Marketplace.
Dieses Forum funktioniert größtenteils peer-to-peer, sodass Ihre Aussage absolut keinen Sinn ergibt. Außerdem habe ich noch nie eine komplexe Frage gestellt, sondern lediglich um Klärung gebeten oder um eine Aktualisierung bestehender Tutorials, die trotz Veraltetheit oder falscher Inhalte weiterhin ständig verlinkt werden. Ich musste mir von DigitalOcean, einem Hosting-Anbieter, Hilfe holen, um einen ordentlichen Reverse-Proxy einzurichten. Das ist geradezu unglaublich, selbst für Open-Source-Software.
Ihre Antwort erweckt bei mir den Eindruck, dass „Support
Erstens: Wir nutzen Discourse in der Produktion hinter einem Apache2-Reverse-Proxy (in mehr als einer Instanz) und hatten keinerlei Probleme bei der Einrichtung – außer dem üblichen „Google, wenn du Hilfe brauchst“, das jeder ohne Zögern tut.
Zweitens: Ich habe das Discourse-Team oder niemanden auf Meta niemals darum gebeten, Apache2 als unseren Reverse-Proxy zu unterstützen, da diese Konfiguration nicht offiziell unterstützt wird. Discourse unterstützt (soweit mir bekannt) „offiziell“ keine Multi-Container-Konfigurationen, Reverse-Proxies (Apache2), Kubernetes, Docker Swarm und eine nahezu unendliche Anzahl weiterer Konfigurationen. Es ist verständlich und richtig, dass das Discourse-Team, das diese großartige Software kostenlos und quelloffen bereitstellt und jeden Commit auf GitHub veröffentlicht, ihre „offiziell unterstützten Konfigurationen“ begrenzt. Ich finde, Jeff hat das treffend und korrekt zusammengefasst:
Nun, wie wir mehrfach klarstellen, gibt es aufgrund von Zeit- und Vernunftbeschränkungen eine Grenze dessen, was wir hier kostenlos unterstützen können. – Jeff A.
Drittens: Discourse bietet zwar einige Anleitungen für „nicht unterstützte“ Konfigurationen an, etwa für Apache2 als Reverse-Proxy; jedoch ist die Einrichtung eines Reverse-Proxys keine „Discourse-Aufgabe“ an sich. Es handelt sich um eine „allgemeine Systemadministrator-Aufgabe“, die im Wesentlichen für jede Backend-Anwendung, einschließlich Discourse, gleich ist.
Wir betreiben Apache als Reverse-Proxy vor einer Reihe von Webanwendungen, darunter Discourse, Docker Registry und anderen Docker-Containern und Apps. Die Verwendung von Apache2 (oder nginx) als Reverse-Proxy ist nicht spezifisch für Discourse. Es ist eine allgemeine Systemadministrator-Aufgabe.
Viertens: Im Internet gibt es eine Fülle von Informationen darüber, wie man Apache2 als Reverse-Proxy für eine Anwendung einrichtet. Es ist völlig unnötig und auch nicht hilfreich für dein Anliegen, das Discourse-Team wegen dieses Problems zu schikanieren. Menschen zu schikanieren und Begriffe wie „Schauspiel“ zu verwenden, ist sowohl unzutreffend als auch nicht hilfreich für dein Anliegen (oder für irgendjemanden hier).
Zusammenfassend also für dich, @OrbitStorm (dies ist mein letzter Beitrag zu deinem Thema, lies ihn bitte sorgfältig): Was bereits gesagt wurde, einschließlich der freundlichen und geduldigen Worte von J. A., bietet dir viele Möglichkeiten:
Du kannst einfach ins Internet gehen und lernen, wie man Apache2 als Reverse-Proxy einrichtet (das haben wir getan). Es macht Spaß und ist kostenlos, diese allgemeine Systemadministrator-Aufgabe zu erlernen.
Du kannst jemanden beauftragen, dies für dich zu erledigen, wenn du nicht lernen möchtest, es nicht selbst „herausfinden“ kannst oder keine Zeit hast.
Du kannst hier posten, schimpfen und toben, Meta und dieses Forum als „Schauspiel“ bezeichnen und allen Beleidigungen entgegenwerfen, um sie zu zwingen, dich persönlich bei einer nicht unterstützten Konfiguration zu unterstützen.
Ich empfehle dir dringend, als Discourse-Nutzer und Systemadministrator mit mehreren Jahrzehnten Erfahrung, Option #3 nicht zu wählen (Einschüchterung und Schikanieren werden beim Meta-Team nicht funktionieren, das kann ich dir garantieren); und Option #1 zu wählen, wenn du kein Geld für Hilfe ausgeben möchtest.
Die Einrichtung von Apache2 als Reverse-Proxy für Discourse ist wirklich ziemlich einfach. Es gibt einige Meta-Beiträge von Discourse dazu (einige aktuell, einige veraltet), und es gibt unzählige Anleitungen im Internet darüber, wie man Apache2 als Reverse-Proxy für eine Webanwendung einrichtet. Die Technik ist dieselbe. Ich empfehle, beim Betrieb im Reverse-Proxy-Modus einen Unix-Socket freizugeben.
Ehrlich gesagt macht es Spaß, Apache2 als virtuellen Host-Reverse-Proxy für Discourse einzurichten. Warum sollte man es stressig machen und den Leuten, die diese großartige Software geschaffen und kostenlos zur Verfügung gestellt haben, Beleidigungen entgegenwerfen? Discourse ist ein kostenloses Geschenk! Wenn du Discourse anders als in den offiziell unterstützten Konfigurationen konfigurieren möchtest, wird dich niemand daran hindern!
Zum Abschluss, @OrbitStorm, rate ich dir dringend (als Discourse-Nutzer, nicht als Teammitglied), deinen Ansatz, Meta durch Schikanieren um Unterstützung zu bitten, zu ändern. Wie bereits erwähnt, betriebe ich Discourse in „nicht offiziell unterstützten“ Konfigurationen und habe hier Updates und Code veröffentlicht, um anderen zu helfen (Rückgabe an diese großartige Gemeinschaft). Ich habe bereits funktionierenden Code veröffentlicht, der einfach zu befolgen ist, um Apache2 als Reverse-Proxy einzurichten, genauso wie andere vor mir.
Bitte wähle entweder #1 (mach es selbst) oder #2 (beauftrage jemanden, es zu tun); und lass bitte deinen aktuellen Ansatz #3 (Einschüchterung, Schikanieren und Beleidigungen gegenüber dem Meta-Team) fallen. Wenn du #3 wählen möchtest, poste einfach in unseren Unix- und Linux-Foren, und du kannst mich dort so oft schikanieren, wie du willst
Sie haben diese Textwand als Antwort zusammengestellt, ohne jemals das ursprüngliche Thema wirklich anzusprechen, in einer vergeblichen Bemühung, etwas zu beschützen, das gar nicht angegriffen wird. Sie haben mich tatsächlich als „Mobber
Ich verstehe nicht, warum die SSL-Konfiguration etwas mit den Apps hinter dem Proxy zu tun haben soll , solange die SSL-Vorlage in der app.yml deaktiviert ist? Nginx, Apache, HAProxy oder Traefik – alle nutzen das gleiche Konzept von Snippets, Serverblöcken oder Virtual Hosts, bei dem man im Grunde SSL aktiviert, den Speicherort der Zertifikate auf dem Host angibt und ein paar SSL-Parameter festlegt. Hier lauern vielleicht Gefahren?
Ich denke, die Lösung, die du suchst, hängt nicht mit Discourse zusammen, sondern mit Apache. Ich glaube, jede Standard-SSL-Apache-Konfiguration mit Virtual Host wird problemlos mit Discourse funktionieren, wie es auch bei anderen Reverse-Proxys der Fall war. Aber vielleicht bin ich etwas zu optimistisch .
Allerdings erinnere ich mich an ein Problem mit den Verschlüsselungsalgorithmen (Ciphers). Achte darauf, die in den Docker-Containern verwendeten Zeilen sorgfältig zu kopieren und einzufügen (die Zeile ist sehr lang).
Was diesen Abwärtstrend angeht: Ich finde, das ist eher wie Skifahren abseits der Pisten. Es ist toll, aber von der Bergrettung wird es stark missbilligt. Ich würde es anders sehen, wenn man in einen Abgrund stürzt, während man noch lernt, ob man ein guter Skifahrer ist.
, solange die SSL-Vorlage in der app.yml deaktiviert ist? Nginx, Apache, HAProxy oder Traefik – alle nutzen das gleiche Konzept von Snippets, Serverblöcken oder Virtual Hosts, bei dem man im Grunde SSL aktiviert, den Speicherort der Zertifikate auf dem Host angibt und ein paar SSL-Parameter festlegt. Hier lauern vielleicht Gefahren?
.