Использование объектного хранилища Scaleway, совместимого с S3

Здравствуйте,

Я пытаюсь настроить Discourse для использования объектного хранилища, совместимого с S3 от Scaleway, но у меня не получается заставить это работать, и я не понимаю, в чём проблема.

Я проверил, что оба бакета работают с помощью aws-cli, и что настройки CORS правильно настроены в соответствии с официальной документацией Scaleway, поэтому я не думаю, что проблема в самих бакетах.

Вот мои настройки S3 в Discourse (часть имени бакета скрыта):

При открытии вкладки «Резервные копии» я получаю ошибку: «Не удалось получить список резервных копий из S3: Aws::S3::Errors::BadRequest».
А при попытке загрузить изображение в логе появляется следующее сообщение: «Исключение в задаче: Не удалось установить TCP-соединение с [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Имя или служба неизвестны)».

Я использую последнюю версию Discourse — 2.4.0.beta10 (14ae574bc5).

Мне кажется, они менее совместимы с S3, чем сами полагают?

Кажется, что настройка региона S3 также влияет на ситуацию.

Это возможно, но если я указал конечную точку, то в URL не должно быть amazonaws.com, верно?

Точно, это странно. Возможно, из-за модного доменного TLD? Давай посмотрю.

@dino попробуй убрать https:// из s3 endpoint

Проверка не позволяет мне это сделать: ‘s3_endpoint: Значение не соответствует требуемому формату.’

Да, это было неверное предположение.

Я не могу найти способ завершить ссылку так, как у вас, изучая код, отвечающий за это:

Это влияет только на резервные копии? Загрузки работают?

Что ж, это отличается от проблемы, с которой я сталкивался в отношении корзин GCP, но вы можете ознакомиться с этим обсуждением: Trouble with Google Bucket for backup - #4 by pfaffman.

Мне удалось определить, какое обновление гемa aws-sdk-s3 привело к неработоспособности корзин GCP, хотя решение, которое выбрал мой клиент, заключалось в переходе на корзину AWS.

@Falco да, я тоже в тупике.
Ошибка с URL, содержащим amazonaws, относится конкретно к загрузке файлов, а не к резервным копиям. Для резервных копий я получаю только общую ошибку, так что, похоже, оба процесса сломаны из-за проблемы с URL.

Можешь подумать, что ещё может быть причиной?

@pfaffman спасибо за подсказку — посмотрю, поможет ли изменение версии gem.

Привет @dino, это в итоге помогло? У меня здесь та же проблема, и я почти готов сдаться и перейти на Amazon S3.

Привет @FroggyC,

У меня, к сожалению, не хватило времени на отладку, поэтому я в итоге не стал экспериментировать с изменением версий gems. Я переключился на использование Amazon S3 согласно официальной документации, и всё заработало сразу.

Извини, что новости не такие хорошие…

Спасибо. Полагаю, нам тоже придётся поступить так же. Спасибо!

Та же проблема. Чем мы можем помочь в отладке?

Например, получить доступ к бакету через CLI и отправить файлы логов?

Параметр s3_region игнорируется, верно? Поскольку Scaleway использует другие значения, чем AWS.

Попробуйте обратиться в Scaleway — ответственность за совместимость лежит на них. Если они не полностью совместимы с AWS S3, им следует это исправить.

Вы намекаете, что это их вина, однако до сих пор вы игнорировали комментарий @dino:

Пока URL-адрес s3_endpoint (без изменений) не используется в исходном виде, будет трудно убедить Scaleway, что ошибка на их стороне. Особенно учитывая, что другие S3-клиенты могут подключиться.

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

Конечно, именно это я и имел в виду, когда писал:

Так как же заставить Discourse логировать попытки подключения к S3? Как только мы точно узнаем, к какому URL он пытается подключиться, я смогу перехватить трафик и поделиться результатами.

Причина, по которой не работает загрузка/резервное копирование в S3, заключается в том, что регион необходимо установить в fr-par (или nl-ams). Это можно сделать только в обход валидации SiteSetting в Discourse:

(через ./launcher enter app, затем rails c)

SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')

После этого изменения загрузка и резервное копирование в объектное хранилище Scaleway начинают работать.

Документация Scaleway по объектным хранилищам

Конечно, это обходное решение. Если вы сбросите или измените эту настройку сайта через веб-администратор, вы не сможете вернуть её в рабочее состояние (если не использовать консоль Rails снова).

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

Также это вводит в заблуждение в случае значения «EU (Paris)» в выпадающем списке Discourse, так как оно относится к схеме именования AWS eu-west-3 (или подобной), а не к ожидаемому значению для Scaleway.

Ага. Нужна ли нам специальная настройка сайта «s3 совместимый регион» @falco? Это позволило бы пользователям вводить совершенно произвольные (и, следовательно, с точки зрения Amazon «выдуманные») регионы?

В этом нет необходимости.

Пользователям клонов S3 нужно задать переменную окружения S3 Endpoint, которая перезаписывает регион S3.

У меня есть подробная инструкция по настройке с клоном S3 от Digital Ocean, но я жду, пока Digital Ocean исправит ошибку в их CDN для S3, прежде чем публиковать её.

Если Scaleway работает лучше, чем Digital Ocean, я думаю, что попробую их и построю своё руководство на основе этого опыта.

Верно, но как они узнают, что это нужно сделать? Упоминается ли это в описании существующего параметра настройки сайта? Мне кажется, что должно. Можешь ли ты это исправить?