Was sind die richtigen Einstellungen für einen S3 Bucket (mit Nicht-Amazon-URL)?

Unterstützung Installation
1

Also, ich habe einen Amazon S3-Bucket eingerichtet, um meine Forum-Assets zu speichern. Ich habe ihn auf eine eigene Domain gelegt und CloudFlare CDN konfiguriert, um den Inhalt zu cachen.

Meine eigene Domain heißt so etwas wie http://forum-storage.com und zeigt auf https://forum-storage.com.s3-us-east-1.amazonaws.com. Der S3-Bucket selbst heißt forum-storage.com.

Das funktioniert alles einwandfrei. Wenn ich ein Bild im Hauptordner des Buckets ablege, kann ich es über meine eigene URL abrufen, also liefert http://forum-storage.com/test.jpg das Bild zurück, inklusive der CloudFlare-Header.

Drei einfache Fragen…

#1

Jetzt muss ich Discourse anweisen, diese neue URL als meinen S3-Bucket zu verwenden. Was trage ich in diese drei Felder ein?

image
image1976×792 48.9 KB

#2

Derzeit habe ich Bilder in meinen Forum-Beiträgen, die sich in einem anderen S3-Bucket befinden, und ich habe auch Bilder, die lokal gespeichert sind. (Meine Bild-URLs sind also ganz schön verstreut.)

Sobald ich die richtigen Änderungen vorgenomme (siehe oben), bedeutet das, dass alle NEUEN Medien, die zu meinem Forum hinzugefügt werden, in den neuen Bucket gelangen, aber bestehende Bilder nicht verschoben werden und weiterhin von ihrem aktuellen Speicherort abgerufen werden, korrekt?

#3

Da dies ab jetzt für alle Bilder funktioniert, wie kann ich Discourse anweisen, alle alten Bilder, die sich nicht in diesem neuen Bucket befinden, in den neuen Bucket zu VERSCHIEBEN (und gegebenenfalls Beiträge neu zu rendern)?

Das Ziel ist es, alles in einen einzigen Bucket zu bekommen, diesen neuen hinter dem CDN.

2

:rotating_light: JETZT AUFHÖREN :rotating_light:

Erstellen Sie einen neuen Bucket, dessen Name keinen Punkt enthält. Wenn Sie fortfahren, werden Sie aufgrund der Funktionsweise von SSL-Wildcard-Zertifikaten endloses Leid erfahren.

Ref: Discourse does not allow dot «.» symbol in bucket name while Amazon S3 allows it
Ref: https://stackoverflow.com/questions/62568657/ssl-certificate-issue-with-bucket-name-containing-dots-while-trying-to-use

3

Hmmm, ok. Kleines vorübergehendes Problem! :wink: Danke für den Hinweis @riking.

AWS S3 bietet eine Funktion, bei der du, wenn du den Bucket genauso nennst wie die Domain, einfach einen CNAME-Eintrag für die Domain hinzufügen kannst und alles funktioniert.

Jetzt suche ich überall nach Informationen, wie man eine Domain an einen Bucket anbindet, der nicht denselben Namen wie die Domain hat… hmm

@BryanV, wie hast du https://discourse-uploads.bokeh.org auf deinen S3-Bucket gezeigt?

4

Hmm, das ist nett, aber du möchtest einen CDN-Dienst wie CloudFront vor dem Bucket haben, der die CNAME-Einträge empfängt. Das ist also derzeit keine wirklich nützliche Funktion.

Ohne ein CDN erhältst du dieselbe überhöhte Rechnung für den Datenverkehr.

5

Richtig. Ich glaube, wir sind auf derselben Seite? Um es klarer zu sagen: Wie ich es verstehe, gibt es drei Möglichkeiten, Discourse und S3 zu verbinden:

  1. Discourse direkt mit der S3-Cloud verbinden. Vorteil: Super einfach einzurichten. Nachteil: Wird schnell teuer.

  2. Discourse die S3-Cloud über eine benutzerdefinierte Domain (z. B. forum-storage.com) nutzen lassen, damit ich ein CDN verwenden kann. Vorteile: Sehr einfach mit S3 einzurichten, wenn der Bucket-Name exakt mit der benutzerdefinierten Domain übereinstimmt (also forum-storage.com.s3-amazon-aws.com). Nachteile: SSL funktioniert nicht ordnungsgemäß.

  3. Discourse die S3-Cloud über eine benutzerdefinierte Domain nutzen lassen (wiederum, damit ich ein CDN verwenden kann), aber den S3-Bucket so einrichten, dass kein zusätzlicher Punkt im Namen steht (also forum-storage-com.s3-amazon-aws.com). Vorteile: SSL funktioniert einwandfrei. Nachteile: Nicht so einfach mit Amazon S3 einzurichten.

