Развернутый в AWS Discourse загружает ресурсы по URL базы данных

Привет, команда,

Я запускаю Discourse на AWS ECS. При попытке запустить приложение вкладка консоли в браузере выдаёт ошибку с указанными ниже URL-адресами. Не упустил ли я какое-то изменение конфигурации?

Смешанный контент: страница по адресу «https://discuss-stage.tllms.com/finish-installation/register» была загружена через HTTPS, но запросила небезопасную иконку сайта «http://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png». Этот запрос был заблокирован; контент должен предоставляться через HTTPS.

В приведённом выше URL указан мой конечный адрес базы данных: discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com.

Я указал этот конечный адрес в файле database.yml.

Я развернул Discourse в ECS с использованием Docker. При попытке получить доступ к приложению браузер запрашивает ресурсы по следующим URL-адресам вместо https://discuss-stage.tllms.com/.

Это конечный адрес RDS discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com, который используется в файле database.yml.

Смешанный контент: страница по адресу «https://discuss-stage.tllms.com/» была загружена через HTTPS, но запросила небезопасную иконку сайта «http://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/uploads/default/optimized/1X/_129430568242d1b7f853bb13ebea28b3f6af4e7_2_32x32.png». Этот запрос был заблокирован; контент должен предоставляться через HTTPS.

Загрузка скрипта «https://discuss-stage.tllms.com/assets/browser-detect.js» отклонена, так как это нарушает следующую директиву политики безопасности контента: «script-src https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/logs/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/sidekiq/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/mini-profiler-resources/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/assets/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/brotli_asset/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/extra-locales/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/highlight-js/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/javascripts/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/plugins/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/theme-javascripts/ https://discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com/svg-sprite/». Обратите внимание, что директива «script-src-elem» явно не задана, поэтому в качестве резервного варианта используется «script-src».

Похоже, что в вашем S3-бакете возникла ошибка конфигурации.

Как вы установили Discourse? Вы использовали официальную стандартную установку Discourse или, возможно, решение проблем с установками Bitnami?

Я ставлю на неправильно настроенный CDN.
Можешь поделиться своим config/discourse.conf?
И поищи на своих настройках сайта c0fbtc — посмотри, есть ли совпадения.

Привет, Джей

Я установил его как обычное Rails-приложение. Ниже приведены шаги, которые я выполнил.

  1. Клонировал репозиторий GitHub.
  2. Установил гемы с помощью bundle.
  3. Изменил файл database.yml, указав endpoint AWS RDS.
  4. Изменил файл discourse.conf для указания на AWS Elasticache.
  5. Нигде не использовал конфигурацию S3-бакета.
  6. Скопировал код внутрь контейнера Docker и развернул его в ECS.

Я не использовал готовый образ Docker. Я собрал образ Docker самостоятельно.

Удаление файла конфигурации

Кажется, что-то не так. На вашем месте я бы проверил, не является ли моя база данных локальной и не имеет ли она странное имя.

Я думаю, это должно выглядеть так:

# адрес хоста для сервера БД
# Это установлено в пустое значение, чтобы сначала попытаться использовать сокеты
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# имя базы данных, на которой работает Discourse
db_name = default

Для чего используется S3? И также нужно ли мне создать отдельный файл discourse.conf, не внося никаких изменений в файл discourse_defaults.conf?

Это не имеет никакого отношения к S3.

Файл discourse.conf генерируется из вашего app.yml; вносите изменения туда и выполните пересборку.

Ричард, я клонировал Discourse из GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub, но нигде в репозитории не могу найти файл app.yml.

Вся настройка Discourse указывает на discourse_docker, который я не хочу использовать. Я хочу собрать свой собственный контейнер.

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

В любом случае, в итоге вы должны убедиться, что эти значения корректно записаны в вашем файле discourse.conf. Если вы редактировали его вручную, хотя бы укажите хост AWS в параметре db_host и оставьте db_name равным default.

Привет, Ричард,

