複数のポートを公開するサービスがあり、kubernetesで正常に動作しましたが、AWS ECSに移動しました。 Load Balancer経由でのみポートを公開できるようですが、Dockerが複数のポートを定義している場合でも、1つのポートを選択する必要がありますが、サービス/タスクごとに1つのポートに制限されています
Add to load balancer
ボタンを使用すると、1つのポートを追加できます。追加すると、2番目のポートを追加するボタンはありません。
2番目のポートを公開する2番目のプロキシサービスを作成するよりも良い回避策はありますか?
更新:私はfargateベースのサービスを使用しています。
これがいい回避策になるとは言えませんが、AWS ECSを使用してEjabberdを実行する必要があるプロジェクトで作業していましたが、サービスのポートをロードバランサーにバインドするときに同じ問題が発生しました。
私はterraformを使用していましたが、AWS ECSのこの制限により、2つのポートを公開することになっていたため、ポートの問題を解決するためにインスタンスごとに1つのコンテナーを実行することに同意します。
コンテナーに動的ポートを割り当てたくない場合、インスタンスごとに1つのコンテナーを実行する場合、ソリューションは確実に機能します。
ターゲットグループを作成し、コンテナの2番目のポートを指定します。
ECSクラスターのAutoScalingGroupsに移動します
ECSクラスターの自動スケーリンググループに新しく作成したターゲットグループを編集して追加します
つまり、2つのコンテナーにスケーリングする場合、インスタンスが2つあるため、新しく起動したインスタンスが2番目のターゲットグループに登録され、自動スケーリンググループがそれを処理します。私の場合、このアプローチは問題なく機能しますが、考慮する必要があることはほとんどありません。
ターゲットでプライマリポートをバインドしないでください。ALBサービスでプライマリポートをバインドすることをお勧めします。このアプローチの主な利点は、コンテナーがAWSヘルスチェックに応答しない場合、コンテナーが自動的に再起動されることです。ターゲットグループヘルスチェックではコンテナが再作成されないため。
Dockerコンテナーに動的ポート公開がある場合、このアプローチは機能しません。
AWSはそのようなシナリオを処理するためにECSエージェントを更新する必要があります。
インスタンスごとに複数のコンテナーを作成しているときにこの問題に直面しました。タスク定義で定義された同じポートを使用していたため、2番目のコンテナーは起動しませんでした。
私たちがしたことは、これらのコンテナーの上にアプリケーションロードバランサーを作成し、ハードコードされたポートを削除することでした。その下に事前定義されたポートを取得しない場合のアプリケーションロードバランサーの動作は、動的ポートマッピングの機能を使用します。コンテナーはランダムなポートで起動し、1つのターゲットグループに常駐し、ロードバランサーはこれらのポートにリクエストを自動的に送信します。
詳細はこちら こちら
AWS ECSは、同じECSサービス内で複数のターゲットグループをサポートするようになりました。回避策は必要ありません。これは、コンテナーの複数のポートを公開する必要があるユースケースに役立ちます。
現在、複数のターゲットグループを指定するサービスを作成する場合は、Amazon ECS API、SDK、AWS CLI、またはAWS CloudFormationテンプレートを使用してサービスを作成する必要があります。サービスが作成されたら、AWSマネジメントコンソールを使用して、サービスとそれに登録されているターゲットグループを表示できます。
たとえば、Jenkinsコンテナは、Jenkinsウェブインターフェースのポート8080とAPIのポート50000を公開する場合があります。
参照:
https://docs.aws.Amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html