目次
はじめに
こんにちは、クラウド事業部の山下です。
AWS Systems Managerの機能の中で、「変更管理」のカテゴリに分類される4つのサービスについて調査・検証を行いました。
後編ではChange CalendarとChange Managerの概要と設定手順について記載します。
前編ではオートメーションとメンテナンスウィンドウの機能について紹介しています。下記記事をご参照ください。
概要
Change CalendarとChange Managerとはどのような機能なのか、その概要について簡単に記載します。
Change Calendar
カレンダーを作成して、タスクを実行する/させないタイミングを制御することができる機能です。
手動でのカレンダーイベント作成に加えて、サードパーティーのカレンダーファイルをインポートすることができます。
※Googleカレンダー、Outlook、iCloudカレンダーがサポートされています。
Change Manager
AWSサービスやオンプレミスのインフラ、アプリケーションの設定に対する変更を安全に行うための変更管理フレームワークです。
作業者がAWSリソース変更等の処理のリクエストを作成⇒承認者がリクエストを承認⇒処理が実行される、という承認ワークフローにより運用上の変更が管理されます。
AWS Organizationsの管理下では複数のAWSアカウントの変更管理を行うことが可能です。
上記サービスのより詳細の説明は公式ドキュメントをご参照ください。
前提
- 検証で使用したEC2インスタンスは、SSM Agentが元々インストールされているAmazon Linux 2023のAMIを利用。
- EC2インスタンスはパブリックサブネットに配置。
- EC2インスタンスのIAMロールに SSMManagedInstanceCore のポリシーを設定済み。
- Systems Manager用のIAMロールは、前編のAutomation手順で作成したロールを使用。
- メール通知で利用するSNSトピックは作成済み。
- （Change Manager）承認者のIAMユーザーは作成済み。（AmazonSSMAutomationRoleを設定済み）
試してみた
Change Calendar
カレンダーイベントの作成
まずは手動でイベント作成する方法を試してみます。
Systems ManagerのChange Calendarに移動し、「カレンダーの作成」を押下します。
カレンダータイプを以下から選択します。
- デフォルトで開く：イベントが作成されている期間中は、タスク実行がブロックされる。
- デフォルトで閉じる：イベントが作成されている期間中に、タスク実行がされる。
今回は「デフォルトで開く」を選択しました。
画面下部の「カレンダーの作成」を押下します。
作成したカレンダーを開いたら、まずタイムゾーンを Asia/Tokyo に変更します。
右上の「イベントを作成」を押下します。
任意のイベント名を入力し、イベント日時も設定していきます。
画面下部の「予定されたイベントを作成」を押下します。
作成したイベントがカレンダーに反映されていることを確認します。
カレンダーとオートメーションの連携
カレンダーイベントを作成した期間内でタスクがブロック、あるいはイベント期間でタスクが実行される様子を確認してみます。
Systems ManagerオートメーションのPreferencesタブに移動し、「Edit」を押下します。
「Turn on Change Calendar integration」をチェックして、作成したカレンダーを選択します。
カレンダー作成時に「デフォルトで開く」を選択しているため、イベント期間内にオートメーションを実行しようとするとブロックされるはずです。
任意のAWS事前定義ランブックを実行してみます。
デフォルトで開く（＝イベント期間内はCLOSE状態）であるため実行できないというエラーが表示されました。
カレンダータイプ「デフォルトで閉じる」に変更した状態で、再度オートメーションを実行してみます。
今度はイベント期間内のみタスク実行可能な状態になるため、問題なく実行できました。
Change Manager
続いてChange Managerで変更管理・承認ワークフローを作成してみます。
下記のような流れで変更テンプレートの作成・承認、変更リクエストの作成・承認を行います。
※今回の検証ではテンプレートもリクエストも同じIAMユーザーが承認者となっています。
テンプレート作成
まずは変更テンプレートを作成していきますが、初めにChange Managerの設定を変更します。
Systems ManagerのChange Managerに移動して、設定タブを開きます。
今回ユーザーID管理方法はIAＭを選択しました。
テンプレートレビュワー（テンプレート承認者）へのメール通知設定として、事前作成済みのSNSトピックを指定します。
テンプレート承認者のIAMユーザーを選択し、設定を保存します。
右上の「テンプレートを作成」を押下します。
任意のテンプレート名と説明を入力します。
テンプレートタイプは「標準変更テンプレート」を選択します。
今回はひとつのランブックを選択します。
テンプレート情報欄に、どんな目的で何を変更するテンプレートなのか等をマークダウン形式で記載することができます。
変更リクエストを承認するユーザーを指定できます。
複数人設定することもできますが、今回は１ユーザーのみ設定します。
変更リクエストが作成されていることを承認者にメール通知するSNSトピックも指定します。
画面下部の「保存してプレビュー」を押下します。
承認前のテンプレートが保存されている状態なので、「レビューのために送信」を押下してテンプレート承認担当ユーザー宛てに承認依頼を出します。
テンプレート承認ユーザーでログインして該当のテンプレートを開くと、承認／拒否のボタンが出ています。
承認を押下します。承認時にコメントを入力することもできます。
変更リクエスト作成
承認者の承認完了後、もともと作業していたユーザーで確認すると、テンプレートのステータスが「承認済み」に変わったことが確認できました。
テンプレートを選択した状態で「リクエストを作成」を押下します。
変更リクエストの名前と詳細を記載します。
ワークフロー開始時間は、承認者がリクエストを承認後すぐに実行されるよう選択しました。
承認後実際に変更タスクが実行されるタイミングをスケジュール指定することも可能です。
あらかじめ作成してあるSSM用のIAMロールを指定します。
単一のAWSアカウントで検証しているので、ターゲットの場所は「このアカウントに変更を適用」を選択します。
ターゲットリソースは「単一のリソース」を選択し、手動で対象インスタンスを選択します。
「次へ」を押下して確認ページにて内容を確認し、画面下部の「確認のために送信」を押下します。
承認ユーザーのSSM画面を確認すると、承認保留中のリクエストが表示されています。
リクエスト内で設定したSNSトピックへも、変更リクエストが作成された旨を通知するメールが届きました。
リクエスト名からリクエストの詳細が確認できるので、内容に問題がなければ承認を押下します。承認時にコメントを入力することもできます。
しばらくした後作業ユーザーでコンソールを確認すると、変更リクエストが承認されタスク実行が完了したことが確認できます。
詳細ページでは承認者のコメントも確認が可能です。
作成した変更リクエスト詳細ページの「タイムライン」タブを見ると、リクエストがいつ誰に承認されて、いつ処理が実行されたのかを時系列に沿って確認することもできます。
おわりに
後編ではChange Calendar、Change Managerについてご紹介しました。
今回は複雑なドキュメントやフローの作成は行っていませんが、実際にサービスに触れてみることで理解が深まったように思います。
まだ使ったことがないSystems Managerの機能は多数あるので、引き続き学習は続けていきたいと思います。
最後までお読みいただきありがとうございました！
お知らせ
APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。
その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp
https://www.ap-com.co.jp/service/utilize-aws/
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
