Probleme mit Patreon-Login, Force HTTPS und S3 CDN (drei) Probleme

Installation
1

Ich muss dies möglicherweise in drei separate Beiträge aufteilen, aber sie hängen zusammen, daher beginne ich mit einem.

Vor ein paar Tagen habe ich dieses Tutorial (How to Scale a Discourse Deployment with a Load Balancer and Managed Database Cluster | DigitalOcean) so ziemlich wortwörtlich verwendet und mein eigenständiges Discourse-Droplet auf Digital Ocean auf zwei Droplets innerhalb eines Load-Balancers migriert, bisher lief alles gut.

Anschließend habe ich dieses Tutorial (Configure an S3 compatible object storage provider for uploads) durchgearbeitet, aber nach dem Wiederaufbau von Discourse über die Kommandozeile zeigte meine Discourse-Website nur einen leeren Bildschirm. Ich habe im Inspektor im Browser nachgesehen und festgestellt, dass der Browser all meine Inhalte blockierte, weil sie über HTTP und nicht über HTTPS ausgeliefert wurden. Das liegt wahrscheinlich daran, dass der Load-Balancer SSL-terminiert ist, sodass alles Externe HTTPS ist, die Server selbst aber über HTTP laufen.

Zu diesem Zeitpunkt habe ich meine Server wieder komplett lahmgelegt und versucht, sie mit HTTPS innerhalb des Load-Balancers zum Laufen zu bringen, aber es war einfach nicht möglich. Ich konnte das Digital Ocean Space/CDN nicht mit S3/CDN gemäß diesem Tutorial (Configure an S3 compatible object storage provider for uploads) zum Laufen bringen. Ich habe es genauestens geprüft und jeden Aspekt mehrmals inspiziert, aber es funktionierte nicht. Die einzige Möglichkeit, Discourse wieder aufzubauen, bestand darin, den Parameter DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com aus app.yml zu entfernen, aber dann, obwohl es aufgebaut war, konnte ich den Server nicht zum Antworten bringen. Ich erhielt entweder eine 503 Server nicht antwortet-Fehlermeldung oder eine normale Browser-Meldung, dass der Server nicht antwortet oder getrennt wurde. Dies variierte je nach den Load-Balancer- und DO Space/CDN-Einstellungen, die ich ausprobierte. Ich habe jede mögliche Kombination von Einstellungen ausprobiert und nichts hat es mir ermöglicht, eine Seite auszuliefern.

Als ich den DISCOURSE_S3_ENDPOINT-Parameter beibehielt, erhielt ich während des Discourse-Wiederaufbaus die folgende Fehlermeldung, die jedoch verschwand, wenn ich den S3_ENDPOINT-Parameter auskommentierte.
Aws::S3::Errors::InvalidAccessKeyId: Aws::S3::Errors::InvalidAccessKeyId

Alle meine Dateien wurden nach S3 synchronisiert, daher gehe ich davon aus, dass der Zugriffsschlüssel in Ordnung war und das Problem irgendwie durch den S3_ENDPOINT-Parameter verursacht wurde.

Heute habe ich aufgegeben, den vorherigen Versuch zum Laufen zu bringen, und ein Backup meiner Droplets wiederhergestellt, die nur mit HTTP-Load-Balancing liefen. Schließlich habe ich es wieder zum Laufen gebracht, indem ich dieses Tutorial (Set up file and image uploads to S3) befolgt habe, aber dieses Mal habe ich die S3-Einstellungen über das Discourse Admin-Panel bearbeitet, anstatt die app.yml mit den Einstellungen aus dem empfohlenen Tutorial zu bearbeiten. Es hat endlich funktioniert, aber der wichtige Unterschied ist, dass ich die S3-CDN-Einstellungen bewusst weggelassen habe. Ich habe bestätigt, dass Bilder, die in Beiträge hochgeladen werden, auf S3 gespeichert werden und ich kann Discourse direkt nach S3 sichern, und das ist eigentlich alles, was ich will. Allerdings habe ich jetzt drei Probleme, die mich verfolgen, eines ist kritisch und zwei sind ignoriertbar, obwohl ich hier gerne Bestätigung erhalten würde, wenn möglich.

Das kritische Problem ist, dass sich Benutzer nicht mehr über den Patreon-Login-Button auf der Discourse-Login-Seite anmelden können. Diese Meldung wird angezeigt:
Sorry, there was an error authorizing your account. Please try again.

