Ich konnte nicht herausfinden, warum unsere Installation mit dem neuesten Update keine Assets mehr über das CDN ausliefert. Wir nutzen Cloudfront, und es funktionierte bisher einwandfrei sowohl für Uploads als auch für Assets. Es scheint jedoch, dass im neuesten Update Assets stattdessen direkt vom Server ausgeliefert werden.
Ein weiteres Problem, das wir haben, ist folgendes: Wenn wir die Variable DISCOURSE_CDN_URL übergeben, fordert Discourse Assets an, die nicht durch die Aufgabe s3:upload_assets generiert oder hochgeladen wurden (z. B. Stylesheets). Dadurch bricht die gesamte Seite mit einer weißen Seite zusammen. Dieser Beitrag erwähnt etwas Ähnliches:
Ich habe DISCOURSE_CDN_URL entfernt, das auf denselben Wert wie DISCOURSE_S3_CDN_URL gesetzt war, da dies die Seite zerstörte (es versuchte, Assets von S3 zu laden, die dort nicht existierten).
Als ich auf die Website zurückblickte, bei der ich Probleme hatte, stellte sich heraus, dass ich die https://-Angabe in der von mir verwendeten CDN-URL vergessen hatte. Mir ist nicht klar, wie es jemals funktioniert haben könnte oder, falls es nie funktioniert hat, wie ich das nicht bemerkt habe, als ich den fehlerhaften Wert hinzugefügt habe.
@eatcodetravel, du musst natürlich SMTP-Passwörter und S3-Schlüssel schwärzen, aber ich denke, du musst zumindest die CDN-Werte teilen, damit jemand überhaupt eine Ahnung davon bekommt, was das Problem sein könnte.
Ja, ich musste DISCOURSE_CDN_URL entfernen. Es wurden plötzlich Assets abgerufen, die vom rake s3:upload_assets-Task nicht auf S3 hochgeladen wurden, was die Seite komplett lahmlegt. Vielleicht hat sich genau dieser Teil geändert, und wir müssen rake s3:upload_assets aktualisieren, damit es wieder korrekt funktioniert.
Ja, es ist möglich, dieselbe CDN-URL sowohl für DISCOURSE_CDN_URL als auch für DISCOURSE_S3_CDN_URL zu verwenden, aber dies erfordert eine große Anzahl von Anmeldungen beim CDN, um die richtige Quelle für jedes Asset basierend auf der URL zu verwenden. Zum Beispiel stammt CSS aus der App und JS aus S3 – das ist nur ein Fall, wir haben Dutzende.
Die Erwartung ist daher, dass Sie beide konfigurieren, wobei DISCOURSE_CDN_URL ein „Proxy
Ah okay, hat sich das kürzlich geändert? Ich bin mir nicht sicher, ob CloudFront als Reverse-Proxy für unsere App anstelle eines S3-Buckets unterstützt wird. Ich sehe, dass du CloudFront in meta verwendest. Gibt es etwas Besonderes, das du tun musst, um es laufen zu lassen, oder kümmert sich Discourse selbst um alles?
Wenn Sie diese Seite inspizieren, werden Sie feststellen, dass wir zwei verschiedene Cloudfront-URLs haben. Wir nutzen daher das, was ich oben erwähnt habe: zwei Distributionen, eine für das normale CDN und eine weitere für S3.
Das Problem aus dem Titel des OP ist folgendes: CSS kommt von der App und JS von S3. Sie benötigen ein CDN, das weiß, von wo jedes einzelne Asset stammt, und den entsprechenden Ort erreichen kann, oder zwei CDNs. Deshalb haben wir schließlich zwei verschiedene Einstellungen.
Obwohl das jetzt, wo ich es verstehe, total Sinn ergibt, bin ich mir nicht sicher, ob das dokumentiert ist. Und du wirst wahrscheinlich Ärger bekommen (zumindest ich!), da der Rake-Auftrag zum Verschieben von Uploads nach S3 voraussetzt, dass du ein s3_cdn hast. Das erklärt, warum ich mehrmals versucht habe, Dinge nach S3 zu verschieben und am Ende aufgegeben habe.
Ich fände es schön, wenn es irgendwo eine Warnung gäbe wie: „Alter, du kannst kein S3-CDN ohne Asset-CDN haben.
Okay, jetzt verstehe ich, was du meinst. Ich wusste nicht, dass dies erforderlich ist. Darf ich fragen, warum CSS aus der App kommen muss? Warum können wir es nicht über die rake s3:upload_assets-Aufgabe hochladen?
Ich werde etwas recherchieren, wie man dies auf Cloudfront umsetzt, und meine Erkenntnisse/Blockaden hier veröffentlichen.
[quote=“pfaffman, Beitrag: 15, Thema: 140705”]
Ich finde es wäre schön, wenn es irgendwo eine Warnung gäbe: „Kumpel, du kannst kein S3-CDN ohne Asset-CDN haben.
Ich habe das Problem schließlich gelöst, indem ich eine zweite Cloudfront-Distribution bereitgestellt habe, die auf den Webserver zeigt, und die andere nur für S3 belassen habe. Danke @Falco für das Feedback, aber ich stimme zu, dass dies etwas besser dokumentiert werden muss.
s