Я пытаюсь настроить 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).
Мне удалось определить, какое обновление гемa aws-sdk-s3 привело к неработоспособности корзин GCP, хотя решение, которое выбрал мой клиент, заключалось в переходе на корзину AWS.
@Falco да, я тоже в тупике.
Ошибка с URL, содержащим amazonaws, относится конкретно к загрузке файлов, а не к резервным копиям. Для резервных копий я получаю только общую ошибку, так что, похоже, оба процесса сломаны из-за проблемы с URL.
Можешь подумать, что ещё может быть причиной?
@pfaffman спасибо за подсказку — посмотрю, поможет ли изменение версии gem.
У меня, к сожалению, не хватило времени на отладку, поэтому я в итоге не стал экспериментировать с изменением версий gems. Я переключился на использование Amazon S3 согласно официальной документации, и всё заработало сразу.
Вы намекаете, что это их вина, однако до сих пор вы игнорировали комментарий @dino:
Пока URL-адрес s3_endpoint (без изменений) не используется в исходном виде, будет трудно убедить Scaleway, что ошибка на их стороне. Особенно учитывая, что другие S3-клиенты могут подключиться.
Ладно, докажи. Покажи документацию и логи, которые подтверждают это. Если ты сможешь предоставить реальные доказательства того, что проблема на нашей стороне, я разберусь.
Так как же заставить Discourse логировать попытки подключения к S3? Как только мы точно узнаем, к какому URL он пытается подключиться, я смогу перехватить трафик и поделиться результатами.
Причина, по которой не работает загрузка/резервное копирование в S3, заключается в том, что регион необходимо установить в fr-par (или nl-ams). Это можно сделать только в обход валидации SiteSetting в Discourse:
Конечно, это обходное решение. Если вы сбросите или измените эту настройку сайта через веб-администратор, вы не сможете вернуть её в рабочее состояние (если не использовать консоль 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, я думаю, что попробую их и построю своё руководство на основе этого опыта.
Верно, но как они узнают, что это нужно сделать? Упоминается ли это в описании существующего параметра настройки сайта? Мне кажется, что должно. Можешь ли ты это исправить?