Я из той же команды, что и Вайджай. Конкретный сценарий, который мы здесь пытаемся реализовать, — это форк Discourse и размещение его в корпоративном GitHub. Оттуда мы собираем образ и разворачиваем его в AWS. Мы хотим разместить его в нашем GitHub, чтобы сохранить гибкость внесения изменений в соответствии с нашими требованиями. Мы хотели бы вносить вклад обратно, где это возможно. Поскольку мы не нашли Dockerfile в публичном репозитории Discourse, мы создали свой собственный для сборки Docker-образа. Кроме того, мы используем GitHub Actions для развёртывания Docker-образа в сервис AWS ECS.

Учитывая наши требования, как вы думаете, могли бы мы использовать какой-либо другой подход?

Спасибо.

Да. Моя рекомендация — использовать официальные репозитории discourse и discourse_docker и реализовывать все изменения в виде плагинов.

Использование официального discourse_docker избавит вас от проблем, подобных той, что описана в этой теме. Кроме того, отказ от форка Discourse и сохранение всех ваших модификаций в отдельных плагинах позволит избежать отклонения от основной ветки и избавит от необходимости прилагать огромные усилия для переноса всех изменений из исходного кода обратно в ваш форк.

Кривая обучения разработке плагинов окупится уже через несколько недель по сравнению с затратами на слияние изменений из исходного репозитория, а в дальнейшем это окажется ещё более эффективным.

При использовании официального репозитория Discourse вы также можете рассмотреть вариант управляемого хостинга, и специалисты будут более охотно (и/или по более низкой цене) готовы помочь вам.

Спасибо за ваши отзывы. У меня есть несколько уточняющих вопросов:

  1. При использовании подхода с плагинами существует ли вероятность того, что мы столкнемся с узким местом по некоторым требованиям, которые невозможно реализовать через плагины? Например, управление ролями пользователей очень кастомизированным образом?
  2. Как будет выглядеть сквозной конвейер (end-to-end pipeline), если мы возьмем discourse_docker и развернем его в нашей учетной записи AWS на ECS? Как я уже упоминал, в настоящее время мы используем GitHub Actions для развертывания в ECS в нашей учетной записи AWS. Какую стратегию развертывания мы можем использовать из публичного репозитория, при этом защищая наши учетные данные AWS?
  1. Плагины поддерживают изменение (monkey patching) Ruby и расширение объектов Ember, поэтому в итоге возможно всё.

  2. Это не моя область экспертизы, поэтому я передам этот вопрос кому-то другому.

Всегда начинайте с копии репозитория discourse_docker. Создайте в нём файл app.yml.

Используйте подкоманду bootstrap скрипта launcher в вашей рабочей копии discourse_docker для создания образа Docker. Загрузите образ Docker в репозиторий Docker. Разверните этот образ Docker в любом удобном вам месте.

Создавайте плагины, если это необходимо. Укажите ваши кастомные плагины в файле app.yml так же, как и другие плагины.

@ashish_rawat @Vijay_Vantipalli Как вы настроили Discourse в Docker на ECS? Когда я запускаю на сервере EC2, Discourse работает нормально. Но когда я загружаю образ Docker с Discourse в реестр ECR и создаю задачу на основе этого образа, контейнер не запускается — я получаю код выхода 1. Я уже застрял на этом более недели. Буду рад получить ваши советы. Спасибо!

Для этого я создал отдельный экземпляр RDS и кластер ElastiCache для Redis.

Попробуйте проверить аргументы, указанные в ./launcher start-cmd app — возможно, вы упустили что-то, что нужно скопировать в ECS.

Спасибо за быстрый ответ! Думаю, я просто упускаю что-то очевидное. Попробую это сделать.

Извините, если это выходит за рамки вашей компетенции. Я попытался добавить «-e», который нашёл в приложении start-cmd, но есть и другие аргументы, например:

+ /usr/bin/docker run --shm-size=512m -d --restart=always 
-h <server ip> 
-e DOCKER_HOST_IP=172.17.0.1 
--name app -t -p 80:80 
-v /var/discourse/shared/web-only:/shared 
-v /var/discourse/shared/web-only/log/var-log:/var/log 
--mac-address <address> local_discourse/app /sbin/boot

Действительно ли параметр -v обязателен?

Да, это тома для монтирования. Для работы Discourse абсолютно необходимо наличие хранилища в директории /shared внутри контейнера.