はじめに
Webアプリケーションなどの実行基盤としてECS(Fargate)を採用している事例がいくつかあると思います。
ECS(Fargate)とは何か？という部分については以下の記事を参照ください。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/AWS_Fargate.html
本記事では、実行中のFargateタスクの内部にECS Execを使って入り、いろいろ調査をする手法についてまとめようと思います。
なぜタスクの中に入るのか？
たとえばこんな事例があります。
- タスクがRDSに正しく接続できるか確認したい…。
- 実行中のタスクが、想定通りの環境変数を参照できているか確かめたい。
- アプリが読み込んでいる設定ファイルなどを、コンテナ内から直接確認したい。
特に１番目などは、アプリケーションの機能(画面や内部処理)がまだ全然出来上がってない状態で、とりあえずインフラ環境を構築した場合に、ECSとRDS間での疎通が正しく行えるかどうかという点で気になることが多いです。
そんなとき、ECS Execというコンテナにログインできる機能を使うことで、実行中のタスクとリソース間での疎通確認や、タスクに関する調査などを行うことができます。
前提
AWS CLIのセットアップが済んでいること
ローカルからAWS CLIのコマンドを叩けるようになっている必要があります。
導入がまだの場合は、以下を参考に実施してみてください。
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html
実行するECSサービスにおいて、「ECS Exec」が有効化されていること
サービスの設定で、「ECS Execをオンにする」にチェックを入れておきましょう。
タスクがSSM(System Manager)と通信できるようになっていること
ECS ExecはSSMを経由して接続するので、タスクが以下にアクセスできるようになってる必要があります。
- SSMエンドポイント
- SSM Messagesエンドポイント
- EC2 Messagesエンドポイント
タスクはプライベートサブネットで実行されているケースが多いと思いますので、その場合は外部へ通信できるよう、NATGWやVPCエンドポイントが必要です。
必要な権限を備えていること
ECSのタスクロールに以下の権限が必要なので追加しておきましょう。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
}
]
}
また、CLIで使用するクレデンシャルには以下の権限が必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecs:ExecuteCommand",
"ssm:StartSession",
"ecs:DescribeTasks"
],
"Resource": "*"
}
]
}
接続手順
上記をクリアしたら、実際にECS Execでタスクの中に入ってみます。
コマンドプロンプトを起動し、以下のコマンドを叩きましょう。
aws ecs execute-command --cluster <クラスター名> --task <タスク名> --container <コンテナ名> --command "/bin/bash" --interactive
以下のようになったら接続成功です。
The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.
Starting session with SessionId: ecs-execute-command-XXXXXXXXXXXXXXXXX
root@ip-10-0-xx-xx:/app#
RDSとの疎通確認を行う
せっかく入ったので、タスクがRDSとやり取りできる状態になっているかを確認してみましょう。
前提として、以下のようになっているか確認してください。
- ECSサービスのSG アウトバウンドルールに、RDSのSGが許可で設定されていること
- RDSのSG インバウンドルールに、ECSのSGが許可で設定されていること
疎通確認は、nc(netcat)というツールを使って行います。
ncについては以下を参照してください。
https://www.intellilink.co.jp/column/security/2015/070100.aspx
ncが入ってるかを確認します。
root@ip-10-0-xx-xx:/app# nc -h
なければインストールしましょう。
root@ip-10-0-xx-xx:/app# apt-get update && apt-get install -y netcat-openbsd
ncが入ってた or インストールしたら、以下のコマンドを叩いてRDSと疎通確認できるか確かめましょう。
<エンドポイント名>には、RDSインスタンスのエンドポイント名を入れてください。
ポート番号に関しては対応しているものを設定してください。(MySQLなら3306)
root@ip-10-0-xx-xx:/app# nc -vz <エンドポイント名> <ポート番号>
以下のように表示されたら疎通できてる証拠です。
Connection to <エンドポイント名> (10.0.xx.xx) <ポート番号> port [tcp/*] succeeded!
参照している環境変数を取得する
たとえばアプリケーションの画面上で「ステージング環境なのに開発環境用のデータが表示されてるぞ…」みたいな事象があったとします。
まあだいたいフロント側で設定しているリクエストURLが違ってた、みたいなのがオチですが、何かの間違いで違う環境変数を参照してしまい、誤ったデータベースに接続してしまっている…みたいなことが全くないとも言い切れないので、実行中のタスクが何の環境変数を参照しているかを確かめる手段についても触れておきます。
(ふつうは環境ごとにサブネットやVPCを分けるのでまずありえないはずですが…)
以下のコマンドを叩くと、タスクが参照している環境変数を取得できます。
2行目が実行結果です。
root@ip-10-0-xx-xx:/app# env | grep <環境変数名>
<環境変数名>=Staging
おわりに
これで、ECS環境におけるアプリのデバッグやトラブルシューティングが実施できるようになるかと思いますので、同じような環境で運用保守や開発などをされている方は覚えておくと役に立つかもです。
私もこの１年はずっとAWSによるインフラ構築がメインだったので、これを知ることができてかなり役立ってます。