Also… Ich habe #1 verwendet, bis ich die Rechnung bekam :slight_smile: Dann habe ich erfahren, dass #2 eine Option ist, habe es eingerichtet und diesen Beitrag gestartet, und prompt erfahren, dass #2 eigentlich keine Option ist.

Jetzt arbeite ich an #3. Ich glaube, ich muss den DNS-Dienst „Route 53

6

Dafür gibt es Tutorials, zum Beispiel habe ich gerade dieses für StackPath gefunden:

https://support.stackpath.com/hc/en-us/articles/360001457743-Using-Amazon-S3-as-a-Site-Origin

7

@BryanV Wie hast du https://discourse-uploads.bokeh.org auf deinen S3-Bucket verweisen lassen?

Ich habe einen CNAME-Eintrag hinzugefügt, der auf die <lange ID>.cloudfront.net-URL der Cloudfront-CDN-Verteilung zeigt, und diesen in unsere DNS-Konfiguration für bokeh.org integriert (in unserem Fall läuft dies über Cloudflare, aber das sollte keine Rolle spielen).

Als Referenz: Unser S3-Bucket enthält keine Punkte im Namen, aber ich erinnere mich nicht an spezifische Probleme bei der Einrichtung der CDN oder beim Erstellen des Buckets; es wird lediglich ein eindeutiger Name benötigt.

8

Das ist zweifellos das Frustrierendste überhaupt. Ich kann mir einfach nicht erklären, wie man Amazon S3-Buckets (ohne Punkt im Bucket-Namen!), meine eigene Domain und CloudFlare so verknüpft, dass alles funktioniert. Wenn ich einen Punkt im Bucket-Namen setzen könnte, wäre das kein Problem. Aber im Moment ist das alles viel zu verwirrend. Ughhhhhh, kann mir jemand helfen oder mir einen einfachen Weg zeigen, CloudFlare mit einem S3-Bucket einzurichten, der nicht denselben Namen wie die Domain hat?

Ich habe die oben genannten StackPath-Infos ausprobiert – ich glaube, ich habe Ähnliches in CloudFlare versucht, bin mir aber nicht sicher. Es hat nicht funktioniert. Ich habe versucht, die Infos von CloudFlare darüber zu lesen, wie man einem Amazon-Bucket ein CDN hinzufügt, aber natürlich wollen sie, dass der Bucket-Name mit dem Domainnamen übereinstimmt. Mir wurde gesagt, dass das eine sehr schlechte Idee ist und ich das nicht tun kann.

Es scheint wirklich darauf hinauszulaufen:

  • Wenn der Bucket-Name mit dem Domainnamen übereinstimmt (mit einem Punkt), übernimmt Amazon S3 das alles für mich – wunderbar, toll, außer dass es Probleme mit SSL verursacht, also sollte ich das nicht tun.
  • Wenn der Bucket-Name NICHT mit dem Domainnamen übereinstimmt, wird alles massiv komplizierter und ich bringe es nicht hin.

Kann mir jemand helfen oder Rat geben? Und in der Zwischenzeit bekomme ich jeden Monat Rechnungen über 100 oder mehr für meinen S3-Speicher. Das ist so nervig. Kann ich jemandem jetzt sofort 200 zahlen, damit er das alles einfach löst? Blargh.

9

Hast du das schon gelesen? Ich hatte auch Schwierigkeiten mit der Einrichtung von S3 und Cloudflare, aber ich habe es schließlich herausgefunden. Du kannst Cloudflare weiterhin für den Sicherheitsvorteil nutzen, aber ich bin mir ziemlich sicher, dass du auch einen separaten CDN-Dienst benötigst. Cloudflare ist nicht wie ein normales CDN, es funktioniert anders. Du solltest zu einem günstigeren S3-Dienst wechseln, Amazon ist teuer.

10

Die Verwendung von Cloudflare zum Cachen eines S3-Buckets erfordert die Manipulation des Origin-Headers in den Anfragen. Diese Funktion ist im Enterprise-Plan von Cloudflare verfügbar, sodass die Nutzung eines anderen CDNs möglicherweise einfacher ist.

11

