1 Minute Tips

タグ: fargate

  • 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を利用してコンテナにログインできない原因は、タスク定義における 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のトラブルシューティングに役立つことを願っています。

  • fargate platform 1.4 で service を起動できない

    fargate platform 1.4 で service を起動できない

    今まで fargate で service を動かせていたが、platform 1.4 では動かせないことがあった。その対処法を紹介。

    pseudoTerminal option があるが、falase だと起動した後に停止してしまう。解決策としては、

    pseudoTerminal を false から true にすること。

    そもそも pseudoTerminal とは擬似ターミナル。

    Docker Remote API の コンテナを作成する際、セッションの TTy にマッピングして docker run にマッピングするオプション。

    1.3 まではこの設定が false でも動かすことができたが、1.4 ではこれを true にしないと動かすことができないようだ。

  • ECS(fargate) 起動時間をスケジュール設定する

    ECS(fargate) 起動時間をスケジュール設定する

    はじめに

    fargate でサービスを運用していて、夜間サービスを停止したい時がある。オートスケールの設定を流用することで、夜間停止を行うことができる。

    オートスケール設定

    aws application-autoscaling  \
register-scalable-target  \
--service-namespace ecs  \
--resource-id service/{cluster-name}/{service-name}  \
--scalable-dimension ecs:service:DesiredCount  \
--min-capacity 0  \
--max-capacity 1

    停止スケジュール
    (スケジューリング機能を使い、MinCapacity を 0 にする)

    aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweroff-hogehoge \
--schedule "cron(00 10 ? * * *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=0,MaxCapacity=0

    起動スケジュール

    aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweron-hogehoge \
--schedule "cron(30 0 ? * MON-FRI *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=1,MaxCapacity=1
  • AWS batch + ECRなのか、fargate (EC2)なのか

    AWS batch + ECRなのか、fargate (EC2)なのか

    はじめに

    定期的にコンテナを立ち上げて処理を流したい。

    AWS batch + ECRというアプローチもあれば、fargate (EC2)でタスクスケジュールというアプローチもあります。

    それぞれメリットデメリットをまとめました。

    AWS batchについて

    aws batch 実態はEC2であります。
    CloudWatch Eventにより発火させることがユースケースとしては多いようです。

    AWS batchがEC2を起動して、コンテナをとってきて、、、という作業になるため、
    10分ほどかかる可能性があります。

    EC2のスポットインスタンスを利用することもできます。
    当然スポットインスタンスなので、突然処理が止まってしまう事もありますが、
    AWS batchには最大5回のリトライ設定も可能。
    jobのキューイング機能もあります。

    diskが難しくなったらEBSを増やせばよいというのも強みの一つです。
    ただし現状、EFSとかをattachできません。

    fargateについて

    retry処理はありません。
    AWS Step Functionsと組み合わせることができ、そちらでリロードすることは可能です。

    LambdaとLambdaを繋げるのに使われることが多いですが
    step functions にfargateを使うことで、ジョブをコントロールすることが可能です。
    fargateのdiskは10G それ以上増やすことは現状できません。

    AWS batch/fargate同じ部分

    fargate/EC2 ログは標準出力になります。

    コンテナの作成について

    AWS batchでもfargateでもdocker imageを作る必要があります。
    その作成のベストプラクティスについて

    現状のベストプラクティス

    CodePilpelineを使い以下のフローの中でコンテナのpushまで入れます。

    * source code
    * ビルド
    * デプロイ
    を一貫して行うことができます。

    実現しやすい方法

    コンテナ作れる人に適切にroleを設定します
    コンテナを作る環境を作り、そこでroleを付与します。

    creadenrial の管理

    タスクのところで環境変数で持てるので、
    そこで適当な文字を入れます(仮にAAAAA)。
    Secret manager に適当な文字(仮にAAAAA)と、実際のパスワードを記載することでcredential の管理が可能です。

    参考情報

    AWSについて体系的に学ぶことができるのでおすすめ。