AWS Systems Manager Automation（オートメーション）を使ってみる【実践編】
前記事の続きです。この記事では、AWS Systems Manager Automation（オートメーション）の具体的な活用例として、複数のインスタンスの停止と、インスタンスタイプの変更作業を自動化させる方法を説明します。オートメーションの概要について知りたい方は、前記事をご確認ください。
この記事の目次
実践するAWS環境の概要
AWS Systems Manager Automation（オートメーション）を活用するには、通常作り込んだ運用シナリオを必要とします。しかし、文字数が多すぎると普段から指摘頂く筆者なので、読者を寝かさないように、オートメーション以外のAWS Systems Maneger（SSM）の機能は必要最低限にしたシンプルな内容を試してみます。
ランブックの準備方法は以下の二つがあります。
- 方法１：予めAWS側で用意されたランブックを使用する
- 方法２：ユーザ自身で作成したランブックを使用する
今回は、方法１で「インスタンスの自動停止」、方法２で「EC2で作ったサーバのインスタンスタイプの変更」の実行の手順を簡単にご紹介します。
（もう！ランブック作成の詳細だけでブログがもう一本作れます。とにかく機能が多い、手順によっては考慮事項も多い）（編集者注釈：今度書いてもらうつもりです）
オートメーション開始前の事前準備
オートメーションを始める事前準備として以下の設定をしました。
- VPCは、デフォルトのままで準備しました。
- EC2インスタンスは、T3.Microで２台用意し起動しています。
- IAMロールは、SSMの関連の権限付与し、ベタに“AutomationServiceRole”という名前で登録しました。
SSMのサービスなので、EC2インスタンスもランブックで作れますが、今回は前記事で詳細説明をした内容の実施をします。
インスタンスの自動停止
ランブックを作成し、その後モニタリング画面でインスタンスが停止されているか確認を行います。
ランブックの作成
①Systems Manager のメニューから共有リソース→ドキュメントを選択、左上のAutomation Documentsにチェックを入れ、AWS作成のランブック一覧から以下を見つけます。（stopEC2instanceで検索すると複数でます。）
②画面中部のAWS-StopEC2nstanceを実行するため、この名称のリンクを選択後、以下の実行画面に遷移します。
③実行画面右上の「オートメーションを実行する」を選択します。EC2の画面に行くと、以下のようにサーバが２台稼働していることが確認できます。
④ランブックの実行中画面に戻ります。こちらでも２台のインスタンスが稼働していることが確認できます。事前準備で制作したロールも設定されており、このロールにはSSMで利用可能な権限設定などが付与されています。右下の「実行」（Excurse）を選択すると、そのランブックが実行され、モニタリングの画面に遷移します。
ランブックが実行されているかモニタリングする
モニタリング画面に遷移後、少し待ってから、「Status」の欄を見ると
２台とも停止作業を実行することができました。
EC2の設定画面で確認しても、停止しています。
以下のようにオートメーションのトップ画面には実行の成功が記録されます。リンクをクリックすれば、結果はいつでも表示できます。
EC2で作ったサーバのインスタンスタイプの変更
ユーザ自身でランブックを作成する
インスタンスタイプの変更が可能なAWS提供のランブックが見つからないので、ユーザが自己所有のランブック作成を試みます。（よく探せばあるのかも・・）
準備
「インスタンスの自動停止」で使用したのと同じEC2のインスタンスを使います。T3.microは無償ではないので、お金のかからないインスタンスに変えることを今回の目的です。
実行のためのタスクの洗い出し
EC2で作ったサーバのインスタンスタイプの変更を実行するにあたって必要なタスクは以下の通りです。
- インスタンスを起動したままなので、手順実施時に停止。
- SSM実行時、インスタンスタイプの変更に必要な権限の付与
- ランブック実施時にインスタンスタイプを自由に指定可能にする
- インスタンスの起動
- 各タスクの失敗時の設定を記述し、上記各タスクとも未完了なら、停止にする
ランブックを作成する
「実行のためのタスクの洗い出し」で並べたタスクを順番通りに実行できるよう、ランブックを作成していきます。コードでババッと書いて行ければカッコよいですが、今回はデザイン画面で試行錯誤しながら以下作成しました。
デザイン画面で制作後、EC2の画面で実行中のインスタンスタイプを確認します。現在はT3.microです。上司に経済観念をアピールしたいので、とっととインスタンスタイプをダウングレードします。（編集者注釈：突然のアピールで困惑しています）
ランブックの実行
変更するインスタンスタイプとロールを設定
今回デザイン画面内で作業待ち（Wait）を設定したので、ランブックを実行した後も作業が一度止まっています。「Execute」を選択して実行開始すると、画面が変わります。
デザイン画面で設定した②〜⑥まで進捗が表示されていきます。ここではEC2が起動した状態のため②の状態チェックは失敗し、ランブックのデザインの通り動作が③に移ります。
結果を確認する
①下の画像は、オートメーションのトップ画面です。完了するとExecution ID以降の行が増えていきます。失敗も成功もExecution IDの名前の欄をクリックすれば、実行結果に戻ります。
②ところで、気になるインスタンスタイプの結果も確認しましょう。
EC2画面で確認します。インスタンスタイプ変更後の起動は時間を要します。
上記実行指示どおり、無事（？）SSMAuto1は変更されていました。インスタンスタイプもT3.microからT2.microに変更されました。SSMAuto2も同様にt2.microに変更したいと思います。
実際に利用する
実際に利用する際は、AWS標準ランブックに各種パラメータを設定して行います。用途に応じて、ロールの設定はもとより、他に必要な項目を用意します。
インスタンスやAMIに付与されたIDやARNなどを控えておき、設定します。S3ならバケット名の設定が必要です。
まとめ
今回使用したオートメーションはAWS Systems Maneger(SSM)サービスの１機能です。
SSMを中心に、その他サービスを使うことで高い拡張性をもって運用手順の自動化ができます。
しかし、オートメーションは実行手段を持たないので、SSMエージェントの導入や、IAMロールの権限追加、インスタンスの知識が必要です。
既存環境で必要なAWSサービスの追加した環境なら、オートメーションのみでランブック作成に移り、容易にオートメーションが試すことができるでしょう。
記事を書くのにあたって、様々なことを調べましたが、S3のバケットの用意をすることで、ファイルサーバのユーザ事故防止や、各インスタンスの運用やバックアップ自動化などにも大いに貢献できる、便利なサービスだと所感をもちましたね。
