14

ECS に最適化された AMI を構築する EC2 起動構成があります。常に少なくとも 2 つのインスタンスを利用できるようにする Auto Scaling グループがあります。最後に、ロードバランサーを手に入れました。

ロード バランサーのインスタンス間でタスクを分散する ECS サービスを作成しようとしています。

ECS ロード バランシングのドキュメントを読んだ後、ASG が EC2 インスタンスを ELB に自動的に登録するべきではないことを理解しました。これは、ECS が処理するためです。したがって、私の ASG は ELB を指定していません。同様に、私の ELB には EC2 インスタンスが登録されていません。

ECS サービスを作成するときに、ELB を選択し、ecsServiceRole も選択します。サービスを作成した後、[ECS インスタンス] タブに使用可能なインスタンスが表示されません。また、サービスはタスクの開始に失敗し、非常に一般的なエラーが発生します...

リソースが見つからなかったため、サービスはタスクを配置できませんでした。

私はこれを約2日間行ってきましたが、どの構成設定が適切に構成されていないのかわかりません。これが機能しない原因について何か考えがある人はいますか?

2015 年 6 月 25 日の更新:

ECS_CLUSTERこれはユーザーデータの設定と関係があるのではないかと思います。

私の EC2 Auto Scaling 起動設定では、ユーザー データ入力を完全に空のままにしておくと、インスタンスはECS_CLUSTER「デフォルト」の値で作成されます。これが発生すると、「default」という名前の自動作成されたクラスターが表示されます。このデフォルト クラスターでは、インスタンスが表示され、予想どおり ELB にタスクを登録できます。タスクが ELB に登録されると、私の ELB ヘルス チェック (HTTP) はパスし、すべてがうまくいきます。

しかし、そのECS_CLUSTER設定をカスタムに変更すると、その名前で作成されたクラスターは表示されません。その名前でクラスターを手動で作成すると、クラスター内でインスタンスが表示されなくなります。このシナリオでは、タスクを ELB に登録することはできません。

何か案は？

4

6 に答える 6

13

同様の症状がありましたが、ログファイルで答えを見つけることになりました：

/var/log/ecs/ecs-agent.2016-04-06-03:

2016-04-06T03:05:26Z [ERROR] Error registering: AccessDeniedException: User: arn:aws:sts::<removed>:assumed-role/<removed>/<removed is not authorized to perform: ecs:RegisterContainerInstance on resource: arn:aws:ecs:us-west-2:<removed:cluster/MyCluster-PROD
    status code: 400, request id: <removed>

私の場合、リソースは存在していましたが、アクセスできませんでした。OP が存在しない、または表示されないリソースを指しているようです。クラスターとインスタンスは同じリージョンにありますか? 詳細はログで確認できます。

他の投稿への応答:

パブリック IP アドレスは必要ありません。

ECS サービスと通信するには、EC2 インスタンスに割り当てられた ecsServiceRole または同等の IAM ロールが必要です。ECS クラスターも指定する必要があり、インスタンスの起動中または起動構成定義中にユーザー データを介して実行できます。次のようにします。

#!/bin/bash
echo ECS_CLUSTER=GenericSericeECSClusterPROD >> /etc/ecs/ecs.config

新しく起動したインスタンスでこれを実行できなかった場合は、インスタンスの起動後にこれを実行してから、サービスを再起動できます。

于 2016-04-06T03:17:15.913 に答える
13

結局、私の EC2 インスタンスにはパブリック IP アドレスが割り当てられていませんでした。ECS は、各 EC2 インスタンスと直接通信できる必要があるようです。これには、各インスタンスにパブリック IP が必要です。コンテナ インスタンスにパブリック IP アドレスを割り当てていませんでした。なぜなら、すべてのコンテナ インスタンスをパブリック ロード バランサの背後に配置し、各コンテナ インスタンスをプライベートにすると考えていたからです。

于 2015-06-29T01:37:01.160 に答える
3

発生する可能性のある別の問題は、適切なポリシーを持つロールを起動構成に割り当てないことです。私のロールには、ここで指定されAmazonEC2ContainerServiceforEC2Roleているポリシー (またはポリシーに含まれるアクセス許可)がありませんでした。

于 2015-10-08T12:24:48.293 に答える
-1

私たちの場合、問題のいくつかの層があります。それらをリストして、追求すべき問題のアイデアを得ることができるようにします.

私の目標は、1 つのホストに 1 つの ECS を持つことでした。ただし、ECS では、VPC の下に 2 つのサブネットが必要で、それぞれに Docker ホストのインスタンスが 1 つあります。1 つのアベイラビリティ ゾーンに 1 つの Docker ホストだけを配置しようとしていたのですが、うまく動作しませんでした。

次に、他の問題は、サブネットの 1 つだけに、インターネットに面したゲートウェイが接続されていることでした。そのため、それらの1つは一般からアクセスできませんでした。

最終結果は、DNS が私の ELB に 2 つの IP を提供していたことです。IP の 1 つは機能し、もう 1 つは機能しませんでした。そのため、パブリック DNS を使用して NLB にアクセスすると、ランダムな 404 が表示されました。

于 2016-10-07T06:57:09.590 に答える