Я не смог понять, почему после последнего обновления наша установка перестала отдавать ресурсы через CDN. Мы используем Cloudfront, и раньше всё работало отлично: и загрузки, и ресурсы отдавались корректно, но, похоже, после последнего обновления ресурсы теперь отдаются напрямую с сервера.
Ещё одна проблема, с которой мы столкнулись: если передать переменную DISCOURSE_CDN_URL, Discourse начинает запрашивать ресурсы, которые не генерируются и не загружаются задачей s3:upload_assets (например, таблицы стилей). Из-за этого сайт полностью ломается и отображается белая страница. В этой теме упоминается что-то похожее.
Я удалил DISCOURSE_CDN_URL, который был установлен в то же значение, что и DISCOURSE_S3_CDN_URL, потому что это ломало сайт (он пытался загружать ресурсы, которых не существовало в S3).
Возвращаясь к сайту, с которым у меня возникли проблемы, похоже, что я забыл указать https:// в URL CDN, который использовал. Не совсем понятно, как это вообще могло работать, или, если оно никогда не работало, почему я не заметил этого при добавлении некорректного значения.
@eatcodetravel, конечно, вам нужно скрыть пароли SMTP и ключи S3, но, думаю, вам придётся поделиться хотя бы значениями 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 — прокси к вашему бакету объектного хранилища.
Если вы проанализируете эту страницу, то увидите, что у нас есть два разных 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, и опубликую здесь свои выводы и проблемы.
Что ж, возможно, я объясняю это плохо. Можно. Но это довольно хлопотно, как показывают темы и эта в частности.
Сайт от @eatcodetravel в данный момент работает только с настройкой S3_CDN, но затем возникает странное состояние, когда CSS (который блокирует рендеринг) обслуживается с вашего сервера, а изображения в постах — нет, что не имеет смысла.
Потому что существует раздел Администрирование > Настройка. Пользователи могут изменять CSS в панели администратора. Пользовательские фрагменты JS, находящиеся в темах, также обслуживаются из приложения, насколько мне известно.
В итоге я решил эту проблему, создав второй дистрибутив CloudFront, указывающий на веб-сервер, и оставив первый только для S3. Спасибо @Falco за обратную связь, но я согласен, что это нужно немного лучше задокументировать.