Не удалось найти файл в хранилище по адресу url: //s3-bucket/prefix/file.jpeg

Поддержка Самостоятельное хостинг
1

В данный момент я настраиваю официальный образ Docker на AWS ECS.
При запуске на EC2 образ Docker работает безупречно.

Однако после запуска на ECS с той же конфигурацией у меня возникают проблемы с отображением аватарок.

Соответствующие ошибки:

Could not find file in the store located at url: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

и

Failed to process hijacked response correctly : FinalDestination::SSRFDetector::LookupFailedError : FinalDestination: lookup failed

Файл находится в бакете, а права доступа такие же, как для экземпляра EC2.

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

Спасибо

2

Вы создали образ с загрузчиком (launcher) и загрузили его в репозиторий? И запускаете ли вы его с теми же переменными окружения, которые использует загрузчик?

3

Да. Я использую переменные окружения, которые генерирует команда run-cmd. Пока что я не обнаружил ошибок.
К сожалению, мне пока не удалось найти примеры использования ECS для Discourse.

4

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

5

Я нашел первопричину. Из-за моей настройки плагина Discourse AI я добавил частную зону в VPC, чтобы обеспечить доступность различных служб внутри VPC.

При запуске Discourse на экземпляре EC2 в контейнере Docker контейнер получает имя хоста вида 12-34-56-78-app. Однако при запуске в виде задачи ECS в режиме awsvpc нельзя установить имя хоста, а также нельзя настроить домен поиска DNS. Это приводит к тому, что разрешение DNS в ECS работает иначе: в моем случае добавляется домен поиска, например, xxxx.internal.

После детального анализа с помощью tcpdump я обнаружил, что Discourse пытается разрешить свой собственный FQDN в рамках проверок SSRF. Если это не удается, проверка завершается неудачей. Вследствие этого вызов к S3 завершается ошибкой с ложным сообщением, указанным выше.

В моем случае исправление заключалось в добавлении записи FQDN (являющейся алиасом для моей дистрибуции CloudFront) в частную зону DNS.

6

Вау! Отличная отладка! Именно поэтому эта установка не поддерживается! Маловероятно, что можно было бы догадаться обо всём этом!

7

В конце концов, как обычно: если что-то не работает, то это всегда DNS :joy:

8

Привет, @nodomain,
У меня возникла точно такая же ошибка, как в вашем сообщении ниже. Запрос к аватару пользователя, например, https://example.com/user_avatar/example.com/myself/96/215_2.png, возвращает ошибку 500. В моём случае доменное имя example.com ещё не настроено в публичной DNS-системе; на этапе тестирования я подменяю его в локальном файле hosts. Не исчезнет ли эта проблема, когда доменное имя example.com будет зарегистрировано в публичной DNS?