電磁波に撃たれて眠りたい！

今日も電磁波浴びまくりのIT業界で働く@mamohacyがガジェット/クラウド/IT業界を語ってくブログ

トップ > AWS > 【AWS re:learning】Day3(1/1) AWS Systems Manager

【AWS re:learning】Day3(1/1) AWS Systems Manager

AWS AWS re:Learning

f:id:mamoahcy:20201231013855p:plain

【2021.01.01更新】DevelopersIOの記事数情報に間違いがあったため訂正

3日目にして既に1日遅れ。。。3日坊主にならいようになんとか踏ん張ります。それにしてもSSM、全容把握までしんどかった。。。

●調査情報リスト

①公式サイト：https://aws.amazon.com/jp/systems-manager/?c=mg&sec=srv
②ユーザーガイド：https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/what-is-systems-manager.html
③BlackBelt：https://www.slideshare.net/AmazonWebServicesJapan/20200212-aws-black-belt-online-seminar-aws-systems-manager
④DevelopersIO記事一覧：https://dev.classmethod.jp/referencecat/aws-ec2-systems-manager/
⑤リリースノート：https://aws.amazon.com/jp/new/?whats-new-content-all.sort-by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats-new-management-governance=general-products%23aws-systems-manager
⑥ドキュメント更新履歴：https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-release-history.html

●AWS Systems Manager サマリ

特定の条件を満たしたEC2を統合的に運用・管理できるサービス。ホスト単体への運用操作はもちろん、監査の定期実行や強制、インベントリ収集やダッシュボード機能なども備えた多機能なマネジメント管理コンソール。

管理対象となるホスト（マネージドインスタンス）にするためには３つの大きな制約条件がある

① SSMエージェントを導入する必要がある

AmazonLinux2やUbuntu、WindowsServerなど特定の条件を満たすAWS提供のAMIにはプリインストールされているが、それ以外のサポート対象OSには自前でSSMエージェントをインストールしておく必要がある。 　　詳細は以下参照

②ホストがSSMサービスと疎通できる必要がある。

Publicサブネットに置いてEIPあるいは自動付与のグローバルIPを当てるか、NATゲートウェイを通じてアウトバウンド方向の通信を通す必要がある（インバウンドは不要）

またはSSMのVPCエンドポイントを通じて疎通させる（オンプレ側とDXで疎通させる場合はこっち） 　　

③対象のEC２に特定のIAMロールを付与する必要がある

マネージドインスタンスとしたいEC2のIAMロールに、「AmazonSSMManagedInstaceCore」ポリシーを含むIAMロールを付与する必要がある。他にもあるがたとえば「AmazonSSMRoleForInstancesQuickSetup」ロールなどは上記ポリシーを含んでいる（高速セットアップについては後述）が、自前で他のポリシーとセットにしてロールを作るのがオススメ

逆にこの３つの条件を満たすことができれば、オンプレミスにあるサーバやVMホストもマネージドインスタンスに入れることが可能。

マネージドインスタンスに入れることができれば、そのホストのインベントリ情報を集めたり、パッチ適用状況やコンプライアンス準拠状況を調査することができ、さらにSSMエージェントを通じてリモートコマンドの実行（RunCommand）も可能である。

他にもいくつか統合運用管理ダッシュボードとしての機能がある。2020年12月30日時点でのメニュー構成にあわせ、以下順に説明する。

■高速セットアップ(QuickSetup)

マネージドインスタンスに対し、その後のSSMエージェントのアップデートやインベントリ情報などの収集を有効化したり、追加でCloudWatchエージェントのインストールやアップデートなどを予めルール化できる機能。

ターゲットとなるインスタンスを「すべて」「タグ指定」「リソースグループ指定」「手動指定」などから選べ、対象となるインスタンスが起動した時点で実行させることが可能になる。（セットアップの手動実行も可能）

f:id:mamoahcy:20201231014011p:plain

SSMでマネージドインスタンス必要となるセットアップを自動化できるという便利がある反面、実行時のDetailに記載されるエラーログがうすすぎて、エラーハンドリングがしにくいという課題がある

f:id:mamoahcy:20201231014038p:plain

■運用管理

エクスプローラー

マネージドインスタンスを含むEC2インスタンスるに関する情報を一覧表示できるダッシュボード。表示できるウィジェットをカスタマイズしたり、表示内容をフィルタリングしたりもできる。

OpsCenter

OpsItemと呼ばれる一覧の運用管理業務を作成し、それに該当するインスタンスとOpsItemの一覧などを表示できるダッシュボード。

