AWS SSMで他クラウドのVMを管理する

管理できているようでできていないVM。

「誰のアカウントがあるの？」「インストールされているパッケージのバージョンは？」「急にネットワーク使用量が多くなったりしていない？」

数が多くなってくると1つずつ調べて回るのも手間なので、AWS Systems Managerを使ってみることにしました。オンプレミスのサーバにも対応しているので、AWS以外で動いているクラウドのサーバも管理対象にできます。

VirtualBoxのサーバを管理対象にしてからハンズオンをやってみる
パッケージの確認はフリートマネージャーで
パラメータストアを使う
1. AWS CLIをRunCommandでインストールする
2. AWS CLIの設定ファイルを展開する
サーバの管理も、センシティブな情報の管理も

VirtualBoxのサーバを管理対象にしてからハンズオンをやってみる

Systems Managerは機能が豊富なので、まずはハンズオンで触ってみるのが良さそうです。

https://pages.awscloud.com/rs/112-TZM-766/images/20200417_AWSSystemsManagerHandson.pdf

AWS EC2に環境を作って試すのがよさそうですが、あえて手元のVirtualBoxに入れたCentOS 7のサーバを対象にしてみました。オンプレミスのサーバを管理する場合、課金しないと使えない機能もあります。無料でどこまで管理できるのか、ハンズオンで確認することにしました。

オンプレ用セットアップ

オンプレ用のセットアップドキュメントが用意されています。

ハイブリッドおよびマルチクラウド環境に Systems Manager をセットアップする - AWS Systems Manager

ハイブリッドおよびマルチクラウド環境で使用する非 EC2 マシンを設定および管理するために Systems Manager をセットアップします。

専用のIAMロールを作ってから、SSMのハイブリッドアクティベーション画面でアクティベーションを作成→オンプレサーバにインストールしたssm agentにセットする
という流れです。

ステップ1はAWSを使うための手順なので、ステップ2からやっていきましょう。SSMRoleForOnPremiseというIAMロールを作りました。付与しているポリシーはAmazonSSMManagedInstanceCoreです。

Systems Managerのハイブリッドアクティベーションのメニューから、アクティベーションを作成します。
※アクティベーションの作成を行ったことがある場合とない場合とで、画面が変わります。が、「アクティベーションの作成」のボタンは、どちらの場合も表示されます。

アクティベーションの作成をクリックします。

IAMロールは、先ほど作ったカスタムIAMロールを選択します。
アクティベーションの有効期限は、設定しないと24時間です。
画面下部のアクティベーションの作成をクリックすると、画面が更新されてActivation CodeとActivation IDが表示されます。この2つは必要になるので、メモしておきます。

オンプレのサーバにSSM Agentをインストールします。ステップ4です。

手順に従ってアクティベーションのcodeとidをセットします。

instance id mi-019138faf02796bcdが割り当てられました。
Systems Managerのフリートマネージャーで見てみます。

ノードIDに割り当てられたinstance idがありました。ハンズオンの4まで終了です。

セッションマネージャーは有料機能

ハンズオンの5にあるセッションマネージャー、オンプレミスのサーバーに対しては、有料の機能です。

sshでサーバにログインする替わりに使えて便利そうではあるのですが…。

RunCommandは複数のサーバへ同時にコマンドを投入できる

ハンズオンの6のRunCommand。セッションマネージャーで1台1台操作する替わりに、複数のサーバーに対して同時にコマンドを流し込めます。管理対象のサーバーが多い場合、これだけでも嬉しいのではないでしょうか？

パッケージの確認はフリートマネージャーで

ハンズオンでは触れられていませんが、フリートマネージャーを使うと、インストールされているパッケージのバージョンや、サーバー上に作られているユーザーアカウントを確認することができます。

フリートマネージャーで対象のノード(サーバー)を選択します。

インベントリを選ぶと、インストールされているパッケージが表示されます。

また、画面左の「ツール」から「ユーザーとグループ」を選ぶと、サーバー上のユーザーとグループが表示されます。

パラメータストアを使う

意外と使えそうな機能が、これです。
メンテナンスscriptからawsコマンドでパラメータストアのデータを取得することが可能になります。ですので、script中にIDやパスワードといった情報を埋め込まずに済みます。

AWS CLIをRunCommandでインストールする

CloudWatch Agentなどは、AWS-ConfigureAWSPakcageというドキュメントを使ってRunCommandでインストールできるのですが、AWS CLIについては見つけられませんでした。
わざわざSSMを使わなくても、AWS CLIをインストールして適切なIAMロールを割り当てたユーザーのクレデンシャルでセットアップすればいいのですが、台数が多くなってくると結構面倒な作業です。ですので、AWS-RunShellScriptというドキュメントを使ってインストールします。

Run CommandとAWS-RunShellScriptについては、ハンズオンの6に出てきます。
RunShellScriptは「コマンドのパラメータ」に実行すべきコマンドを並べればいいので、インストール手順を参考にします。

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install

※RunCommandはrootユーザで実行されるので、sudoは不要です。

Working Directoryは/tmpにしておきます。

画面右下の「実行」をクリックして、実行させます。

AWS CLIの設定ファイルを展開する

設定ファイルがないとaws cliは使えません。
aws –configure で1台ずつ設定していくのも大変なので、Run Commandで展開します。

AWS CLIの設定ファイルを見ると、configとcredentialsの2つから構成されています。credentialsには秘密にすべき情報が含まれているので、AWS-RunShellScriptに直接記述するわけにはいきません。
そこで、パラメータストアを使います。

※awsやssmで始まる名前は付けられないので、注意。

「安全な文字列」を選択して、値にcredentialsファイルの中身をそのまま書きます。

Run CommandのAWS RunShellScriptのパラメータは、下記のようにしました。jqコマンドが必要です。

TARGET=対象ユーザ
TARGET_DIR=対象ユーザのホームディレクトリ
cd $TARGET_DIR
su - $TARGET -c "mkdir .aws"
su - $TARGET -c "echo -e '[default]\nregion = ap-northeast-1' > .aws/config"
/usr/local/bin/aws ssm --region ap-northeast-1 get-parameter --name パラメータストアに入れたcredentialの名前 --with-decryption | su - $TARGET -c "jq -r '.Parameter.Value' > .aws/credentials"
su - $TARGET -c "chmod og-r-w-x .aws/*"

suの動きが若干違うようで、注意が必要です。AWS Systems Manager ドキュメントを使うときに知っておきたいこと | DevelopersIO が参考になります。

このコマンドドキュメントをRun Commandで実行することで、対象ユーザがawsコマンドでパラメータストアにある値を読み取れるようになります。