タスク起動に失敗する原因は主に下記ですが、ここでは上記２つに関する事象に対応するための確認事項を記載していこうと思います。
- ネットワークエラー
- IAM権限不足
- リソース不足
もし、ECSを利用してみたが、タスクが起動しなくて困っているなどあれば、下記の内容を見て実際の環境で確認してみてほしい。
まず、エラーの確認
なにはともあれ、起動しなかったタスクのエラーログを確認しましょう。
停止されたタスクでのエラーの確認 - Amazon Elastic Container Service
ここに下記のメッセージが出ている場合は、デプロイしたアプリケーションが正常に動作していない可能性が高いです。
- Essential container in task exited
- Task failed ELB health checks
この場合、タスクは一度起動したが、アプリが落ちた or アプリのヘルスチェックが失敗しているので、アプリのログやLBのヘルスチェックの設定を確認しましょう。
これ以外の理由が記載されている場合は、下記に記載している内容が原因であることが多いです。
1. ECRやS3へアクセス可能か
ECSのタスク起動時には、指定されたコンテナイメージのPullを実行しています。そのため、イメージが格納されているリポジトリへのアクセス可能である必要があります。
イメージがPullできない状態でタスクを起動した場合、CannotPullContainerのエラーが発生し、タスクの起動に失敗します。
CannotPullContainer task errors - Amazon Elastic Container Service
もし、上記のエラーが発生した場合は下記リソースの確認を行うと良いです。
- Public IP
- Internet Gateway
- Route Table
- Security Group
- Nat Gateway
- NACL
ECRにイメージが格納されている場合は下記も確認しましょう。
- VPC Endpoint
- IAM Role
DockerHubなどにイメージが格納されている場合
DockerHubなどの外部レジストリにイメージが存在する場合は、基本的にはそのレジストリへ通信できる環境があればよいです。（プライベートレジストリを利用しているパターンは、後に記載）
もしエラーが出ている場合は、インスタンスがインターネットへアクセス可能かどうか確認する必要があります。
※EC2インスタンスを利用している場合は、パブリックIPが付与できないパターンがあるので注意（下記参照）
ステップ 2: ネットワークの設定 - Amazon ECS
もし、DockerHubなどでプライベートリポジトリにイメージが格納されている場合、下記ドキュメントに従って認証を実施できるようにしないといけません。
タスクのプライベートレジストリの認証 - Amazon Elastic Container Service
ECRにイメージが格納されている場合
ECRにイメージが格納されている場合、「タスク実行ロール」に、ECRに対してPullする権限が必要となります。
また、実際にイメージが格納されているS3バケット（arn:aws:s3:::prod-<REGION>-starport-layer-bucket/*）にもアクセス可能である必要があります。
さらに、VPC Endpointを構築しており、通信をVPCに閉じている場合は、下記2つのリソースに対して通信可能かどうか確認する必要があります。
- ECR (イメージが格納されているリポジトリ)
- S3 (
arn:aws:s3:::prod-**<REGION>**-starport-layer-bucket/*)
というわけで、下記の流れで確認しておくと良いです。
よくやりがちなのが、S3バケットへのアクセスをVPC Endpointのポリシーで制限してしまっているパターンなので要確認。
Amazon ECR インターフェイス VPC エンドポイント (AWS PrivateLink) - Amazon ECR
もし、上記で説明したエラーではなく、ResourceInitializationErrorが発生している場合は、この後の2つを確認してみると良いです。
2. CloudWatch Logsへの権限はあるか
ECSでコンテナのログをCloudWatchに転送しようとした場合、一般的にはawslogsを用います。（※S3やElasticSearchに直接転送したいなどの要件があればFirelensなどを利用）
awslogsはデフォルトではロググループを新規作成することは無いですが、これでは不便なのでオプションを指定してロググループを自動生成させる事がよくあります。
この場合、「タスク実行ロール」にはCreateLogGroupの権限が必要です。
上記の権限が存在しない場合は、ResourceInitializationErrorが発生するので、もしこのエラーが発生していたら見直してみると良いです。
awslogs ログドライバーを使用する - Amazon Elastic Container Service
なお、「タスク実行ロール」に一般的に付与するポリシーであるAmazonECSTaskExecutionRolePolicyには上記の権限は入っていないので、このエラーは発生しがち。。
また、LogsのVPC Endpointを構築している場合は、もちろんアクセス可能な設定になっているか確認する必要があります。
3. KMS, SSM, SecretsManagerへの権限はあるか
ECSのタスクに機密情報などを環境変数を介して渡す場合、Systems ManagerのParameterStoreやSecrets Managerを用います。
これらを用いる場合も「タスク実行ロール」に追加で権限が必要になります。詳しくはリンク先のドキュメントを参照してください。
こちらも、権限不足の場合、ResourceInitializationErrorが発生します。
Systems Manager パラメータストアを使用した機密データの指定 - Amazon ECS
Secrets Manager を使用した機密データの指定 - Amazon Elastic Container Service
繰り返し書いているが、こちらもVPC Endpointを構築している場合は、アクセス可能か確認する必要があります。
その他
もし上記を確認したが、解決しない or エラーメッセージが違うなどの場合は、下記のドキュメントを確認しましょう。トラブルシューティングの際に確認すべき事項がまとまっています。
Amazon ECS のトラブルシューティング - Amazon Elastic Container Service
※こちらの記事はnoteにも投稿しています。
ECSでタスクが起動しない場合に確認すべきこと