Probleme mit AWS CDN und S3

,

@Falco Ist das immer noch der Fall? Ich dachte, ich hätte etwas über aktuelle Probleme mit AWS gelesen, aber ich kann das Thema nicht wiederfinden.

Ich habe zahlreiche Probleme bei der Verwendung von AWS S3, wobei ich die verschiedenen relevanten Themen als Leitfaden verwende.

Backups funktionieren wie erwartet, aber die Verwendung von Cloudfront als CDN oder das Auskommentieren von DISCOURSE_USE_S3 und/oder DISCOURSE_S3_BUCKET führt zu einem ständigen Ladekreis (Throbber).

Ich vermute, dass ich etwas im Upload-Bucket und/oder in der Cloudfront-Verteilung falsch konfiguriert habe, konnte aber keinen Fehler finden. Sowohl der Upload- als auch der Backup-Bucket befinden sich hinter der Verteilung und Backups funktionieren einwandfrei, also???

discourse-cdn.repealobbba.org CNAME —> amazonassigned.cloudfront.net

DISCOURSE_CDN_URL: https://discourse-cdn.repealobbba.org

## S3 Speicher-Konfiguration
#  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_ACCESS_KEY_ID: ACCESS_KEY_ID
  DISCOURSE_S3_SECRET_ACCESS_KEY: SECRET_ACCESS_KEY
  DISCOURSE_S3_CDN_URL: amazonassigned.cloudfront.net  oder
#  DISCOURSE_S3_BUCKET: repeal-obbba-discuss-uploads
  DISCOURSE_S3_BACKUP_BUCKET: repeal-obbba-discuss-backups
  DISCOURSE_BACKUP_LOCATION: s3

Zusätzlich führt das Hinzufügen von Folgendem zur Konfiguration

    after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