Ist der Punkt im Bucket-Namen nicht irrelevant, wenn die Bilder ohnehin über ein CDN zwischengespeichert werden? Das Einzige, was zählt, ist ein gutes Zertifikat, das die von Cloudflare ausgelieferten Bilder abdeckt.

Ich denke, er sollte sich auf Cloudflare-Server, DNS und das Zertifikat konzentrieren, das diesen Bereich abdeckt. Ich glaube nicht, dass der Benutzer oder Browser jemals wissen wird, dass die Quelle dieser Bilder ein S3-Bucket ist. Cloudflare wird das Bild selbst zwischenspeichern/proxyn, oder?

12

Discourse generiert direkte Bucket-URLs und verwendet diese für interne Vorgänge, wie etwa das „Hochladen einer Datei“. Das ist immer noch relevant.

13

@riking Alles, was Discourse zu benötigen scheint, ist ein Bucket-Name, korrekt? Das Hochladen und die Verwaltung können über AWS-URLs mit deren Zertifikaten erfolgen, falls HTTPS überhaupt erforderlich ist. Gibt es bisher einen Grund, warum wir über Sicherheitszertifikate sprechen?

Der Fragesteller (OP) kann dann separat prüfen, was er tun muss, damit sein CDN oder seine Caching-Lösung die Bilder von S3 abrufen kann. Ob dies sicher ist oder nicht, spielt keine Rolle, es sei denn, der OP oder das CDN haben Anforderungen, oder? Ist es für Discourse von Bedeutung, wie der OP die Verbindung zwischen S3 und dem CDN einrichtet?

Schließlich muss der OP sicherstellen, dass die Bilder über das CDN mit einem gültigen Zertifikat ausgeliefert werden. Hat dies etwas mit Discourse zu tun, außer dass der OP die Basis-URL für die Bilder angibt, die letztendlich dort gehostet werden? Sobald sein CDN oder Cache die Bilder von S3 abgerufen hat, sind AWS, Buckets und so weiter komplett aus dem Spiel.

Ich verstehe, dass es Probleme mit einem Punkt in S3-Bucket-Namen gibt, wenn Sie beabsichtigen, Ihre Bilder von dort aus zu liefern, aber der OP tut dies NICHT. Es kommt also nur darauf an, dass der OP einen beliebigen Bucket-Namen wählt, den Discourse akzeptiert, solange dieser nicht mit seinem Setup für das CDN kollidiert.

14

Obwohl es möglich ist, Bucket-in-Domain-URLs zu vermeiden, werden sie aufgrund der Art und Weise, wie das AWS S3 SDK verwendet wird, und der Schwierigkeit, es zu konfigurieren, tatsächlich nicht vermieden.

Auch hier umgehen diese Operationen das CDN; der einzige Weg, sie zu beheben, liegt im Quellcode von Discourse. Sie können behoben werden, werden es aber derzeit nicht. Viele der Probleme treten zudem nicht auf dem kritischen Pfad auf und zeigen sich erst später. Solange sich dies nicht ändert, verwenden Sie keine Bucket-Namen mit Punkten.

15

Also, um das auf das absolut Wesentliche herunterzubrechen: Die Frage des OP war, was genau in drei Einstellungen einzutragen ist:

(1) BUCKET NAME – wird also gesagt, dass Punkte nicht empfohlen sind? Oder gar nicht erlaubt? Ich vermute, das könnte für den OP kein Problem sein. (Er muss nur separat herausfinden, wie sein CDN Bilder cachen und ausliefern kann.) Sind wir uns hier also einig?

(2) S3 ENDPOINT – leer lassen, nichts einzutragen, wenn er AWS nutzt; ansonsten kann er den Eintrag für einen anderen Anbieter ausfüllen?

(3) S3 CDN URL – ist das einfach die Basis-URL, die Discourse dem Bildpfad voranstellen wird? Wenn ja, dann ist das einfach und unkompliziert, und der OP kann sein CDN konfigurieren und diese Basis-URL hier angeben.

Ich sehe nicht, wo SSL-Wildcard-Zertifikate hier ins Spiel kommen. Dem OP wurde gesagt, dass ein Punkt in der Discourse-Konfiguration schlecht ist, weil er sein Zertifikat beschädigt. Aber wenn er ein CDN oder einen Cache nutzt, könnte der Bucket-Name für das Zertifikat völlig irrelevant sein, oder? Falls es Discourse auf andere Weise beeinträchtigt, wäre es gut, das zu wissen.

16

Ich bin mir nicht sicher, ob ich all das so genau verstehe, aber vielleicht hilft es, das Ganze etwas zu vergrößern und diese einfachen Anforderungen zu betrachten:

