URL: //s3-bucket/prefix/file.jpeg にあるストアでファイルが見つかりませんでした

インストール
1

ECSで公式Dockerイメージの設定を行っています。
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

ランチャーを使用してイメージをビルドし、リポジトリにプッシュしましたか？また、ランチャーが使用するものと同じ環境で起動していますか？

3

はい。run-cmd コマンドが生成する環境変数を使用しています。今のところエラーは見つかりませんでした。
残念ながら、Discourse の ECS の例はまだ見つかりませんでした。

4

順調ですが、スタンドイーの移行とアセットのアップロードは難しいです。問題が何であるか分かりません。

5

原因を特定しました。Discourse AIプラグインの設定で、さまざまなサービスをVPC内部で利用可能にするために、VPCにプライベートゾーンを追加したことが原因でした。

Dockerコンテナ内のEC2インスタンスでDiscourseを実行する場合、コンテナには12-34-56-78-appのようなホスト名が付けられます。しかし、ECSタスクとして実行する場合、awsvpcモードではホスト名を設定できませんし、DNS検索ドメインも設定できません。これにより、ECSでのDNS解決が異なり、私の場合はxxxx.internalのような検索ドメインが追加されます。

調査した結果、tcpdumpを使用して、DiscourseがSSRFチェックの一部として自身のFQDNを解決しようとしていることがわかりました。これが失敗すると、チェックも失敗します。その後のエラーとして、上記の不正なエラーメッセージでS3への呼び出しが失敗します。

私の場合は、CloudfrontディストリビューションへのエイリアスであるFQDNレコードをプライベートDNSゾーンに追加することが修正となりました。

「いいね！」 2
6

すごい。それは良いデバッグですね！だからこれはサポートされていないインストールなのです！推測できるようなことはほとんどありませんでした！

「いいね！」 1
7

結局いつもの通りだ：うまくいかないときは、いつもDNSのせいだ😂

8

こんにちは、@nodomainさん。

あなたの投稿と同じエラーが発生しました。たとえば、https://example.com/user_avatar/example.com/myself/96/215_2.png へのユーザーアバターのリクエストが500を返します。私のケースでは、ドメイン名 example.com はパブリックDNSに設定されていません。テスト段階では、ローカルのhostsファイルでexample.comをスプーフィングしています。ドメイン名example.comがパブリックDNSに設定された場合、この問題は発生しなくなりますか？