タグ: exec

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

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

    はじめに

    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を利用してコンテナにログインできない原因は、タスク定義における pidModetask に設定されているためであると判断しました。

    pidMode の設定変更

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

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


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

    参考情報

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

    まとめ

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