Настройка провайдера объектного хранилища, совместимого с S3, для загрузки файлов

Документация Самостоятельный хостинг
, , ,
415

@Falco — Стоит добавить предупреждение для Scaleway: она поддерживает только 1000 частей при многочастной загрузке, тогда как AWS поддерживает 10 000. Для обычных загрузок это не проблема, но при резервном копировании файлов определённого размера возникает проблема, так как S3 SDK использует 10 000 частей, если их количество не изменено вручную, что приводит к ошибке.

4 лайка
416

Отличное открытие! Если можете, добавьте его в OP-вики.

4 лайка
417

Спасибо. Также хочу добавить, что вы можете использовать любой из этих инструментов для копирования между облачными хранилищами, особенно в/из совместимых с S3 объектных хранилищ, например, Rclone, Shargate, Gs Richcopy360 и GoodSync. Все они совместимы с аналогичными облачными платформами.

1 лайк
418

Мы только что обнаружили проблему: Cloudflare R2 не разрешает публичный доступ (public-read) через URL конечной точки S3, поддерживается только доступ через пользовательский домен или случайный домен r2.dev.
(Скачивания по предподписанным ссылкам работают, но прямой публичный доступ не поддерживается.)
Однако Discourse использует URL CDN только для встроенных изображений, а не для прямых загрузок, которые используют URL конечной точки S3.
Есть ли способ заставить его использовать URL CDN для всех файлов или принудительно применять предподписанные URL?

Связано:

Упомянутый в том сообщении обходной путь работает: добавление ?dl=1 исправляет проблему, так как это заставляет Discourse использовать предподписанный URL S3.

1 лайк
419

Исправлено в 2023-03-16. Теперь R2 работает с Discourse как по маслу даже в бесплатном тарифном плане.

3 лайка
420

Я тоже сталкиваюсь с этим довольно часто (раз в несколько месяцев), даже несмотря на то, что мой Discourse работает в AWS Lightsail, а резервные копии загружаются в AWS S3. Поэтому я не уверен, что проблема в Wasabi.

Возможно ли перехватывать эту ошибку и отправлять уведомление администратору? Я проверяю свободное место на диске и удаляю старые резервные копии при обновлении, но иногда это происходит слишком поздно, и форум перестаёт работать из-за нехватки места на диске.

1 лайк
Notification when uploading backup to cloud storage fails
421

Я почти уверен, что проблема заключалась в том, что автоматические перезагрузки ОС для установки обновлений безопасности происходили во время выполнения резервного копирования. Убедитесь, что вы запланировали перезагрузки ОС и резервное копирование в разное время. Я пришел к этому объяснению уже после того, как перенес этот сайт с Wasabi, но я вполне уверен, что дело именно в этом.

2 лайка
422

uptime показывает, что система работает уже 300 дней, так что, думаю, дело не в этом. Но, по аналогии, у меня были запланированы резервные копии Discourse в 2:00 ночи, а снимки Lightsail — в 2:30 ночи. Возможно, иногда загрузка не успевает завершиться, и снимок вносит помехи. Я разнес эти две операции на час — посмотрим, поможет ли это.

В любом случае, считаю разумным предупреждать администраторов в случае сбоя загрузки, по какой бы то ни было причине.

2 лайка
423

Думаю, пришло время обновить ядро и перезагрузить систему. :slight_smile:

Возможно, у вас заканчивается оперативная память?

424

После настройки удалённых резервных копий Backblaze я вижу в панели управления эту ошибку:

Сервер настроен на загрузку файлов в S3, но не настроена CDN S3. Это может привести к высоким затратам на S3 и снижению производительности сайта. Подробнее см. в разделе «Использование объектного хранилища для загрузки файлов».

Я не настраивал загрузку файлов, я настроил только резервное копирование с помощью следующей конфигурации:

DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3

Неужели я что-то сделал неправильно?

Кажется, что что-то настроено неверно: при попытке загрузить файл в пост я получаю эту ошибку:

Недопустимое значение для canned acl ‘public-read’

Буду признателен за любую помощь.

2 лайка
425

Удалите это, если не хотите, чтобы загрузки отправлялись в S3.

4 лайка
426

Ты спас день, брат. :+1:t3: Большое спасибо!

2 лайка
427

Кажется, это сработало?

1 лайк
428

За последний месяц это произошло один раз, после того как я разнес эти два процесса на час. Это не «исправило» проблему, и случается она не так часто, чтобы можно было сказать, помогло ли это.

С другой стороны, я заметил, что на странице администратора есть раздел со статусом резервного копирования, который показывает доступное место на диске. Это избавляет меня от необходимости постоянно открывать терминал и выполнять команду df, чтобы проверить, не застряло ли резервное копирование. Я изменил текст, чтобы напомнить себе, что ожидаю около 80 ГБ свободного места.

image
image282×203 2.86 KB

1 лайк
429

Отличная идея.

Я увидел изображение до того, как прочитал, что вы изменили текст, и wondered, какая логика привела к тому, что это было признано «хорошим»!

1 лайк
430

Мне так и не удалось заставить это работать с Scaleway, используя образ Bitnami Discourse.

Переменные окружения были заданы, но явно не читались/применялись корректно (или вообще не применялись?).

Поэтому я установил переменные S3 в панели администратора и указал регион напрямую в консоли Rails (все еще надеясь, что это просто станет текстовым полем):
SiteSetting.s3_region="fr-par"

Это вызвало ошибку валидации, но я просто закомментировал проверку валидации перед обновлением настройки, а затем вернул её обратно.

1 лайк
431

Образ Bitnami не упакован нами и не следует нашим рекомендациям. Всё, что документировано здесь, протестировано только на официальной установке.

4 лайка
432

Это было решено включением опции «использовать CDN-URL S3 для всех загрузок», которая недавно была добавлена в Discourse.
Поскольку ранее мы использовали R2, нам нужно было использовать discourse remap для ручного исправления нерабочих ссылок, а также синхронизировать файлы S3 на всякий случай, после чего мы перекомпилировали все сообщения.

1 лайк
434

Я пытаюсь настроить это с помощью idrive e2, который совместим с S3. Однако в конце команды ./launcher rebuild app я получаю не очень полезную ошибку/трассировку стека:

I, [2023-10-14T15:08:08.026184 #1]  INFO -- : > cd /var/www/discourse && sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: We encountered an internal error, please try again.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1]  INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js

Это конфигурация, которую я использовал, но я также пробовал с DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY и DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: Dallas
  DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
  DISCOURSE_S3_ACCESS_KEY_ID: <snip>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
  DISCOURSE_S3_BUCKET: discourse
  DISCOURSE_S3_INSTALL_CORS_RULE: false

Обратите внимание, что я не использую это для резервных копий (они уже настроены в интерфейсе с помощью Backblaze), а также не использую DISCOURSE_CDN_URL, так как не уверен, что idrive это поддерживает. Я планировал поэкспериментировать с этим, когда в бакет попадут реальные файлы.

1 лайк
435

Похоже, что это недостаточно совместимо с S3 для нужд Discourse.

Если вы хотите разобраться глубже, следующим шагом будет воспроизведение проблемы в установке для разработки и получение точного вызова API, который не работает.

2 лайка