AWSにデプロイされたDiscourseがデータベースURLからアセットを取得しています

チームの皆様

Discourse を AWS ECS 上で実行しています。アプリケーションを実行しようとしたところ、ブラウザのコンソールタブが以下の URL でエラーになっています。何か設定変更を見落としているでしょうか?

Mixed Content: ページ ‘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 を Docker を使用して ECS にデプロイしました。アプリケーションにアクセスしようとすると、ネットワークブラウザが https://discuss-stage.tllms.com/ ではなく、以下の URL からリソースを取得しようとしています。

これは、database.yml ファイルで使用されている RDS エンドポイント discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com です。

Mixed Content: ページ ‘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 で提供される必要があります。

Content Security Policy のディレクティブ “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/” に違反するため、スクリプト ‘https://discuss-stage.tllms.com/assets/browser-detect.js’ の読み込みが拒否されました。‘script-src-elem’ が明示的に設定されていないため、‘script-src’ がフォールバックとして使用されています。

S3 バケットの設定ミスのようです。

Discourse はどのようにインストールしましたか?Discourse 公式の標準インストールを使用しましたか、それともBitnami インストールのトラブルシューティングに従いましたか?

設定が誤っている CDN に賭けます。
config/discourse.conf を共有していただけませんか?
また、サイト設定で c0fbtc を検索して、ヒットがあるか確認してください。

こんにちは、Jay さん

通常のリレーショナル・アプリケーションとしてインストールしました。以下が私が踏んだ手順です。

  1. GitHub リポジトリをクローンしました。
  2. Gem を bundle install しました。
  3. database.yml ファイルを編集して AWS RDS エンドポイントを指すように設定しました。
  4. discourse.conf ファイルを編集して AWS ElastiCache を指すように設定しました。
  5. S3 バケット設定は使用していません。
  6. コードを Docker コンテナ内にコピーし、ECS にデプロイしました。

事前構築された Docker イメージは使用せず、自分で Docker イメージをビルドしました。

設定ファイルを削除中

これは正しくないようです。もし私なら、データベースが実際にはローカルにあり、奇妙な名前になっているか確認します。

以下のようにすべきだと思います:

# DBサーバーのホストアドレス
# ソケットを最初に試すよう空白に設定されています
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# Discourseが動作しているデータベース名
db_name = default

S3 は何に使用されますか?また、discourse_defaults.conf ファイルを変更せずに、別の discourse.conf ファイルを作成する必要がありますか?

これは S3 とは関係ありません。

discourse.conf ファイルは app.yml から生成されるため、変更は app.yml で行い、再構築してください。

「いいね!」 1

リチャード

GitHub - discourse/discourse: A platform for community discussion. Free, open, simple. · GitHub から Discourse をクローンしましたが、リポジトリ内に app.yml ファイルが見つかりませんでした。

すべての Discourse の設定が、私が使用したくない discourse_docker を指しています。私は独自のコンテナを構築したいと考えています。

(完全に機能する車輪を再考しようとするのはやめるよう警告しておきます。また、コミュニティにメリットがないため、ここにいる人々はあなたのサポートにあまり熱心ではないでしょう)。

何をするにせよ、最終的にはそれらの値が discourse.conf に正しく反映されていることを確認してください。手動で編集した場合は、少なくとも db_host に AWS のホスト名を指定し、db_namedefault のままにしてください。

「いいね!」 1

リチャードさん、こんにちは。

私はヴィジャイと同じチームに所属しています。今回取り組んでいる具体的なユースケースは、Discourse をフォークして自社の GitHub リポジトリに配置し、そこからビルドして AWS にデプロイするというものです。GitHub 上で管理したい理由は、自社の要件に合わせて柔軟に変更を加えられるようにするためです。可能な範囲で貢献することも検討しています。

Discourse の公開リポジトリに Dockerfile が見つからなかったため、Docker イメージをビルドするための独自の Dockerfile を作成しました。さらに、GitHub Actions を使用して、作成した Docker イメージを AWS ECS サービスにデプロイしています。

これらの要件を踏まえて、他に検討すべきアプローチはあると思われますでしょうか?

よろしくお願いいたします。

はい。お勧めするのは、公式の discourse および discourse_docker リポジトリを使用し、すべての変更をプラグインとして実装することです。

公式の discourse_docker を使用すれば、このトピックで述べられているような問題を防ぐことができます。また、Discourse をフォークするのではなく、すべての変更を個別のプラグインに保つことで、メインブランチから逸脱することを避け、フォークにアップストリームの変更をすべて移植するために多大な労力を費やす必要がなくなります。

プラグイン開発の学習曲線は、数週間でアップストリームのマージに要する労力と均衡し、それ以降はさらに効率的になります。

公式の Discourse リポジトリを使用している場合、マネージドホスティングの利用も検討できます。また、サポートが必要な際にも、人々はより熱心に(あるいはより安価に)対応してくれるでしょう。

「いいね!」 2

ご投稿ありがとうございます。いくつかフォローアップの質問がございます:

  1. プラグイン方式の場合、プラグインでは実現できない要件にボトルネックが発生する可能性はありますか?例えば、ユーザーロールを非常にカスタマイズされた方法で管理する場合などです。
  2. discourse_docker を採用し、AWS アカウントの ECS にデプロイする場合、エンドツーエンドのパイプラインはどのようになるでしょうか?現在、AWS アカウントへのデプロイには GitHub Actions を利用していると申し上げました。AWS 資格情報を保護しつつ、公開リポジトリからどのようなデプロイ戦略を採用できるでしょうか?
  1. プラグインは Ruby のモンキーパッチングと Ember オブジェクトの拡張をサポートしており、最終的にはあらゆることが可能です。

  2. これは私の専門分野ではないため、他の人に任せます。

常に discourse_docker リポジトリのコピーから始め、その中に app.yml を作成してください。

discourse_docker の作業コピーで launcher スクリプト の bootstrap サブコマンドを使用して Docker イメージを作成し、それを Docker リポジトリにプッシュしてください。その後、作成した Docker イメージを任意の場所にデプロイします。

必要に応じてプラグインを作成し、他のプラグインと同様に app.yml にカスタムプラグインをリストしてください。

「いいね!」 5

@ashish_rawat @Vijay_Vantipalli Discourse Docker を ECS でどのようにセットアップされましたか?EC2 サーバーで試したときは Discourse が正常に読み込まれました。しかし、Discourse の Docker イメージを ECR レジストリにプッシュし、そのイメージからタスクを作成すると、コンテナが起動せず、Exit Code 1 になります。1 週間以上この問題に悩まされています。アドバイスをお聞かせいただければ幸いです。ありがとうございます!

なお、別途 RDS インスタンスと Redis クラスター用の ElastiCache を作成しました。

./launcher start-cmd app に含まれる引数を調べてみてください。ECS にコピーし忘れているものが含まれている可能性があります。

「いいね!」 3

迅速なご返信ありがとうございます!単純な見落としだったのかもしれません。試してみます。

もし私の質問が担当範囲外であれば申し訳ありません。start-cmd アプリで見つけた「-e」を追加してみましたが、以下のような他の引数もあります:

+ /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 にストレージを確保することは必須です。

「いいね!」 2