Dies sind die Variablen, die wir im Zusammenhang mit S3/CDN setzen:
DISCOURSE_CDN_URL
DISCOURSE_S3_ACCESS_KEY_ID
DISCOURSE_S3_BACKUP_BUCKET
DISCOURSE_S3_CDN_URL
DISCOURSE_S3_REGION
DISCOURSE_S3_SECRET_ACCESS_KEY
DISCOURSE_S3_UPLOAD_BUCKET
USE_DB_S3_CONFIG: true
Ich denke, DISCOURSE_S3_BUCKET wurde zugunsten von DISCOURSE_S3_UPLOAD_BUCKET und DISCOURSE_S3_BACKUP_BUCKET veraltet. Du solltest stattdessen diese setzen.
Das habe ich angenommen, aber ich komme nicht weiter, es sei denn, ich setze sowohl DISCOURSE_S3_UPLOAD_BUCKET als auch DISCOURSE_S3_BUCKET. Wie Sie dem oben geposteten Code-Ausschnitt entnehmen können, sucht use_s3? weiterhin nach s3_bucket und nicht nach s3_upload_bucket.
Das Setzen von DISCOURSE_BACKUP_BUCKET löst das Problem meines Erachtens nicht.
Wenn ich beide Bucket-Umgebungsvariablen setze, komme ich einen Schritt weiter, aber nun bin ich auf ein neues Problem gestoßen: Discourse ignoriert meine S3-CDN-URL und versucht, Assets von meinem Basispfad zu laden. Dies führt zu CSP-Fehlern, da die Content Security Policy nur den Asset-Pfad von meiner S3-CDN enthält.
Es sollte DISCOURSE_S3_BACKUP_BUCKET statt DISCOURSE_BACKUP_BUCKET sein. Abgesehen davon sollte es funktionieren, wenn Sie alle Variablen mit den beiden Cloudfront-Distributionen setzen. Wenn Sie unsere Einstellungen ansehen, definieren wir DISCOURSE_S3_BUCKET nicht.
Ich bin mir nicht sicher, ob auch ein Re-Bake erforderlich ist.
@Falco Soweit ich mich erinnere, ist eines der Dinge, das hier sehr kontraintuitiv wirkt, der Unterschied im Verhalten, wenn DISCOURSE_S3_CDN_URL als Umgebungsvariable oder GlobalSetting gesetzt wird, im Vergleich zur Konfiguration als SiteSetting. Vielleicht solltest du das in deinem howto beachten.
Ja, entschuldige, das war ein Tippfehler in meinem vorherigen Beitrag. DISCOURSE_S3_BACKUP_BUCKET setzt für mich s3_bucket nicht in GlobalSetting. Ich bin mir nicht sicher, wie du diesen Rake-Auftrag ausführen kannst, ohne DISCOURSE_S3_BUCKET zu setzen.
Ich schätze deine Hilfe übrigens sehr und verstehe, dass dies nicht dein Problem zu lösen ist, also danke.
def ensure_s3_configured!
unless GlobalSetting.use_s3? || use_db_s3_config
STDERR.puts "FEHLER: Stellen Sie sicher, dass S3 in config/discourse.conf oder in Umgebungsvariablen konfiguriert ist"
exit 1
end
end
use_db_s3_config erspart Ihnen das Setzen dieser zusätzlichen Variable. Das muss ein Fehler in global_setting.rb sein, denn ich sollte einfach DISCOURSE_S3_UPLOAD_BUCKET setzen können, es sei denn, es gibt einen Unterschied zwischen diesem und DISCOURSE_S3_BUCKET. Ich denke jedoch, dass Sie recht haben, dass letzterer veraltet sein soll.
Unabhängig von einem Fehler in global_setting.rb sehe ich weiterhin ein Problem, bei dem Discourse nach Assets am üblichen Ort sucht und nicht auf meinem S3-CDN, obwohl ich alle Variablen deklariert habe und DISCOURSE_ENABLE_S3_UPLOADS auf true gesetzt ist.
Es gibt eine Aufgabe dafür: bundle exec rake uploads:migrate_to_s3. Sobald Sie Ihre Buckets konfiguriert haben, sollten Sie diese Aufgabe ausführen, um die Uploads zu S3 zu verschieben. S3/CDN hat sich in den letzten Monaten geändert, und die Dokumentation ist nicht auf dem neuesten Stand. Stellen Sie daher sicher, dass Sie ein Backup erstellen und sich vorbereiten, falls etwas schiefgeht.
Als ich dies zum ersten Mal aktiviert habe, hatten wir eine kurze Ausfallzeit, während wir alles herausfanden.
Ich vermute, das liegt daran, dass dir DISCOURSE_CDN_URL fehlt. In unserer Konfiguration ist es wie folgt:
DISCOURSE_CDN_URL: 'https://d16zv78c963s69.cloudfront.net' # zeigt auf den Server
DISCOURSE_S3_CDN_URL: 'https://community-cdn-prod.debtcollective.org' # zeigt auf den S3-Bucket
Stylesheets werden vom Server abgerufen, daher wird DISCOURSE_CDN_URL verwendet. JavaScript wird in den S3-Bucket hochgeladen und nutzt DISCOURSE_S3_CDN_URL. @Falco hat mir das hier erklärt:
Ja, das habe ich gesehen. Ich habe DISCOURSE_CDN_URL gesetzt, aber das Problem besteht weiterhin. Allerdings bin ich müde, also habe ich vielleicht bei dem ganzen Herumprobieren etwas übersehen. Ich mache morgen weiter. Danke für die Hilfe.
Wird dies sowohl Bilder als auch Assets als JS-Dateien in S3 hochladen? Und sollte ich eine CloudFront-URL verwenden oder reicht S3 aus? Danke für deine Hilfe.
bundle exec rake uploads:migrate_to_s3 lädt nur Anhänge in S3 hoch. Diese Aufgabe muss einmalig ausgeführt werden. Sobald Sie S3 aktiviert haben, werden neue Uploads in den S3-Buckets gespeichert.
Um Assets hochzuladen, müssen Sie bundle exec rake s3:upload_assets verwenden. Dies muss nach jedem Rebuild oder Upgrade ausgeführt werden.
Ich habe getan, was du erwähnt hast, und die Uploads nach S3 (Bilder usw.) waren erfolgreich, aber bei Assets erhalte ich folgenden Fehler:
ERROR: Ensure S3 is configured in config/discourse.conf or environment vars
Ich habe beide gesetzt:
DISCOURSE_CDN_URL: 'https://d16zv78c963s69.cloudfront.net' # zeigt auf den Server
DISCOURSE_S3_CDN_URL: 'https://community-cdn-prod.debtcollective.org' # zeigt auf den S3-Bucket
Es gibt ein interessantes Problem: Discourse versucht, Asset-Dateien von einem falschen Pfad abzurufen. Es versucht, sie vom brotli_asset-Pfad abzurufen, aber dieser Pfad existiert nicht im S3-Bucket.
Außerdem versucht es, JavaScript- und Stylesheet-Dateien von der CDN-URL abzurufen. Diese Dateien sind jedoch ebenfalls nicht im Bucket vorhanden.
Wenn ich die Daten im Admin-Bereich auf S3 setze, funktioniert alles einwandfrei und alles wird auf S3 hochgeladen. Ich habe keine Einstellungen in ENV. Ist das schlecht? Ist es notwendig, wenn alles funktioniert?
Das zweite Beispiel ist anders, weil ich die alten Daten nicht auf S3 migrieren kann (nur neue funktionieren). Aber hier ändert das Eingeben dieser Daten in der Datei app.yml (DISCOURSE_S3_ACCESS_KEY_ID: ‘key’ usw.) nichts, und es funktioniert immer noch nicht (d.h.
. Das hat das Problem behoben.
