Kann Uploads nicht zu S3 migrieren

Hallo, wir haben das Upload-Hosting (mit den S3-Einstellungen) auf Backblaze eingerichtet.
Neue Uploads funktionieren (nach der Korrektur des x-amz-checksum-crc32-Headers), aber der Versuch, bestehende Uploads mit uploads:migrate_to_s3 zu migrieren, schlägt sofort fehl.

Dies geschieht auf der neuesten Discourse-Version (3.5.0.beta5-dev).
Hier ist die vollständige Ausgabe:

root@goactuary-app:/var/www/discourse# rake uploads:migrate_to_s3 --trace
** Invoke uploads:migrate_to_s3 (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute uploads:migrate_to_s3
Bitte beachten Sie, dass die Migration zu S3 derzeit nicht rückgängig gemacht werden kann!
[CTRL+c] zum Abbrechen, [ENTER] zum Fortfahren

Migrating uploads to S3 for 'default'...
Einige Uploads wurden nicht in das neue Schema migriert. Wenn Sie die Migration ausführen, kann dies eine Weile dauern...
rake aborted!
FileStore::ToS3MigrationError: Einige Uploads konnten nicht in das neue Schema migriert werden. Sie müssen dies manuell beheben. (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-6.1.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-6.1.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-6.1.0/lib/rails_multisite/connection_management.rb:21: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>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:281:in `block in execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:281:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:281:in `execute'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:199:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:199:in `invoke_with_call_chain'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/task.rb:188:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:188:in `invoke_task'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:138:in `block (2 levels) in top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:138:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:138:in `block in top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:147:in `run_with_threads'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:132:in `top_level'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:83:in `block in run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:214:in `standard_exception_handling'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.2.1/lib/rake/application.rb:80:in `run'
bin/rake:13:in `<top (required)>'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in `load'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:59:in `kernel_load'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli/exec.rb:23:in `run'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:452:in `exec'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor.rb:538:in `dispatch'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:35:in `dispatch'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/cli.rb:29:in `start'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:28:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.3.0/gems/bundler-2.6.4/exe/bundle:20:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3

Sie müssen sie in Ihre app.yml einfügen, wie unter Konfigurieren eines S3-kompatiblen Objektspeichers für Uploads beschrieben.

Meinen Sie, dass Sie Code zu Ihrer app.yml hinzugefügt haben, um die AWS-Bibliothek auf eine Version zurückzusetzen, die mit Backblaze funktioniert?

2 „Gefällt mir“

Ja, sie sind in app.yml und ich habe die App neu erstellt.
Ich habe bestätigt, dass neu hochgeladene Dateien dorthin gelangen.

Nicht ganz. Ich verwende die folgenden Umgebungsvariablen:

  AWS_REQUEST_CHECKSUM_CALCULATION: WHEN_REQUIRED
  AWS_RESPONSE_CHECKSUM_VALIDATION: WHEN_REQUIRED

Diese haben das Problem behoben, dass nach der Änderung der Einstellungen keine neuen Dateien mehr hochgeladen werden konnten.

Sie müssen diese wahrscheinlich selbst aufspüren.

In Rails können Sie

 Upload.pluck(:url)

und dann nachsehen, welche Uploads das Problem sind.

Ich glaube, nach meiner Erfahrung war das nicht genug, aber Sie sagen, es funktioniert für Sie.

2 „Gefällt mir“

Das manuelle Downgraden der aws-Gems im Container hat dazu geführt, dass der uploads:migrate_to_s3-Job tatsächlich Bilder hochgeladen hat. Anscheinend reichten die Umgebungsvariablen nicht aus, wie Sie angemerkt haben.

Der Prozess ist jedoch später an einem anderen Punkt fehlgeschlagen:

FileStore::ToS3MigrationError: 2 Posts sind nicht auf die neue S3-Upload-URL abgebildet. S3-Migration fehlgeschlagen für DB 'default'. (FileStore::ToS3MigrationError)

Das wird ein separates Fehlerbehebungsabenteuer.

1 „Gefällt mir“

Das liegt vielleicht daran, dass Sie eine Box haben, die sich auf lokale Beiträge bezieht. Ich habe dazu ein Thema erstellt, erinnere mich aber nicht mehr genau an die Details.

Wenn es nur 2 sind, können Sie sie vielleicht einfach ignorieren, aber in Rails können Sie alle Uploads finden, die Ihren neuen Bucket nicht enthalten. Ich glaube, das wird leer sein?

Ich glaube, das Problem ist, dass Sie zwei Beiträge haben, die einen unerwarteten Pfad im “cooked post” haben.

Ich habe es gefunden!
Kann kein Backup wiederherstellen, wenn es einen Link zu Discourse Onebox enthält

Bearbeiten: Ich glaube also, Sie haben zwei Beiträge mit lokalen Oneboxen. Ich denke, Sie müssen diese Beiträge nur finden und neu backen.

1 „Gefällt mir“

@stanski, hat das Ihr Problem gelöst?

1 „Gefällt mir“

Entschuldigung, ich war beschäftigt und habe vergessen, dies zu aktualisieren.
Nach dem erneuten Backen aller Beiträge erhielt ich eine andere Fehlermeldung, als ich die Migration erneut versuchte.
Ich kann den Backtrace leider nicht mehr finden.

Ich habe festgestellt, dass trotz des Fehlers Uploads anscheinend zu Backblaze migriert und die Beiträge aktualisiert wurden.
Ich habe die lokalen Uploads archiviert und sie woandershin verschoben und seitdem keine Beschwerden mehr gehört.

Zusammenfassend lässt sich sagen, ja, mein Problem wurde behoben.
Danke an @pfaffman für die fortlaufenden Vorschläge.

Jetzt habe ich eine Beschwerde, dass verschiedene Firewalls von Backblaze gehostete Uploads blockieren, aber das ist eine andere Sache.

Ich denke, Sie möchten wirklich ein CDN verwenden.

1 „Gefällt mir“