Die URL lautet:
https://mbp.community/auth/failure?message=invalid_credentials&origin=https%3A%2F%2Fmbp.community%2Flogin&strategy=patreon

Ich würde mich sehr über Ratschläge freuen, was ich versuchen könnte, um dies zum Laufen zu bringen, aber ich frage mich wieder, ob dies daran liegt, dass die Server intern kein HTTPS ausführen. Wie Sie an der URL sehen können, sind sie extern auf HTTPS, daher ist es schwer, sicher zu sein. Ich hoffe, jemand hier hat Erfahrung mit Digital Ocean Load-Balancing usw. mit Discourse.

Die anderen beiden Probleme werden jetzt in der Admin-Konsole wie unten aufgeführt:

Einige Ratschläge basierend auf Ihren aktuellen Website-Einstellungen

  • Ihre Website verwendet SSL. Aber [force_https](https://mbp.community/admin/site_settings/category/all_results?filter=force_https) ist in Ihren Website-Einstellungen noch nicht aktiviert.
  • Der Server ist so konfiguriert, dass Dateien nach S3 hochgeladen werden, aber es ist kein S3-CDN konfiguriert. Dies kann zu teuren S3-Kosten und einer langsameren Website-Leistung führen. Weitere Informationen finden Sie unter „Verwendung von Objektspeicher für Uploads“.

Ich habe nichts dagegen, force_https zu aktivieren, aber ich befürchte, dass es mich von meinem Server aussperren wird, da die internen Load-Balanced-Server kein HTTPS ausführen und ich aufgrund der Probleme von gestern nur ungern weitere zwölf Stunden damit verbringen möchte, mir den Kopf an der Wand einzuschlagen und unzählige 15-minütige Wiederaufbauten von Discourse zu beobachten, um nirgendwohin zu gelangen. Auch hier gilt: Wenn jemand weiß, dass es sicher ist, force_https mit meinen Konfigurationen zu aktivieren, lassen Sie es mich bitte wissen.

Und das zweite Problem, das wieder einmal nicht gut über die Parameter in der app.yml-Datei lief, daher zögere ich, dies auch noch einmal zu versuchen. Können Sie bestätigen, dass dies im Wesentlichen dasselbe bewirken würde wie die Parameter, die der app.yml-Datei hinzugefügt wurden? Wenn ja, werde ich diese zweite Nachricht einfach ignorieren. Umgekehrt, wenn es aus irgendeinem Grund sicher ist, es zu versuchen, lassen Sie es mich wissen und ich werde ein Backup erstellen und es ausprobieren.

Entschuldigung für den langen Beitrag. Ich hoffe, Sie können herausfinden, worum ich Ratschläge bitte.

1 „Gefällt mir“
2

Dann brauchst du dort wirklich Hilfe, denn hier wird nur eine Standardinstallation unterstützt.

Erwartest du mehr als 200.000 Seitenaufrufe pro Tag? Wenn nicht, ist ein einzelnes 8-GB-Droplet mit CDN viel einfacher zu verwalten und wahrscheinlich günstiger. Und soweit ich das beurteilen kann, gibt es mindestens ein paar Möglichkeiten, wie diese Anweisungen für niemanden funktionieren werden.

Hast du zuerst einen externen Redis eingerichtet, wie in Schritt 5 beschrieben? Wenn nicht, erwarte ich, dass die Dinge zumindest ein wenig kaputt sind. Sie implizieren, dass die Verwendung von Sticky es “reparieren” wird, aber das wird es wirklich nicht. Du kannst also schwer zu diagnostizierende fehlerhafte Fehler erwarten. Und sie geben keine Möglichkeit an, um sicherzustellen, dass alle deine Instanzen genau die gleiche Version von Discourse ausführen, was die Dinge ebenfalls wahrscheinlich kaputt machen wird.

Das hättest du wirklich zuerst tun sollen, sonst kann dieses Setup nicht funktionieren, da einige Uploads auf einem Server und andere auf einem anderen liegen werden, und diese Anweisungen erwähnen das Wort “Upload” nicht, daher erwarte ich, dass du, wenn du dies mehr als zum Testen verwendet hast, ein ziemliches Durcheinander hast und die Uploads zwischen deinen mehreren Droplets synchronisieren musst.

Dort steht ausdrücklich, dass das CDN von Digital Ocean nicht mit Discourse funktioniert.

Hast du ein anderes CDN verwendet, wie empfohlen? Bunny.net ist ziemlich einfach einzurichten.

2 „Gefällt mir“
3

Oh je, ich weiß nicht, wer diesen Leitfaden geschrieben hat, aber sicher nicht jemand, der sich mit Discourse im großen Maßstab gut auskannte.

Der letzte Schritt besagt, dass man weitere Backends zum Load Balancer hinzufügen kann, indem man die Droplet-Snapshot-Funktion verwendet. Da der Leitfaden jedoch die Verwendung von Object Storage für Uploads nicht erwähnt, wird dies die Benutzer-Uploads vollständig unterbrechen. Wenn Sie diesem Leitfaden folgen, werden Updates auch nicht trivial.

Mein Rat an @Martin_Bailey ist, nichts davon zu befolgen. Es wird nur zu einer fehlerhaften Installation führen, wie Sie festgestellt haben.

Bitte folgen Sie unserer offiziellen Installationsanleitung, wenn Sie eine schnelle und sinnvolle Installation von Discourse wünschen. Von diesem Weg abzuweichen, kann schnell zu einer Vollzeitbeschäftigung werden.

3 „Gefällt mir“
4

Lustig. Ich habe dort einen Kommentar hinterlassen, in dem einige der Probleme aufgeführt und auf Rafels Beitrag verlinkt wurden, aber er wurde gelöscht.

3 „Gefällt mir“
5

Wow! OK, ich dachte, es wäre gut gelaufen, obwohl mir ein paar Dinge aufgefallen sind, die nicht stimmten, aber ich habe jetzt eine Load-Balanced-Installation. Natürlich war das Erste, was ich fand, dass Bild-Uploads nicht funktionierten, weshalb ich S3 zur Speicherung von Bildern verwendet habe.

So wie es jetzt ist, wird es noch eine Menge Arbeit erfordern, um zu einem einzelnen Server zurückzukehren. Gibt es also etwas, das ich wegen des Patreon-Login-Problems tun kann? Die anderen beiden Probleme werde ich ignorieren.

Vielen Dank für Ihre Hilfe in jedem Fall. Sie leisten hier so gute Arbeit.

6

Hallo Jay, danke für deine Hilfe. Als Antwort auf deine Fragen…

Ich erwarte nicht viele Benutzer, da es sich um eine geschlossene Patreon-Community handelt. Mein Hauptziel war es, einen Server aktualisieren zu können, ohne dass die Website ausfällt. Ich habe tatsächlich bestätigt, dass dies möglich ist, daher war ich mit dem Setup zufrieden. Ja, ich habe Schritt fünf durchgeführt, daher werden Zustände auf einem externen Redis-Droplet gespeichert.

Das andere, was ich herausfinden musste und was mich eine Weile zurückgehalten hat, war, dass ich auch den unten stehenden Parameter zu app.yml hinzufügen musste, da der Rebuild immer wieder fehlschlug, weil versucht wurde, eine Verbindung zu Postgres auf dem Standardport herzustellen, obwohl der tatsächliche Port im DISCOURSE_DB-Parameter angegeben war.

DISCOURSE_DB_BACKUP_PORT: 25060

Ich hatte nicht an Uploads gedacht, bis ich alles basierend auf dem ersten Tutorial zum Laufen gebracht hatte, und es hat anfangs alles kaputt gemacht, als ich versuchte, S3 einzurichten, aber das lag daran, dass die von euch hier bereitgestellten DO Space CDN-Einstellungen nicht funktionieren.

Es wird ausdrücklich darauf hingewiesen, dass das Digital Ocean CDN nicht mit Discourse funktioniert.

Ich weiß, aber dann fügt das Tutorial dies hinzu:
DISCOURSE_S3_ENDPOINT: https://sfo3.digitaloceanspaces.com

Was von DO Space kommt, oder? Ich habe keine Ahnung, basierend auf allem, was ich in diesen Tutorials gelesen habe, wie ich mit einem anderen CDN arbeiten würde, aber im Moment mache ich mir keine Sorgen, da ich gleich darauf eingehen werde.

Nein, ich habe kein anderes CDN verwendet. Ich bin eigentlich damit zufrieden, kein CDN zu verwenden. Ich werde die CDN-Einstellungen leer lassen. Als weitere Aktualisierung werde ich, basierend auf dem Rat, den ihr mir bisher freundlicherweise gegeben habt, einfach zu meinem Backup von letzter Woche zurückkehren, aber ich dachte, ich würde versuchen, die force_https-Option zu aktivieren, und die Aktivierung hat das Patreon-Login-Problem behoben, wie ich es vermutet hatte. Am Server (n) wurde nichts geändert, daher wurde das Patreon-Login-Problem wahrscheinlich durch eine interne Discourse-Logik verursacht, obwohl ich (jetzt) erkenne, dass ich etwas tue, das ihr nicht empfiehlt oder unterstützt.

An diesem Punkt ist mein Setup so ziemlich das, was das erste Tutorial empfiehlt, aber Bilder und Backups gehen alle an S3, ohne ein CDN. Es funktioniert wirklich gut. Ich schätze, dass ihr mir empfehlt, einfach die Standalone-Installation zu verwenden, aber die Website jedes Mal für 15 Minuten herunterzufahren, wenn ein Update herauskommt, ist wirklich schmerzhaft. Erst gestern habe ich eure Verweise auf data.yml und web_only.yml für ein Multi-Server-Setup gefunden, aber ich konnte nicht herausfinden, was ich tun sollte, also habe ich aufgegeben.

Ich werde vorerst bei dem bleiben, was ich habe. Danke für deine Hilfe und für alles, was ihr tut.

7

Okay Leute, ihr habt gewonnen. :slight_smile:

Ich habe wieder mehr Probleme mit Bildern festgestellt, die nicht geladen wurden, da sie manchmal über HTTP und nicht über HTTPS geteilt wurden. Ihr hattet Recht, es ist ein Durcheinander.

Ich habe das meiste davon rückgängig gemacht, die Postgres-Datenbank belassen, aber nur noch einen Server-Droplet, keinen Load-Balancer mehr und Bilder/Redis lokal gespeichert. Ich habe S3 für die Website-Backups beibehalten. Ich liebe es, wie reibungslos das funktioniert.

Ich habe jetzt wieder 15-minütige Ausfallzeiten bei jedem Upgrade, aber ich habe insgesamt etwa fünf volle Tage damit verbracht, und ich kann keine weitere Zeit mehr dafür aufwenden. Daher bin ich froh, dass ihr mich bezüglich des ursprünglichen Tutorials, dem ich gefolgt bin, korrigieren konntet. Es ist fast so, als ob sie nur wollen, dass die Leute für mehr Droplets bezahlen. :slight_smile:

Danke nochmals für eure Hilfe.

8

Eigentlich, wenn ich fragen dürfte, gibt es ein Tutorial, das uns hilft, Discourse so einzurichten, dass diese 15-minütige Ausfallzeit bei jedem Update vermieden werden kann. Ich habe die Notiz zu data.yml und web_only.yml gesehen, aber ich habe keine Ahnung, was ich tun muss, um das zu erreichen.

9

Das separate Vorhandensein von data und web_only YMLs stammt aus dem Zwei-Container-Setup:

1 „Gefällt mir“
10

Das wird funktionieren und einige Probleme lösen. Und falls du aus irgendeinem (anderen) Grund ausgesperrt wirst, kannst du dich immer über launcher enter app wieder einloggen und die Website-Einstellung über die Rails-Konsole zurücksetzen.

Wie andere bereits sagten, ist es besser, einer anderen Anleitung zu folgen.

1 „Gefällt mir“
11

Hallo Leute,

Ich habe diesen DigitalOcean-Artikel geschrieben und anscheinend ein paar Fehler gemacht, mein Fehler!

Ich möchte den Artikel aktualisieren, um die Probleme zu beheben.

Daher möchte ich ein paar Fragen stellen, um sicherzustellen, dass ich die Dinge mit der korrigierten Version richtig mache.

Im Artikel habe ich erwähnt, dass man optional eine Managed Redis-Instanz verwenden könnte. Damals dachte ich, dass man mit Sticky Sessions das eingebaute Redis im Discourse-Image verwenden könnte. Ist das richtig? Vielleicht ist das nicht ausreichend und eine externe Redis-Instanz sollte eine zwingende Voraussetzung sein.

Ich stimme @Falco’s Kommentar zu Object Storage zu, das ist ein Versehen von mir. Ich kann den Artikel aktualisieren, um Anweisungen für die Verwendung von DigitalOcean Spaces zur Verwaltung von Bild-Uploads aufzunehmen.

Ich vermute, dass das Entfernen aller Zustände aus den Droplets die Antwort ist, um die Installationsprobleme zu lösen. Ich hatte gehofft, dass die Verwendung eines externen Redis aufgrund von Sticky Sessions optional ist, aber ich könnte mich irren.

Ich stimme auch zu, dass dies Ihre Discourse-Installation komplizierter zu aktualisieren macht. Ich denke jedoch, wenn Sie alle Zustände aus den Droplets entfernen, sollten Sie in der Lage sein, nur ein Droplet zu aktualisieren, es dann zu snappen und die anderen Droplets einfach durch neue zu ersetzen, die aus den Snapshots erstellt wurden (ein bisschen wie bei Kubernetes Deployments, nur dass Sie die Neuverteilung manuell durchführen).

Ich stimme auch zu, dass es wahrscheinlich bessere Möglichkeiten gibt, Discourse zu skalieren. Ich möchte den Artikel trotzdem korrigieren, damit die Leute ihn befolgen können, wenn sie möchten.

Danke,
Francis

12

Ich bin ein zufriedener Digital Ocean-Kunde und habe ein Dashboard, in das meine Kunden API-Schlüssel und einen Hostnamen eingeben können. Dann wird automatisch ein Droplet erstellt, Mailgun konfiguriert, auf die Einrichtung von DNS-Einträgen gewartet und dann Discourse installiert.

Es funktioniert überhaupt nicht so, wie Sie es vorschlagen. Ich habe mich in Ihrem Forum an Digital Ocean gewandt (ich konnte keinen anderen Weg finden), um Sie darüber zu informieren, und meine Nachricht wurde gelöscht. Dann, 9 Monate später, antworten Sie hier.

Es richtig zu machen ist eine ziemlich komplizierte Angelegenheit, und die Fälle, in denen es nützlich wäre, sind ziemlich weit hergeholt. Ich habe eine Website mit 100.000 Seitenaufrufen pro Tag auf einem 8-GB-Droplet. Wer, glauben Sie, ist die Zielgruppe für diese Anleitung?

Ja, Sie benötigen externe Redis-, Postgres- und S3-Buckets mit einem CDN, und das Digital Ocean CDN funktioniert nicht. Ihre Anleitung müsste sie also durch die Einrichtung des CDNs eines anderen Unternehmens führen. Ich glaube nicht, dass Sie das wollen. Und das ist nur die Einrichtung. Wenn sie dann ein Upgrade durchführen wollen, wäre das eine ganz andere Reihe von Verfahren, bei denen niemand sonst auf der Welt helfen könnte.

Das Beste, was Sie tun könnten, wäre, diese Anleitung ganz zu löschen. Wenn Sie ein echter Held sein wollen, könnten Sie die 1-Klick-Installation so reparieren, dass sie nicht Ihr eigenes proprietäres Skript für die Einrichtung der E-Mail usw. verwendet, damit es sich tatsächlich um eine Standardinstallation handelt. Es ist ziemlich verwirrend, Strg+C drücken zu müssen, um zu Discourse zu gelangen, und da Leute, die die 1-Klick-Installation verwendet haben, nicht die Standard-Discourse-Tools verwendet haben, wissen sie nicht, wie sie diese verwenden sollen, wenn es Zeit für ein Upgrade über die Befehlszeile ist. Es wäre wirklich, wirklich großartig, wenn Sie das tun könnten.

Hier können Sie Leute sehen, die es benutzt haben und Probleme hatten: Search results for 'digital ocean one-click' - Discourse Meta

1 „Gefällt mir“
13

Nein, da Redis kein einfacher Cache ist, sondern viele Zählungen, Ratenbegrenzungen, Hintergrundaufträge und Pub/Sub verarbeitet. Mehrere Redis-Instanzen führen zu korrupten Zählungen und fehlerhaftem Verhalten.

Das würde es tun, aber das Hinzufügen eines verwalteten Redis, eines verwalteten PostgreSQL, eines verwalteten Load Balancers, eines Objektspeichers und einer Container Registry wäre auch teurer als die Bezahlung unseres Standard-Hostings und viel komplizierter zu warten.

Zu diesem Zeitpunkt ist die Schnittmenge zwischen Leuten, die Hunderte von Dollar pro Monat bezahlen wollen und denen es egal ist, ob ihr Dienst wegen eines SPOF ausfällt, ziemlich klein, und es wird eher zu einem Hobbyisten-Setup als zu dem, was wir für Foren-Admins empfehlen würden.

1 „Gefällt mir“