zu der Fehlermeldung FEHLER BEIM BOOTSTRAPPING

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets fehlgeschlagen mit Rückgabe #<Process::Status: pid 8484 exit 1>
Ort des Fehlschlags: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.3.0/lib/pups/exec_command.rb:131:in `spawn'
exec fehlgeschlagen mit den Parametern {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets", "sudo -E -u discourse bundle exec rake s3:expire_missing_assets"]}
bootstrap fehlgeschlagen mit Exit-Code 1
** FEHLER BEIM BOOTSTRAP ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.

wie immer… Jede Idee oder jeder Vorschlag wäre willkommen.

Sie müssen den Abschnitt hinzufügen, der Assets auf S3 hochlädt.

Oh. Ich irre mich, Sie machen es ja.

Das deutet darauf hin, dass mit der Bucket-Konfiguration etwas nicht stimmt.

Ich glaube, es gab früher ein Thema, das das JSON zur Konfiguration eines Buckets generiert hat, aber ich weiß nicht, ob es noch existiert.

1 „Gefällt mir“

Zustimmung
Obwohl für den Backups-Bucket keine Bucket-Richtlinie verwendet wurde, hat das Hinzufügen einer Richtlinie zum Uploads-Bucket den Bootstrap-Fehler behoben.
Die Richtlinien-JSON ist verfügbar unter CloudFront>Distributionen>Ihre Distribution>Ursprung bearbeiten
Screenshot 2025-12-10 141220

Leider bleibt der ständige Ladekreis bestehen.
Das Anpassen des Objektbesitzes und der ACLs ändert das Ergebnis nicht.
Screenshot 2025-12-10 141936

Aktuelle Einstellungen. Ich glaube, es sind die empfohlenen Einstellungen, oder ich bin vielleicht verwirrt.
Screenshot 2025-12-10 141702
Screenshot 2025-12-10 141835

Nachdem Sie die Einstellungen geändert haben, müssen Sie den Rant-Task ausführen, um die Assets hochzuladen.

Außerdem können Sie die Entwicklerkonsole öffnen und prüfen, ob die Dateien, auf die zugegriffen werden soll, im Bucket vorhanden sind oder ob es ein Problem mit dem CDN gibt.

1 „Gefällt mir“

Danke für die Fortsetzung…

Ja, die rake-Aufgaben werden ausgeführt, macht keinen Unterschied.

./launcher enter app
rake posts:rebake
rake uploads:migrate_to_s3
rake posts:rebake_uncooked_posts

Der Throbber bleibt bestehen.

rake uploads:migrate_to_s3 liefert einen Fehler

Migrating uploads to S3 for 'default'...
Some uploads were not migrated to the new scheme. Running the migration, this may take a while...
rake aborted!
FileStore::ToS3MigrationError: Some uploads could not be migrated to the new scheme. You need to fix this manually. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management.rb:17:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3

Mindestens ein CDN-Prüfer zeigt discourse-cdn.repealobbba.org ->Amazon CloudFront

und die Konsole zeigt immer noch an, dass Bilder und JS-Dateien von der CDN aufgerufen werden
Screenshot 2025-12-10 192413

Die Assets werden von der cdn aufgerufen, aber sind sie dort? Wenn nicht, sind sie im Bucket? Sind sie vom Bucket aus zugänglich?

Wahrscheinlich haben Sie einige Uploads in einem anderen Bucket oder etwas, das verhindert, dass sie sich am erwarteten Ort befinden. Wenn ja, müssen Sie diese manuell korrigieren, wie es heißt. Sie müssen auf die Konsole zugreifen und sehen, wo sie sich im Upload-Datensatz befinden.

Scheint die Aufgabe zum Hochladen von Assets zu funktionieren? Der Throbber läuft weiter, weil die anderen Assets nicht geladen werden.

2 „Gefällt mir“

Ja, sie sind da, Dateien sind im Bucket unter assets\nZugänglich: https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com/assets/logo-815195ae.png

Nur zwei Buckets, uploads und backups. Backups funktionieren einwandfrei.

rake s3:upload_assets gab den Fehler:
rake aborted!
Aws::S3::Errors::AccessControlListNotSupported: Der Bucket erlaubt keine ACLs (Aws::S3::Errors::AccessControlListNotSupported)

Auf ACLs aktiviert umgestellt und s3:upload_assets edit: uploads:migrate_to_s3 erneut ausgeführt, aber…
FileStore::ToS3MigrationError: Einige Uploads konnten nicht in das neue Schema migriert werden. Sie müssen dies manuell beheben. (FileStore::ToS3MigrationError)

??? Sie müssen dies manuell beheben. (FileStore::ToS3MigrationError)

Es scheint, als hätten Sie den Bucket repariert und er kann nun Assets hochladen, sodass die Seite jetzt funktionieren sollte. Sich mit den Uploads zu befassen, die nicht migriert werden können, ist ein anderes (kompliziertes) Problem.

Hier ist eines der Assets, das Sie zu servieren versuchen:

https://discourse-cdn.repealobbba.org/assets/start-discourse-6f03a463.br.js

Das Zertifikat ist fehlerhaft, das ist also Ihr Problem. Es gibt zwar ein Zertifikat, aber es stimmt nicht mit der URL überein.

Wie ich bereits vorgeschlagen habe, schauen Sie sich den Netzwerk-Tab der Entwicklertools in Ihrem Browser an und sehen Sie Folgendes:

1 „Gefällt mir“

edit von oben
Auf ACLs aktiviert umgestellt und s3:upload_assets edit: uploads:migrate_to_s3 erneut ausgeführt

s3:upload_assets schließt jetzt ohne Probleme ab

Ich sehe die Netzwerkfehler. Ist das Zertifikat ein AWS-Problem?

Vielen Dank nochmals für Ihre Zeit!

Ja. Das Zertifikat stimmt nicht mit dem Hostnamen überein. Es stimmt mit *.cloudfront.net überein.

Das funktioniert: https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com/assets/logo-815195ae.png

Das funktioniert nicht: https://discourse-cdn.repealobbba.org/assets/start-discourse-6f03a463.br.js

Das funktioniert: https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com/assets/start-discourse-6f03a463.br.js

Sie müssen also Ihr S3-CDN auf https://repeal-obbba-discuss-uploads.s3.us-east-1.amazonaws.com umstellen – oh, ich schätze, das ist die Bucket-Adresse, also wäre das nicht ideal, aber es würde funktionieren.

1 „Gefällt mir“

Nicht so begeistert von „also wäre das nicht ideal“ :wink:

Ich schaue mir die AWS-Alternativ-Domainnamen als mögliche Lösung an.

Vielleicht bilde ich es mir nur ein, aber das Hinzufügen eines CDNs, das @Discourse intern verwendet, sollte vielleicht nicht so schwierig sein und nicht die freundliche Unterstützung von Leuten wie @pfaffman erfordern.

Vielleicht können @Falco oder @sam und @team (kann Team nicht erwähnen) sich äußern??

Ja, alle von uns gehosteten Seiten verwenden die S3-plus-CloudFront-Kombination. Sogar diese Seite, die Sie gerade ansehen.

2 „Gefällt mir“

Danke für die Bestätigung! Nachdem ich das gesehen hatte, habe ich DISCOURSE_S3_CDN_URL wieder auf amazonassigned.cloudfront.net zurückgestellt, in der Hoffnung, dass dies die Zertifikats- und URL-Probleme behebt.
Screenshot 2025-12-11 133250

Ich habe alles neu erstellt und alle in der Dokumentation erwähnten Rakes erneut ausgeführt.
rake posts:rebake
rake uploads:migrate_to_s3 erzeugt immer noch FileStore::ToS3MigrationError
rake posts:rebake_uncooked_posts

rake s3:upload_assets
rake s3:expire_missing_assets

Immer noch kein Erfolg beim Laden der Seite.

Irgendwelche Vorschläge?

Das hat sich als hilfreich erwiesen.
Screenshot 2025-12-12 001849

@chapoi, bitte teilen Sie diesen Thread zur Unterstützung auf.
Vielleicht hat @JammyDodger ihn zu Installation verschoben, um eine bessere Sichtbarkeit zu erzielen, obwohl das Forum seit vielen Monaten einwandfrei läuft.

Auf jeden Fall vielen Dank für Ihre Aufmerksamkeit!

Die Installation dient nicht nur der Einrichtung des Forums

1 „Gefällt mir“

Verstanden, danke für die Klarstellung.

1 „Gefällt mir“

Wie oben erwähnt, fügen Sie eine alternative Domain help hinzu.
Die Seite wird geladen, aber ohne Stylesheets und…

Wenn ich im Bucket nachsehe, sehe ich keinen Ordner stylesheets/

Screenshot 2025-12-12 120937

Scheint, als wäre s3:upload_assets unvollständig.

Und gibt es ein CORS-Problem?
Screenshot 2025-12-12 121734

Nachdem ich ein paar Dinge in der Dokumentation verstanden habe, die entweder irreführend, verwirrend oder einfach zu viel für jemanden mit BBS waren, mache ich Fortschritte :distorted_face:

Für uns BBS-Leute würde es helfen, wenn dies in leuchtendem Rot hervorgehoben würde: „Sie benötigen zwei Cloudfront-Distributionen“.

und einige Anweisungen, wie man

Einige Aktualisierungen und Konsolidierungen von S3-bezogenen Themen wären sehr willkommen. Ich denke, ein Hauptthema mit aktuellen Daten für AWS S3 CDN und Backups wäre großartig.

weiter geht’s…

Ich habe jetzt zwei Cloudfront-Distributionen, aber:

Alle Rakes werden ohne Fehler ausgeführt und
und dies führt nicht mehr zu einem Bootstrap-Fehler.

after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets
          - sudo -E -u discourse bundle exec rake s3:expire_missing_assets

Der CDN-Checker sieht eher nach einem wünschenswerten Ergebnis aus
Screenshot 2025-12-14 004220

Alles in allem Fortschritte, aber ein paar Tipps vom Discourse-Infrastrukturteam wären sehr hilfreich.

Puh! Es hat eine Menge Zeit und einige Stunden (8 über 2 Anrufe) mit einem sehr hilfsbereiten Amazon-Ingenieur gekostet, aber ich glaube, ich habe das jetzt verstanden. Die Dinge funktionieren großartig auf der RepealOBBBA-Website und mein Prozess ist auf andere Websites übertragbar.

Ich werde das vielleicht noch aufschreiben, aber hier sind ein paar Notizen für den Moment:

  1. DISCOURSE_CDN_URL (wenn AWS S3 verwendet wird) und DISCOURSE_S3_CDN_URL benötigen ihre eigenen Cloudfront-Distributionen.
  2. DISCOURSE_CDN_URL verwendet keinen Bucket.
  3. DISCOURSE_CDN_URL kann ein Nicht-AWS-CDN sein. Bunny.net funktioniert großartig. (Mir wurde gesagt, dass Bunny Storage mit S3-Unterstützung im 1. Quartal 2026 erscheinen soll)
  4. Die CDNs von DISCOURSE_CDN_URL und DISCOURSE_S3_CDN_URL können gebrandete URLs mit der entsprechenden DNS-Konfiguration sein.
  5. DISCOURSE_S3_CDN_URL erfordert einen Uploads-Bucket.
  6. Der Uploads-Bucket erfordert aktivierte ACLs und „Jeder (öffentlicher Zugriff)“ auf „Lesen“ eingestellt, und Sie müssen eine Richtlinie für den Bucket festlegen.
  7. Der Backups-Bucket erfordert keine ACLs oder Richtlinien.

Bearbeitung(en)

  1. Aktivieren Sie das Kontrollkästchen in S3 „CDN-URL für alle Uploads verwenden“: Verwenden Sie die CDN-URL für alle Dateien, die in S3 hochgeladen werden, anstatt nur für Bilder. Das Nicht-Aktivieren verursachte bei mir immer wieder Fehler.

Ich stelle mir vor, dass viele das oben Gelesene lesen und denken: duhhh Phil, das ist doch offensichtlich, aber… mein BBS-Verstand hat es nicht sofort begriffen.

1 „Gefällt mir“