先週に「全てのリージョンでECSに最適化されたAmazonLinux2イメージに対してSystemsManagerAgentをプリインストールされるようになった」とアナウンスがありました。
従来ではSSMエージェントをユーザーデータの記述でインストール・起動させてあげる必要がありましたが、最新のECSイメージを使用することでデフォルトでエージェントが立ち上がっている状態になります。
せっかくなので実際に最新のイメージを立ち上げて動作を見てみることにしました。
事前準備
ECS用のインスタンスにアタッチするロールに事前にSSMを扱うためのポリシーをアタッチしてあげる必要があります。
ポリシーのアタッチから[AmazonEC2RoleforSSM]をアタッチします。
EC2インスタンスで検証
本来であればAutoScalingグループからECSのインスタンスを立ち上げるべきなのですが、今回はECSの新規イメージを確認するだけなので通常のEC2インスタンスと同様の起動方法を取りました。
どちらの方法で立ち上げても実態は同じなので問題ありません。
EC2インスタンスのAMIを選択する際に「ECS」で引っかかるAWSロゴの入ったイメージを立ち上げたくなりますが、これは最新の最適化されたAMIではありません。
実際に立ち上げたところ、標準でSSMエージェントは立ち上がっていませんでした。
ECSに最適化された最新のAMIイメージはこちら(クリックで開く)から調べる必要があります。
公式ページからAMIのIDを調べて、コミュニティAMIから選択します。
AMIのIDはリージョンごとに異なるため注意してください。
画像はバージニアリージョンで立ち上げる場合のAMIです。
インスタンスを立ち上げる際に、ECSで使うためのロールをアタッチすることを忘れないようにしましょう。
万が一忘れてしまっても、後から個別でつけることが可能です。
従来であればユーザーデータの中にyumやsystemctlコマンドを記述してSSMをインストール・起動させる必要がありましたが、今回はその記述をしないままインスタンスを立ち上げます。
アクセスの確認
SystemsManagerを開いて左のメニューから「セッションマネージャー」を選択して「セッションを開始する」を押します。
もしも設定が間違っている場合には上記のような画面になってしまうため、設定を見直しましょう。
正しく設定ができている場合には上記のようにインスタンスの一覧が表示されます。
「セッションを開始」することでローカル環境からsshを実行することなくインスタンスの中を操作することが可能です。
docker execコマンドなどでコンテナの中身を見ることも可能でした。
EC2コンソールからもアクセス可能
どちらかというとEC2のコンソールから接続を実施するケースの方が多いかなと思いますが、もちろんこの画面からもセッションを繋ぐことが可能です。
[セッションマネージャー]を選択すると先ほどと同様にEC2インスタンスの中で操作が可能になります。
終わりに
今までは事前にSSMエージェントをインストールしておくか、ユーザーデータ内での記述が必要でした。
しかし最新のECSのAMIから立ち上げた場合にはデフォルトでSSMエージェントが有効になっている状態ですので、セッションによる接続設定の敷居が大きく下がったと思います。
普段からSSMエージェントを活用していれば、ローカル環境からsshを実施することなく不具合の調査や検証を行うことができます。
一方で、IAM権限の設定が不十分な場合にはEC2インスタンスの中身を操作して欲しくない人であってもセッションマネージャーから操作できるようになってしまう可能性があります。
運用をするに当たっては、その辺りもしっかりと考えて設定をしておいたほうが良さそうですね。
コメントを残す