Стороны, поддерживающие AWS SDK, нарушили совместимость. Ваша задача — обновить провайдера S3-клонирования и реализовать улучшенную совместимость, чтобы вы могли отказаться от временных решений.
Просто уточню: это касается только файлов JS/map/CSS в папке assets и не влияет на загрузку файлов, верно?
То есть, это повлияет ли на очистку «осиротевших» файлов?
Кстати, я предполагаю, что эта проблема может затрагивать обновление Discourse через панель администратора?
На самом деле, обновление через панель администратора у меня не сработало, поэтому я выполнил пересборку.
Да, это только для ресурсов.
Эта задача rake? Нет.
Но полное изменение AWS SDK могло также сломать эту функциональность для пользователей несовместимых клонов.
Я почти уверен, что это неверно. Так что, вероятно, нам нужно также отключить clean up uploads. Это просто вызовет ошибки во время работы, но не помешает пересборке.
Вероятно. Возможно, нам понадобится настройка “skip_s3_delete”, чтобы решить эту проблему, пока другие провайдеры не догонят? И, возможно, автоматически устанавливать её для провайдеров, о которых мы знаем, что они не работают?
Является ли эта задача Rake единственным способом удаления устаревших ресурсов?
Меня просто интересует, почему бы не добавить опцию для хранения ресурсов на основном сервере Discourse (то есть без их сохранения в S3)?
Пока это не влияет на загрузку файлов или процесс удаления orphaned файлов, это кажется жизнеспособным решением.
Да. В этом нет ничего критичного. Обычные сайты, обновляемые время от времени, не заметят большой разницы.
Пользователи могут настроить свои собственные правила жизненного цикла, если это для них важно.
Разве настройка clean up uploads = false уже не является этим решением?
Ха-ха, нет. Discourse официально поддерживает S3. Хотя я приложил немало усилий, создав всю вики-статью Настройка совместимого с S3 провайдера объектного хранилища для загрузок и добавив несколько переключателей для повышения совместимости клонов, у нас нет никаких планов вкладывать больше времени в это на данный момент.
Если сообщество захочет отправить несколько PR, повышающих совместимость и по умолчанию отключённых, мы будем рады (pr-welcome), но не ожидайте, что официальная поддержка каждого клона в ядре появится в ближайшее время.
Кстати, похоже, что у Digital Ocean нет проблем ни с удалением резервных копий, ни с истечением срока хранения отсутствующих ресурсов.
Для ненадёжных провайдеров прошло бы довольно много времени, прежде чем ненужные ресурсы вызвали бы серьёзные проблемы. Однако хранение множества резервных копий, включая огромную базу данных и все загруженные файлы, может стать серьёзной проблемой, если вы платите за хранилище.
Привет, я Пат Паттерсон, главный технический евангелист компании Backblaze. Я наткнулся на эту ветку, так как у меня есть собственный форум Discourse в режиме proof-of-concept, и сегодня при настройке использования Backblaze B2 для резервного копирования и загрузки файлов я столкнулся именно с этой проблемой.
Установка параметров AWS_REQUEST_CHECKSUM_CALCULATION и AWS_RESPONSE_CHECKSUM_CALCULATION в значение WHEN_REQUIRED является полезным обходным решением для базовых случаев загрузки и выгрузки файлов, однако стоит знать, что оно не покрывает ряд сценариев, включая:
- Удаление файлов — Discourse использует операцию S3
DeleteObjectsдля удаления нескольких файлов в одном вызове API, как и положено. - Загрузку файлов в бакеты с включённой функцией блокировки объектов (object lock).
Проблема заключается в том, что для этих операций требуется (а не просто поддерживается) контрольная сумма (либо заголовок Content-MD5, либо один из новых заголовков контрольных сумм), из-за чего текущие версии AWS SDK автоматически добавляют новый заголовок контрольной суммы. Насколько мне известно, нет способа переопределить это поведение и заставить SDK использовать Content-MD5, как это было раньше.
Наши инженеры работают над решением всех этих вопросов; тем временем лучшей мерой смягчения является использование версии 1.177.0 или более ранней пакета aws-sdk-s3.
Я попытался понизить версии пакетов AWS SDK в своём тестовом развёртывании, отредактировав файл Gemfile и заменив:
gem "aws-sdk-s3", require: false
gem "aws-sdk-sns", require: false
на
gem "aws-sdk-core", "~> 3.215.1", require: false
gem "aws-sdk-kms", "~> 1.96.0", require: false
gem "aws-sdk-s3", "~> 1.177.0", require: false
gem "aws-sdk-sns", "~> 1.92.0", require: false
но мои навыки работы с bundle оказались недостаточно сильными, и мне удалось лишь сломать развёртывание с ошибкой:
/var/www/discourse/config/initializers/100-sidekiq.rb:69:in `<main>': undefined method `logger=' for module Sidekiq (NoMethodError)
Sidekiq.logger = Logger.new(nil)
^^^^^^^^^
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `load'
from /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-7.2.2.1/lib/rails/engine.rb:689:in `block in load_config_initializer'
...
Похоже, я упустил какой-то важный шаг.
Не желая бросать тень на наших друзей из DO, скажу, что они решили это, обновив свой сервис так, чтобы он просто игнорировал новые заголовки контрольных сумм, вместо того чтобы отклонять вызов API из-за неподдерживаемой контрольной суммы.
В их отчёте об инциденте говорится:
Обратите внимание, что Spaces в настоящее время не проверяет контрольные суммы целостности данных, отправляемые AWS CLI и AWS SDK в рамках запросов на загрузку.
Мы же решили, что простое принятие и хранение данных, которые могут не соответствовать контрольной сумме, предоставленной клиентом API, — это плохой подход.
Спасибо за публикацию!
Да, и разработчики AWS SDK лишь холодно игнорируют нашу проблему
Рад, что команда B2 тоже обратила внимание на эту проблему.
Вот моё временное решение:
Я закомментировал все конфигурации, связанные с S3, в файле app.yml, и успешно пересобрал Discourse. Это не влияет на доступ к ранее загруженным файлам на моём сайте, а любые вложения, загруженные в этот период, будут храниться локально без каких-либо проблем.
Кстати, я всё ещё думаю: почему бы не добавить опцию для хранения активов на основном сервере Discourse (то есть без их размещения на S3)?
???
Так Discourse работает по умолчанию. Чтобы передавать ассеты в сервис объектного хранилища, нужно явно включить эту опцию.
Я имею в виду, что было бы неплохо иметь возможность хранить основные ресурсы Discourse (JS, CSS и т.д.) на локальном сервере. При этом в S3 будут сохраняться только файлы, загруженные пользователями.
Вы можете сделать это, не включая «use_s3», но они небольшие — я бы просто загрузил их и не беспокоился о потраченном впустую месте.
Пожалуйста, помогите мне правильно понять.
Вы имеете в виду установить DISCOURSE_USE_S3: false в app.yml?
Я хочу сделать это, потому что мой сервер Discourse находится в Азии, а у B2 серверы только в США.
Кроме того, проблема с AWS SDK в этот раз связана с управлением активами, верно?
Так что, если я буду хранить активы на локальном сервере, это может избежать проблемы (если я правильно понимаю ситуацию).
Проблема связана с удалением ресурсов из S3. Если вы просто удалите строку, которая пытается удалить неиспользуемые ресурсы, это сразу сработает. И похоже, что скоро проблема будет решена. Это самое простое решение. Я рекомендую именно его. Это мой лучший бесплатный ответ.
Спасибо, это очень полезно для меня!
Это связано с тем, что в определении API S3 операция DeleteObjects имеет параметр httpChecksum.requestChecksumRequired, установленный в true, в отличие от, например, PutObject, который устанавливает его в false. Таким образом, SDK соблюдает режим WHEN_REQUIRED, поскольку контрольная сумма действительно требуется.
Все SDK AWS теперь генерируются на основе определения API с минимальным количеством дополнительного кода для покрытия пограничных случаев. Код видит, что для DeleteObjects требуется контрольная сумма, и способ сделать это сейчас — использовать один из новых алгоритмов контрольных сумм, а не Content-MD5.
К сожалению, AWS не сочли нужным предоставить конфигурацию «используйте Content-MD5, как раньше». Они обычно не учитывают экосистему сторонних объектных хранилищ при внесении подобных изменений, поскольку в этом нет необходимости. Подобные проблемы исправляются только тогда, когда они случайно ломают одну из их собственных служб в каком-то пограничном случае.
Хотя это не особенно поможет, если вы находитесь в Азии, но для полноты картины: у нас также есть центры обработки данных в Европе (Амстердам, Нидерланды) и, с начала этого года, в Канаде (Торонто).
Я не могу давать никаких обещаний, но мы определённо рассматриваем возможность размещения в Азии.
Кроме того, если вы используете CDN, не так важно, где находится исходный сервер.
Вы правы!
Backblaze не поддерживает x-amz-checksum-crc32, и новая версия AWS SDK в Discourse могла включить эту функцию по умолчанию.
Поэтому я зашёл в приложение:
./launcher enter app
и удалил текущую версию AWS SDK:
gem uninstall aws-sdk-s3 aws-sdk-core aws-sdk-kms
затем установил ту версию, которая, по словам представителя Backblaze, должна работать:
gem install aws-sdk-core -v “~> 3.215.1”
gem install aws-sdk-kms -v “~> 1.96.0”
gem install aws-sdk-s3 -v “~> 1.177.0”
после этого я пересобрал приложение, и всё заработало!