はじめに
AWSハンズオン for Beginnersシリーズとして提供されている「AWS Hands-on for Beginners AWS Systems Managerを使ったサーバ管理はじめの一歩編」を実施した際のメモです。
EC2インスタンスを管理する場合、インスタンス毎のログイン情報やパッチ適用状況の確認、パッチの適用操作、インストールされているOSSのバージョンなど多くの管理作業が必要です。インスタンスの数が増えてくるとこの作業が大きな負担となります。
AWS Systems Managerは上記の作業を一括で自動で行うことができるサービスです。なお、このサービスはオンプレのサーバも管理対象にできます。
本ハンズオンではEC2インスタンスを立てて、そのインスタンスのインベントリ情報を収集、表示してみたり、コマンドを複数インスタンスに対して一括実行といったことを体験します。
アジェンダ
- 本ハンズオンの概要、サーバ管理における課題、AWS Systems Managerとは
- ハンズオンの事前準備
- Systems Manager環境のセットアップ
- SSM Agentの自動更新とインベントリデータの収集
- Session Managerを使ったサーバ接続
- Run Commandを使ったコマンド実行
- リソースの削除、本ハンズオンのまとめ
メモ
ゴール
- Systems Managerを使用したサーバ管理の基本を理解します。
- ハンズオンを通して、サーバ管理に必要な設定を理解します。
- ユースケース別にSystems Managerを活用するイメージを持ちます。
サーバ管理における課題
管理するサーバが多くなるほど、管理項目が増え、管理負荷が増大します。
例えば、サーバの接続情報、脆弱性を持ったバージョンのサーバ対応、パッチ適用などを把握、対応する必要があります。
Amazon Systems Manager
前述の課題に対応するAWSのサービスがAmazon Systems Managerです。
Systems Managerには
- グループ化
- 可視化
- 対応
の大きく3つの機能があり、AWS環境で動作するサーバを管理します。（オンプレ環境のサーバも管理可能です）
機能郡には
- ノード管理
- 運用管理
- アプリケーション管理
- 変更管理
の4つがあり、それぞれ複数のサービスがあります。
以上の機能、サービスでサーバ管理の手助けをしてくれます。
マネージドサーバ
Systems Managerでサーバを管理するにはそのサーバを管理対象のサーバを意味する「マネージドサーバ」にする必要があります。具体的には3ステップが必要です。
- サーバにSSM Agentをインストールします。なお、SSM Agentは最新のインスタンスタイプ( Amazon Linux)にインストールされています。
- Systems Managerとの通信経路を確保します。具体的には、NAT Gateway+Internet Gateway（インスタンスからインターネットへのアクセス経路）、または、VPCエンドポイント（通信がインターネットを経由させたくない場合）を使用します。
- サーバにSystems Managerを操作するIAMロール（※）を付与します。（※）AmazonSSMManagedInstanceCoreポリシーを持ったIAMロールをサーバに付与する必要がある。
以上の3ステップが完了すると、サーバがマネージドインスタンスと判断され、Systems ManagerのFleet Managerからインスタンスを確認できます。
詰まったところ
最新のEC2コンソールからデフォルトのインスタンスタイプを選択し、インスタンスを作ったが、フリートマネージャーに表示されませんでした。
10分ぐらい待ったあと表示されていることを確認できました。
インスタンス起動直後には表示されず、10分ぐらいのタイムラグがあるようです。
SSM Agentの更新
マネージドインスタンスにはSSM Agentがインストールされているので、当然そのバージョンアップ作業が必要です。Systems Managerの最新機能を使用するためにもバージョンアップは欠かせません。
Fleet Managerの設定タブからSSM Agentの自動アップデートを設定できます。
Inventory
Inventory機能でマネージドインスタンスのOS、インストールされているソフトウェアなどのバージョンや構成情報を収集、可視化できます。最短30分間隔で収集できます。
また、検索機能も持ち、特定のバージョンをインストールしているインスタンスの検索などもできます。
State Manager
StateManagerはSystems Mangerで定義された状態を保つためのプロセスを自動化する機能です。
例えば、上述でSSM Agentの自動更新設定やInventory定期収集設定を行いました。これらは設定時にStateManagerによって登録されています。登録された設定は、マネージドインスタンスが新規登録時に自動実行され、新規インスタンスの状態のSSM Agentの自動更新設定やInventory定期収集設定が既存インスタンスと同じ設定になります。
Session Manager
課題にあったように大量のインスタンスが存在すると、インスタンスの接続情報の管理が煩雑になります。場合によっては踏み台サーバが必要となり、踏み台サーバのスペックを検討したり、踏み台サーバ自体の管理が必要となります。
また、インフラ構成によっては社内からのSSHが禁止されていたり、VPN、Direct Connect経由の接続のみ許可している場合があり、容易にインスタンスにログインできない場合も考えられます。
Session Managerを使用すると、IAMでの認証ができ、認証情報管理が不要となります。さらに、踏み台サーバなしでプライベートサブネットのインスタンスにSSH接続もでき、インバウンドポートの解放も不要になります。
何故ポートの解放が不要？
マネージドサーバはSystems Managerにアウトバウンド通信できます。Session ManagerはSystems Mangerを経由して、マネージドサーバから接続を要求できます。そのため、インバウンドポートの解放なしに接続ができます。
操作ログの記録
Session Manager接続後の操作をCloudWatch Logsに記録できます。なお、Session Managerからセッションを開始するようなAWSコンソール上の操作はCloud Trailに記録されます。
手順はまず、EC2インスタンスのIAMロールにCloudWatchLogsを操作できるポリシーを付与します。
次に、Session Managerの設定で、ログを記録するCloudWatch Logsのロググループを設定すればリアルタイムに操作ログを記録できます。
Run Command
課題として、複数のサーバに対して同じコマンドを実行したい場合がある。例えば、複数のサーバに同じOSSをインストールするため、同じyumコマンドを実行するなどです。
Run Commandによって、これらを実現できます。
Shellを実行する場合、SSMドキュメントであるAWS-RunShellScriptを選択します。コマンドの実行結果はマネジメントコンソール、または、S3に出力ができます。ただし、前者の場合、表示できる文字数に制限(48000文字)があるので、それを超える可能性があるなら、後者を使用すべきです。
ハンズオンの感想
本ハンズオンでSystems Managerを使用したことと、弊社で行っている運用を思い起こしてみることで、その便利さをよく理解できました。
Systems Managerは今回使用した機能以外にも多数の機能があり、それを使用することでサーバー管理の運用を効率化できます。
実運用に利用されることでどれほど楽になるかを想像しながら、その他機能も試してみたいです。