# DiscourseをAWS ECSまたは同様の環境で正常に動作させた方はいますか？

**URL:** <https://meta.discourse.org/t/has-anyone-successfully-gotten-discourse-running-in-aws-ecs-similar/141694>\
**Category:** Development\
**Created:** [2020 年 2 月 15 日午後 5:54 UTC](https://meta.discourse.org/t/has-anyone-successfully-gotten-discourse-running-in-aws-ecs-similar/141694 "2020-02-15T17:54:38Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![lktmxjv](https://avatars.discourse-cdn.com/v4/letter/l/fbc32d/32.png) [@lktmxjv](https://meta.discourse.org/u/lktmxjv)\
**Post date:** [2020 年 2 月 15 日午後 11:36 UTC](https://meta.discourse.org/t/has-anyone-successfully-gotten-discourse-running-in-aws-ecs-similar/141694/4 "2020-02-15T23:36:00Z")

</div>

> [@codinghorror](#):
>
> それらすべては Discourse の要素であり、正常なセットアップを保証するために、Discourse がコンテナ内でそれらを制御する必要があります。

しかし、なぜそのようなコンテナを起動し、オーケストレーターとして機能する奇妙なブートストラップスクリプトが必要なのでしょうか？

なぜ Discourse イメージは環境変数を受け取り、エントリーポイントからそれらすべてのリソースにアクセスして必要なテーブルを作成するなどの処理ができないのでしょうか？外部の永続化層に依存する他のサービスや Web アプリは、このようにコンテナ化されて成功しています。それらを ECS や EKS などに投入し、データベースの場所などを指示するだけで、すべてがうまく機能します。Discourse でもこれは可能でしょうか？

> [@codinghorror](#):
>
> 複雑なマルチコンテナシナリオに入る場合は、それは資金を大量に持つ大規模な顧客にとってのみ _必要_ であり、当社のエンタープライズホスティングサービスをご参照ください。

私たちはその逆、つまり予算があまりない非営利組織であるからこそ、すべてのエンタープライズアプリを単一の AWS ECS ホストに集約することで、コストを可能な限り抑えたいと考えています。しかし、そのためには個々のアプリがきれいにコンテナ化され、ECS タスク定義として定義可能、つまり自己完結型の Docker イメージである必要があります。

---

_[View the full topic](https://meta.discourse.org/t/has-anyone-successfully-gotten-discourse-running-in-aws-ecs-similar/141694)._