Die Ziele:

  1. Meine Discourse-Bilder nicht auf meinem Discourse-Server speichern
  2. Einen S3-Bucket zum Speichern von Bildern haben (muss S3 sein, da Discourse dies unterstützt)
  3. Keine teuren S3-Gebühren haben
  4. Ein CDN ist nicht erforderlich, wäre aber ein netter Bonus, da es helfen könnte, teure S3-Gebühren zu reduzieren (oder die einzige Möglichkeit ist, sie ganz zu vermeiden) und zudem eine bessere weltweite Verfügbarkeit sowie eine Sicherung bietet, falls der Hauptserver offline geht, usw. usw.

Bitte korrigiert mich, falls etwas davon falsch ist

Einschränkungen/Anforderungen:

  1. Der externe Bildspeicher muss das S3-Protokoll unterstützen (da Discourse damit arbeitet), muss aber streng genommen nicht Amazons S3 sein.
  2. Discourse verlangt, dass der S3-Bucket-Name keine Punkte enthält.
  3. Die Bildquelle (S3 oder CDN) muss HTTPS bereitstellen, da ein Browser Probleme meldet, wenn die Seite HTTPS ist, die Bilder aber nicht.

Bitte korrigiert mich, falls etwas davon falsch ist

Lösungen:

Früher habe ich die Bilder direkt von Amazon S3 bereitgestellt. Das hat super funktioniert, außer dass die Gebühren von Amazon für DataTransfer-Out-Bytes extrem teuer sind. Das führte zu hohen monatlichen Rechnungen von Amazon! Deshalb habe ich es wieder auf den Hauptserver verlagert. Zwei mögliche Lösungen dafür: Ein CDN vor dem Amazon S3-Bucket platzieren, sodass das CDN den gesamten Datentransfer übernimmt, und/oder zu einem anderen S3-Anbieter wechseln.

Ich habe versucht, das CloudFlare-CDN vor dem Amazon S3-Bucket zu platzieren, stieß aber sehr schnell auf viele Probleme, die ich nicht lösen konnte.

Eine andere Option?

Ich habe gerade dieses S3-kompatible Speicherangebot von Digital Ocean angesehen. [DigitalOcean Spaces | S3-Compatible Object Storage]. Eingebautes CDN (ich bin mir nicht genau sicher, was das bedeutet, aber es klingt vielversprechend), günstige Preise. Würde das mit Discourse funktionieren?

Zur Information: In den letzten 30 Tagen habe ich etwa 300 GB von S3 bereitgestellt. Ein Teil davon sind Sicherungen der Website, ein großer Teil sind statische Bilder. Es ist für mich sehr schwierig herauszufinden, wie man diese Dinge bei Amazon misst… deren Rechnungsstellungs-Interface – wie alles andere bei Amazon AWS auch – ist für die Verwaltung wirklich verwirrend.

17

Ich bin der Meinung, dass die einfachste Lösung AWS und KeyCDN ist, wobei die Richtlinien unter Verwendung von Object Storage für Uploads (S3 & Clones) befolgt werden. Wenn Ihre Nutzer nicht in Südamerika sind, ist KeyCDN recht günstig und einfach zu konfigurieren.

Eine potenziell kostengünstigere Lösung könnte Einrichtung von BackBlaze S3 mit BunnyCDN sein. Bei meinen ersten Tests für Backups war ich mit BackBlaze zufrieden, habe es aber noch nicht für Uploads ausprobiert.

18

Wir haben uns wild über einen Punkt im Bucket-Namen und Browser-Zertifikate ablenken lassen, aber ich denke, all diese Diskussion ist völlig irrelevant. JEDE CDN-Lösung wird eine HTTPS-Konfiguration ermöglichen, sodass es KEIN PROBLEM mit dem „Wildcard-Zertifikat

19

P.S. Dieses Thema, das @pfaffman oben hilfreich verlinkt hat, weist darauf hin, dass Digital Oceans S3-Produkt („Spaces“) ein „extrem fehlerhaftes“ CDN hat.

Und ich sehe, dass bei anderen S3-Anbietern verschiedene Einstellungen angepasst werden müssen.

Das sagt mir:

  • Die Einstellungen variieren von Anbieter zu Anbieter, selbst wenn alle behaupten, das „S3“-Protokoll zu befolgen.
20

Immer noch

:warning: Setzen Sie KEINEN Punkt in Ihren Bucket-Namen

Ich meine, es sei denn, Sie lieben es zu leiden.