たとえばEC2のメンテナンスウィンドウの実行に失敗しただとか、EBSのスナップショット取得に失敗したなど、ワークアラウンドが必要となる課題を定義しておけば、それが発生した場合にリストで表示することができ、ここからワークアラウンドとして後述する「自動化（オートメーション）」を実行させることができる

CloudWatchダッシュボード

CloudWatchから収集した情報をもとにグラフを表示できる機能。QuickSightの機能が使われていると思われる。

PHD(Personal Health Dashboard)

同名のAWSサービスからのサマリ（過去７日間の未解決の問題リスト等）埋め込まれている

■アプリケーション管理

Application Manager

別日に調査予定

リソースグループ

Application Managerに統合されたらしい。（メニューとしては残存。強制リダイレクトされる）

AppConfig

別日に調査予定

パラメータストア

SSMに限らずAWSの様々なサービスで利用できる外部パラメータストア。KMSで値を暗号化することも可能。

■変更管理

変更マネージャー

AWSConfigと統合されたホストとインフラの変更管理ワークフローを設定、管理できるメニュー。

AWS およびオンプレミスのアプリケーション設定とインフラストラクチャに対する変更を管理し、運用チームがリクエスト、承認、実装、およびレポートする方法が提供される。

自動化（Automation）

特定のAWSアクションを自動化するためのドキュメント（後述）を手動実行させたり、その結果を表示したりするメニュー。

カレンダーの変更

AWS アカウントの変更が可能またはブロックされる期間を指定します

メンテナンスウィンドウ

マネージドインスタンスのターゲットセットが更新をインストールしたりメンテナンス作業を実行したりする時間を指定できる。パッチ適用や独自のコマンドドキュメントを定期的に実行したりする際に使う。

■ノード管理

フリートマネージャー

元マネージドインスタンス。管理対象となっているホストの一覧表示と詳細表示が可能

コンプライアンス

予め設定したコンプライアンスに各ホストが準拠できているかを表示

インベントリ

マネージドホストのインベントリ情報を一括表示・個別表示できるダッシュボード。

マネージドインスタンス

フリーとマネージャーに統合

ハイブリッドアクティベーション

オンプレミスのホストを管理する際に必要となるアクティベーションコードを管理する

セッションマネージャー

マネージドインスタンスに対してSSMエージェントを通じてターミナル接続を可能にするサービス

これがあれば対象のホストに対してターミナルソフトウェアを使ってSSHをする必要がなく、またホスト側にもそのために必要なルートを開けるなどの必要もないためセキュアな運用が実現可能になる。

Run Command

マネージドインスタンスに対して予め設定されたコマンドドキュメントを実行させることができる。 予め設定されたコマンド以外にも、「AWS-RunShellScript」「AWS-RunPowerShellScript」といった独自拡張が可能なドキュメントもあり、その名の通りシェルを書いてリモートホストで実行し、その結果をテキストで受取ることができる。

ステートマネージャー

メンテナンスウィンドウと対をなすメニュー。メンテナンスウィンドウと違い、マネージドインスタンスを常に同じ構成で維持させたり、あるいはコンプライアンスレポートを作成したりといった際に使う。

パッチマネージャー

マネージドインスタンスにおけるパッチ適用の自動化が行える

ディストリビューター

独自のソフトウェアリストをパッケージ化し、SSMを通じて対象のホストにインストールさせることができる

■共有リソース

ドキュメント

セッションマネージャやRunCommand、Automationなどで利用するスクリプト定義を行う

●温度感調査

Developers IO パラメータ

記事数：125
最終更新日Top3： 2020.12.25 → 2020.10.27 → 2020.09.13

膨大な数の記事と更新頻度！

サービスアップデート状況

https://aws.amazon.com/jp/new/?whats-new-content-all.sort-by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats-new-management-governance=general-products%23aws-opsworks

2020/12/22　AWS Systems Manager でランブックのさまざまなバージョンを比較
2020/12/21　AWS Systems Manager で、Automation Runbook 実行による高度なフロー制御が可能に
2020/12/15　AWS Systems Manager の Application Manager 機能を使用して、Amazon EC2 で Microsoft SQL Server ワークロードを管理する
2020/12/15　AWS Systems Manager Change Manager のご紹介
2020/12/15　AWS Systems Manager Application Manager のご紹介

2020年内のサービスアップデートアナウンス：52

ドキュメントアップデート状況

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-release-history.html

