Ресурсы не загружаются через CDN в последнем обновлении

Привет!

Я не смог понять, почему после последнего обновления наша установка перестала отдавать ресурсы через CDN. Мы используем Cloudfront, и раньше всё работало отлично: и загрузки, и ресурсы отдавались корректно, но, похоже, после последнего обновления ресурсы теперь отдаются напрямую с сервера.

Ещё одна проблема, с которой мы столкнулись: если передать переменную DISCOURSE_CDN_URL, Discourse начинает запрашивать ресурсы, которые не генерируются и не загружаются задачей s3:upload_assets (например, таблицы стилей). Из-за этого сайт полностью ломается и отображается белая страница. В этой теме упоминается что-то похожее.

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

Спасибо!

Это новая ошибка, @falco? Мы что-то сломали здесь?

@eatcodetravel нам нужно гораздо больше подробностей, чтобы как-то помочь вам.

Каковы точные значения настроек и переменных окружения, связанных с S3 и CDN?

@Falco, конечно, какая информация вам нужна? Наше решение с открытым исходным кодом, и вот настройки, которые мы используем.

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

Возвращаясь к сайту, с которым у меня возникли проблемы, похоже, что я забыл указать https:// в URL CDN, который использовал. Не совсем понятно, как это вообще могло работать, или, если оно никогда не работало, почему я не заметил этого при добавлении некорректного значения.

@eatcodetravel, конечно, вам нужно скрыть пароли SMTP и ключи S3, но, думаю, вам придётся поделиться хотя бы значениями CDN, чтобы кто-то мог хоть как-то предположить, в чём может быть проблема.

Конечно, позвольте мне записать их здесь. Я думаю, что нужен только CDN_URL, так как остальные параметры проверяются через AWS SDK.

DISCOURSE_S3_CDN_URL: 'https://community-cdn-prod.debtcollective.org'
DISCOURSE_S3_REGION: 'us-west-1'

Ранее DISCOURSE_CDN_URL также был установлен в значение ‘https://community-cdn-prod.debtcollective.org’, но я его удалил.

В нашей конфигурации ничего существенного не изменилось, мы просто мигрировали на более мощный экземпляр EC2.

Также, если вам понадобится дополнительная информация, дайте знать, @Falco. Я с радостью отвечу на ваши вопросы.

Итак, вы в настоящее время используете S3 CDN, но не обычный CDN. Не уверен, что такая конфигурация поддерживается…

Другие три комбинации точно работают корректно:

  1. Без CDN
  2. Только DISCOURSE_CDN_URL
  3. И DISCOURSE_CDN_URL, и DISCOURSE_S3_CDN_URL.

Кажется, это может объяснить некоторые проблемы с CDN, с которыми я сталкивался в прошлом.

Да, мне пришлось удалить DISCOURSE_CDN_URL, так как система начала запрашивать ресурсы, которые не загружаются в S3 задачей rake s3:upload_assets, и это полностью ломает сайт. Возможно, это та часть, которая изменилась, и нам нужно обновить rake s3:upload_assets, чтобы она снова работала корректно.

Да, использование одного и того же URL CDN для DISCOURSE_CDN_URL и DISCOURSE_S3_CDN_URL возможно, но это требует много настройки в CDN, чтобы использовать правильный источник для каждого ресурса на основе URL. Например, CSS берётся из приложения, JS — из S3, и это лишь один из десятков подобных случаев.

Поэтому ожидается, что вы настроите оба параметра: DISCOURSE_CDN_URL будет «прокси» к вашему веб-приложению, а DISCOURSE_S3_CDN_URL — прокси к вашему бакету объектного хранилища.

О, понятно, это что-то изменилось недавно? Я не уверен, поддерживает ли Cloudfront роль обратного прокси для нашего приложения вместо S3-бакета.

Я вижу, что вы используете Cloudfront в meta. Есть ли что-то особенное, что вы делаете для его запуска, или сам Discourse берет на себя все настройки?

Если вы проанализируете эту страницу, то увидите, что у нас есть два разных URL-адреса CloudFront. Поэтому мы используем описанный выше подход: два дистрибутива — один для обычного CDN, а другой для S3.

Проблема, упомянутая в заголовке вопроса автора (OP), заключается в следующем: CSS-файлы загружаются из приложения, а JS-файлы — из S3. Вам нужен CDN, который «понимает», откуда поступает каждый отдельный ресурс, и может обращаться к нужному месту, либо два CDN. Именно поэтому у нас в итоге две разные настройки.

Хотя теперь, когда я это понял, это кажется вполне логичным, я не уверен, что это задокументировано. И вы, скорее всего, столкнетесь с проблемами (по крайней мере, я столкнулся!), так как задача rake move-uploads-to-s3 требует наличия s3_cdn. Это объясняет, почему несколько раз я пытался перенести данные в S3, но в итоге сходил с дистанции.

Кажется, было бы неплохо, если бы где-то было предупреждение: «Эй, у вас не может быть S3 CDN без asset CDN».

Хорошо, теперь я понял, что вы имеете в виду, не знал, что это требуется. Можно спросить, почему CSS должен поступать из приложения? Почему мы не можем загрузить его через задачу rake s3:upload_assets?

Я проведу исследование о том, как это реализовать в Cloudfront, и опубликую здесь свои выводы и проблемы.

Спасибо @Falco, это было действительно полезно

Что ж, возможно, я объясняю это плохо. Можно. Но это довольно хлопотно, как показывают темы и эта в частности.

Сайт от @eatcodetravel в данный момент работает только с настройкой S3_CDN, но затем возникает странное состояние, когда CSS (который блокирует рендеринг) обслуживается с вашего сервера, а изображения в постах — нет, что не имеет смысла.

Потому что существует раздел Администрирование > Настройка. Пользователи могут изменять CSS в панели администратора. Пользовательские фрагменты JS, находящиеся в темах, также обслуживаются из приложения, насколько мне известно.

Может, нам стоит как-то лучше это задокументировать, @falco? Может быть, даже в духе «здесь живут :dragon:»?

В итоге я решил эту проблему, создав второй дистрибутив CloudFront, указывающий на веб-сервер, и оставив первый только для S3. Спасибо @Falco за обратную связь, но я согласен, что это нужно немного лучше задокументировать.