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

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

データセンター設定・構築・運用
記事内に広告が含まれています。
スポンサーリンク

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

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

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

スポンサーリンク
スポンサーリンク

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コマンドでパラメータストアにある値を読み取れるようになります。

サーバの管理も、センシティブな情報の管理も

サーバにあるアカウント情報やインストールされているパッケージの情報を取得できるだけでなく、センシティブな情報をパラメータストアに格納することによって、サーバ上に配置せずに済むようになります。

すべての機能を使いこなそうとすると大変ですが、目の前の問題を解決できる機能から使っていくのでも十分役立ちそうです。

コメント

タイトルとURLをコピーしました