AWS Systems Manager Quick Setup から EC2Launch V2 のデプロイが可能になりました

2023.06.20

同じ作業を複数台に実行する時、同じ作業を定期的に何度も実行する時、そんな時は自動化したい。それが人情というものではないでしょうか。

そんな私のために(?)、AWS Systems Manager(SSM) Quick Setup を利用して EC2 Windows で利用される EC2Launch V2 のデプロイが可能になりました。以前から SSM 機能群を用いて実現は可能でしたが、複数の設定が必要だった部分を Quick Setup を利用することで、簡単に設定することが出来ます。


引用: AWS Systems Manager ユーザーガイド - ドキュメント履歴

タイムリーに EC2Launch V2 を含む、EC2 の各起動エージェント(EC2Launch V2, EC2Launch V1, EC2Config, cloud-init, EC2 macOS Init)を自動更新するアップデートもありました!
(実は、最初こちらを今回の機能と混同してしまいました...指摘してくれたメンバーに感謝です)

そちらのアップデートは、すでに弊社メンバーが記事にしてくれているので、ご参照ください!

これで、本日時点(23/06/22)では Quick Setup Host Management と Distributor のいずれでも CloudWatch Agent と EC2Launch V2 の設定が可能となっていますが、両者には、前者は「対応内容が豊富で EC2 に必要な設定を一気に管理・実行出来る」、後者は「実行周期の選択肢が30日以外にも選択出来る」といった違いがあります。要件に応じて使い分けるなどが良さそうです。

前置き

今回、登場する EC2Launch V2 と SSM Quick Setup については下記をご参照ください。

EC2Launch V2

SSM Quick Setup

事前準備

本日時点(23/06/20)、EC2Launch V2 の 最新バージョンは 2.0.1303 となります。

そのため 2.0.1303 以前のバージョンがインストールされている EC2 インスタンスを用意します。

PS C:\Windows\system32> & "C:\Program Files\Amazon\EC2Launch\EC2Launch.exe" version
2.0.1245
PS C:\Windows\system32>

Quick Setup 設定

Systems Manager >>> Quick Setup >>> 作成 >>> Distributor >>> 作成

今回、対象とする Amazon EC2Launch V2 agent を選択 >>> 作成

※ Windows に対するアップデートになるため、タグなどで Windows OS のみにターゲットに絞ることを推奨します。Linux を対象に実行すると失敗(Failed)扱いになります。

しばらくすると設定が作成されます。

3つの内容が実行されています。

  • 次のパッケージを設定します: Amazon EC2Launch v2 agent。
  • 設定済みパッケージを 30 日間に 1 回更新します。
  • Systems Manager Explorer を有効化します。

処理に対応するステートマネージャーは、下記の3つです。

EC2Launch V2 の更新は AWS-QuickSetup-Distributor-EC2Launch-Agent で実行されているため、ステータスが 成功 になっていることを確認します。

初回実行が完了しているため、EC2Launch V2 Agent のバージョンを確認します。

PS C:\Windows\system32> & "C:\Program Files\Amazon\EC2Launch\EC2Launch.exe" version
2.0.1245
PS C:\Windows\system32> & "C:\Program Files\Amazon\EC2Launch\EC2Launch.exe" version
2.0.1303
PS C:\Windows\system32>

無事に最新バージョンへ更新されています。次回更新は設定で指定した日数後になります。

さいごに

ドライバーやエージェントの追加や更新は、セキュリティや障害・不具合、新機能利用などの面から重要な運用作用の一つですが、なかなか大変なのが実情です。EC2Launch V2をはじめ、定期的に手動でのメンテナンスを実行されている場合は、今回の機能や冒頭で紹介した別記事の機能に置き換えることで、作業負担を減らすことが出来るのではないかと思います。一方で、自動的な更新に置き換えることで、管理する(当事者)意識まで薄れてしまい更新の失敗に気づかなかったり、それにより別の障害要因となってしまうケースもあります。そのため、作業は今回のような機能にどんどんオフロードしつつも、実行結果の監視や意図したバージョンへの更新確認といった管理する部分は、今まで通りチームの責任範囲とすることも自動化を行う際の大切なポイントではないかと思います。