aws

Amazon ECS Exec チェッカーを使用してもログインできない場合の対処

2024年8月6日

はじめに

Amazon ECS（Elastic Container Service）は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを簡素化するためのサービスです。しかし、ECS Exec機能を利用してコンテナにアクセスする際に、想定通りに動作しない場合があります。本記事では、Amazon ECS Exec チェッカーを使用しても異常が見られなかったが、依然としてログインできない場合の対処法について解説します。

調査したこと

以下の手順に従って、Amazon ECS Exec チェッカーを使用してテストを行いました。実行結果は以下の通りです。

https://github.com/aws-containers/amazon-ecs-exec-checker

$ ./check-ecs-exec.sh $cluster $task

-------------------------------------------------------------
Prerequisites for check-ecs-exec.sh v0.7
-------------------------------------------------------------
  jq      | OK (/usr/local/bin/jq)
  AWS CLI | OK ([xx]/aws)

-------------------------------------------------------------
Prerequisites for the AWS CLI to use ECS Exec
-------------------------------------------------------------
  AWS CLI Version        | OK (aws-cli/1.22.7 Python/3.7.2 Darwin/23.4.0 botocore/1.23.7)
  Session Manager Plugin | OK (1.2.463.0)

-------------------------------------------------------------
Checks on ECS task and other resources
-------------------------------------------------------------
Region : [xxx]
Cluster: [xxx]
Task   : [xxx]
-------------------------------------------------------------
  Cluster Configuration  | Audit Logging Not Configured
  Can I ExecuteCommand?  | [xxx]
     ecs:ExecuteCommand: allowed
     ssm:StartSession denied?: allowed
  Task Status            | RUNNING
  Launch Type            | Fargate
  Platform Version       | 1.4.0
  Exec Enabled for Task  | OK
  Container-Level Checks | 
    ----------
      Managed Agent Status
    ----------
         1. RUNNING for "postfix"
         2. RUNNING for "http"
         3. RUNNING for "composer"
         4. RUNNING for "log-router"
    ----------
      Init Process Enabled ([xxx]:241)
    ----------
         1. Enabled - "http"
         2. Enabled - "composer"
         3. Enabled - "postfix"
         4. Disabled - "log-router"
    ----------
      Read-Only Root Filesystem ([xxx]:241)
    ----------
         1. Disabled - "http"
         2. Disabled - "composer"
         3. Disabled - "postfix"
         4. Disabled - "log-router"
  Task Role Permissions  | [xxx]
     ssmmessages:CreateControlChannel: allowed
     ssmmessages:CreateDataChannel: allowed
     ssmmessages:OpenControlChannel: allowed
     ssmmessages:OpenDataChannel: allowed
  VPC Endpoints          | SKIPPED ([xxx] - No additional VPC endpoints required)
  Environment Variables  | ([xxx]:241)
       1. container "http"
       - AWS_ACCESS_KEY: not defined
       - AWS_ACCESS_KEY_ID: not defined
       - AWS_SECRET_ACCESS_KEY: not defined
       2. container "composer"
       - AWS_ACCESS_KEY: not defined
       - AWS_ACCESS_KEY_ID: not defined
       - AWS_SECRET_ACCESS_KEY: not defined
       3. container "postfix"
       - AWS_ACCESS_KEY: not defined
       - AWS_ACCESS_KEY_ID: not defined
       - AWS_SECRET_ACCESS_KEY: not defined
       4. container "log-router"
       - AWS_ACCESS_KEY: not defined
       - AWS_ACCESS_KEY_ID: not defined
       - AWS_SECRET_ACCESS_KEY: not defined

上記の結果より、Amazon ECS Exec チェッカーを使用しても異常は見られませんでした。

すべてのチェックが問題なくパスしていることが確認できました。

結論と対処法

Amazon ECS Exec チェッカーを使用しても異常が見られなかったにもかかわらず、依然としてECS Execを利用してコンテナにログインできない原因は、タスク定義における pidMode が task に設定されているためであると判断しました。

pidMode の設定変更

pidMode を task から container に変更することで、この問題を解決できます。以下の手順で設定を変更してください：

  1. タスク定義の確認と編集： AWSコンソールまたはAWS CLIを使用して、問題のタスク定義を確認します。タスク定義のJSON内でpidModeがtaskに設定されている箇所を見つけ、該当行を削除


  2. タスクの再デプロイ： タスク定義を更新後、新しいタスク定義を使用してタスクを再デプロイします。これにより、更新された設定が適用されます。
  3. ECS Execの再試行： 設定変更後、再度ECS Execを試行して、コンテナへのアクセスが可能か確認します。

参考情報

https://github.com/aws/containers-roadmap/issues/2268

まとめ

Amazon ECS Exec チェッカーを使用しても異常が見られない場合でも、タスク定義の設定によってはECS Execが正常に動作しないことがあります。特にpidModeの設定に注意が必要です。本記事が、ECS Execのトラブルシューティングに役立つことを願っています。