ec2のvirtualhostでドキュメントルートを設定して1つのインスタンスで複数のドメインサービスを運用するみたいに、ecsを使う場合でも1つのec2で複数のドメインのコンテナを並列で動かせるのでしょうか?
例えば、
hoge.com のコンテナA
fuga.com のコンテナB
この二つのコンテナを
ecsの1つのtask definitionにまとめて定義し、
1つのEC2で運用できるのでしょうか?
もしできるのであれば、やり方を教えていただきたいです。
理解が間違っていたらすみません。
※1つのコンテナAをecs・ec2で動かすところまではできたのですが、task definitionで二つ目のコンテナを追加しようとすると、ポートで80:80のところが重複してしまい、うまくいきません。
なんで1つのtask definitionにまとめたいんでしょうか?
普通に別々に作れば良いと思うのですが…。あまりメリットを感じません。
なるほどですね。ありがとうございます。
※運用するドメイン・コンテナの数が4~6位あるので、
1つのEC2にまとめられたらランニングコストが安くなるように思ったので
質問させていただきました。
インスタンスの台数に影響するのはECS Cluster のキャパシティプロバイダー戦略であって、task definitionではありません。
なのでtask definitionをまとめようが分割しようが関係ありません。
ECS Clusterで使っているEC2インスタンスが1台の場合、ポートの扱いがどうなのかは気になるところですが。
EC2インスタンスを1台にすることにこだわるならわざわざECSを使わずに普通にEC2上に構築してはどうでしょうか。
せっかくECSを使うことによってクラスターにできているのに肝心のクラスターが1台ではそのメリットが死ぬように思えます。
ECSを使うならスペックの低めのオンデマンドインスタンス1台+スポットインスタンス複数台(スケーリング)などの構成にするかFargateにしてFargate Spotを使うとかしないとクラスターのメリットを享受しきれないかと。
ありがとうございます。非常に参考になります。
アプリケーションによって使用しているフレームワークなどが異なり、それにより必要な言語のバージョンなどが異なる可能性が高いので
コンテナ化することで、各アプリごとに必要なミドルウェア・ソフトウェアで開発できるなど
幾つかメリットはあると考えておるのですが、コストに関しては概算でどれ位かかるのかを考慮して
おっしゃる通りEC2にまとめるのか、コンテナ化するのかジャッチするのが良いのではと思います。
コンテナ化するなと言っているのではなく、コンテナをEC2インスタンス上で複数動かせばいいのではないですか、と言っています。
フレームワークを使っているとなると複数動かすにはそれなりの性能が要求されると思いますが、そもそも必要スペックは見積もれているのでしょうか?
なるほどですね、承知いたしました。
現行の稼働状況を見ながらインスタンスタイプの目安は選定しております。
必要なインスタンスタイプがmicroとかmediumとかじゃなければせっかくのクラスターなのでそもそも1台で動かす必要もないかと思います。