October 22, 2020　Ubuntu Server 20.10 のサポート
October 21, 2020　新しいトピック: 設定可能なシェルプロファイルを有効にする
October 20, 2020　パッチコンプライアンスの結果により、どの CVE がどのパッチによって解決されるかが報告されるようになりました
October 16, 2020　Linux パッチメタデータのサポートの拡張
October 15, 2020　新しいトピック: セッションドキュメントスキーマ

2020年内ドキュメントアップデート回数：71回

API バージョン: 2014-11-06

深堀りの有無

実施する

下記のDevelopersIOの記事を参考に様々な機能を試してみた。エラーが出ている箇所もあり、完全に解決できていない部分も多いが、マネージインスタンスに入れる必須条件や手順、各種ダッシュボードの意味、RunCommandの実行など、一通りの機能は試して感覚を掴む。

↓RunCommand実行
Amazon EC2 Systems ManagerのRun Commandをやってみた #reinvent | Developers.IO
https://dev.classmethod.jp/articles/esm-run-command/
↓StateManagerでのAssociationの実行
Amazon EC2 Systems ManagerのState Managerをやってみた #reinvent | Developers.IO
https://dev.classmethod.jp/articles/esm-state-manager/
↓インベントリ収集
Amazon EC2 Systems Managerでインベントリ収集してみた #reinvent | Developers.IO
https://dev.classmethod.jp/articles/esm-collect-inventry/
↓パラメータストアを使ってRunCommand実行
Amazon EC2 Systems Managerでパラメーターストアを試してみた #reinvent | Developers.IO
https://dev.classmethod.jp/articles/esm-parameter-store/
EC2 Systems ManagerのRun CommandでWindowsUpdatesを実行してみた #reinvent | Developers.IO
https://dev.classmethod.jp/articles/installing-win-update-with-runcommand/

●所感

サービスアップデート量やドキュメント更新頻度、DevelopersIOの記事数や更新頻度などから見ても、AWSを軸にシステムを運用していくのには非常に便利なサービスであり、AWS側も相当力を入れていることが伺える。

ただ、個人的には下記の点がひっかかった。

  • 対象ホストに入れるための必須条件が以外に厳しい。(SSMエージェント導入＋SSMサービスへの通信経路確保＋IAMロール付与 or アクティベーションID付与）
  • パフォーマンスなどの詳細を見たければCloudWatchエージェントも入れなければならない
  • 高速セットアップのエラートレースがやりにくい
  • SSMそのものをまともに機能させるためには、SSMエージェント/CWエージェントの自動更新はほぼ必須

実際の運用にあたってはともかくもマネージドインスタンスとして登録させる必要があり、導入の条件が厳しい上に登録が完了するまでが一苦労。エラートレースがやりにくいために原因が掴めず、手探りですすめる以外なかった。実際の運用ではEC2ホストの起動にあたっての制限事項が多く、これを強制できるような運用体制にないとSSMでホストの統合管理するのは厳しい。

また結局このSSMというサービスはEC2あるいはEC2をベースとしたサービスのホスト運用に特化したサービスであり、これ単体でシステム全体の運用をカバーすることはできない。前述した「ホスト起動時の制約条件を強制できること」と合わせて、EC2ホストの管理をインフラ担当者が完全に掌握できる形での開発体制が組めないと、SSMでのホスト管理を成立させるのは難しいかもしれない。

ただ、エンタープライズにおいてはインフラ担当とアプリ担当が明確に分かれている場合が未だに多く、そういった体制で開発を行っている企業には有効的な運用手段の一つになる可能性がある。例えばオンプレミス側をベースに作られたレガシーシステムがAWS側にサービスエンドポイントをエンハンスしているような構成のシステムの運用であれば、オンプレ側のノードもすべてひっくるめてコンプライアンス管理やパッチ管理ができるので非常に有効的だ。またそのサービスがコンテナ上で動作していて、SRE担当が存在できるチーム構成であれば、インフラ運用者と組んでコンテナホストの維持管理にSSMを使うという方法も非常に有効的と考えられる。むしろこちらのほうが今っぽいやり方と言えるのかもしれないが、今後Generalなコンテナの管理がFargateに向かうことを考えると、使い分けを考える必要があるかもしれない。

いずれにしてもホスト特化型とはいうものの統合運用管理ツールとしては非常に優れたサービスであり、制約条件さえクリアできれば適用範囲も広く、特に体制分離がされているエンタープライズには活用の場面は多い。全社統合運用環境として使うのはちょっと厳しい気もするが、自社でも適用できる場面がないか引き続きセキュリティ運用を行っている部門と協業しながら検討を続けたい。

●参考情報

特に無し