はじめに

豊富な機能を持つことから、Systems Manager（以下、SSM）への苦手意識があったのですが、
先日、builders-flashで以下の記事を読み、少し見え方が変わりました。

読むと分かるのですが、SSMは結構便利そうで、楽しそうです！

今回はSSMの触りとして、
CloudWatchエージェントのインストールと設定を、複数のEC2を対象に一括で実行してみようと思います！！

やってみた

EC2を用意する

SSMで操作するための要件を確認する

まずはEC2を用意します。

EC2インスタンスをSSMで操作するためには、以下を満たす必要があります。
① SSMエージェントがインストールされている
② SSMやCloudwatchを操作するポリシーがEC2にアタッチされている
③ EC2から外部インターネットにアウトバウンドが可能である

また、これらの条件を満たし、SSMが操作可能なインスタンスをマネージドインスタンスと呼びます。

参考）

AMIの選定

いくつかのAMIでは、デフォルトでSSMエージェントがインストールしています。

参考）

今回はAmazonLinuxとUbuntuのAMIを使用してみます。

IAMポリシーの選定

必要なIAMポリシーですが、AWSマネージドのものが存在するので、それを利用します。

SSMエージェント用と、CloudWatchエージェント用の2つのポリシーをアタッチしています。

SSMで操作できるか確認

上述した設定で、EC2が作成できました！

SSMにはフリートマネージャーという機能があり、マネージドインスタンスの一覧が簡単にできます。

マネージドインスタンスとして表示されており、
SSMエージェントのインストールやポリシーなどに問題がなさそうなことが確認できました！

CloudWatch エージェントをインストールする

それでは、2つのマネージドインスタンスを一括操作していきます！
まずはエージェントのインストールからです。

SSM Run Commandを準備する

SSMでは、複数のマネージドインスタンスに一括で同じコマンドを実行するRunCommandという機能が存在します。
（OSが異なっていても一括で命令できるため、実際には宣言型の命令が可能なイメージ）

Run Commandをクリックします

目的のドキュメントを検索する

SSMでは、インスタンスへの命令は「ドキュメント」という単位で管理されています。
今回は、「AWS-ConfigureAWSPackage」というドキュメントを実行させます。

参考）

検索ボックスに「configure」を入力してフィルタしていきます

ドキュメントを選択すると、ドキュメントの説明が表示されます

ディストリビューターパッケージをインストールまたはアンインストールします。最新バージョン、デフォルトバージョン、または指定したパッケージのバージョンをインストールできます。AmazonCloudWatchAgent、AwsEnaNetworkDriver、AWSPVDriverなどのAWSが提供するパッケージもサポートされています。

よさそうですね！

Run Commandのオプションを設定する

Run Commandにはオプションを設定できます
ドキュメントによって、特定のインプット情報が必要だったり、
ドキュメントを問わず、結果をS3にアップロードしたりなど、です

installするパッケージ名に「AmazonCloudWatchAgent」を入力します
そのほかの設定はデフォルトのままで問題なさそうなので、次のオプションに進みます。

RunCommandの対象となるマネージドインスタンスを指定します。

今回は手で設定しましたが、タグやリソースグループ単位で指定できるのはかなり便利そうですね！！

その他のパラメータも埋めていきます。

S3へのアップロードがデフォルトで有効化されていましたが、不要に感じたので無効にしました。

その他の設定もデフォルトで無効になっており、問題はなさそうだったので、実行してみます！

Run Commandの実行結果を確認する

実行をクリックすると、RunCommandが正常に開始されました！

10秒ほど待つと、どちらのインスタンスもRunCommandが成功していることが確認できました

インスタンスIdが結果詳細画面へのリンクになっているので、クリックしてみます

フェーズごとに細かくログが確認できそうです！

ステップ2を確認してみます

アウトプットタブを開くと、無事CloudWatchエージェントがインストールできてそうです

他方のインスタンスも確認してみます

簡単！！凄い！！

CloudWatch エージェントの設定を確認する

RunCommandが成功しているのが確認できたので、インスタンスに接続し、設定状況を確認します。

参考）

Linux サーバーで、次のように入力します。
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status

インストールしただけで、まだ設定・起動は行っていないので、stoppedでnot configured 状態なのが確認できました
良い感じですね！

CloudWatch エージェントのログ配信設定を行う

同じくRunCommand機能を使ってCloudWatch エージェントのログ配信設定を行ってみます

参考）

CloudWatchエージェントの配信設定jsonを用意する

CloudWatchエージェントの配信設定は、jsonで定義されています
この定義用jsonを保存、使いまわすことで、複数のインスタンスに同じ設定でログなどを出力させることができます。凄い！

今回は以下のようなjsonを用意しました

config.json

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/apache2/access.log",
            "log_group_name": "/ec2/agent",
            "log_stream_name": "{instance_id}-access"
          },
          {
            "file_path": "/var/log/apache2/error.log",
            "log_group_name": "/ec2/agent",
            "log_stream_name": "{instance_id}-error"
          }
        ]
      }
    },
   "log_stream_name": "{instance_id}-default"
  }
}

/var/log/apache2/access.logに記載されるログを、「/ec2/agent」というロググループの、「{instance_id}-access」ログストリームに転送します

参考）

SSMパラメータストアでパラメータを作成する

設定jsonを複数のインスタンスでシェアできるように、SSMパラメータストアに保存します！

「パラメータの作成」をクリックします
（この文脈で触ると、secretを保存する機能ではまったくない感じがしますね・・・）

パラメータ名を入力します。他の値はデフォルトでよさそうです

jsonの値を入力します
作成ボタンをクリックします

パラメータが作成されました！
ではこのパラメータを使用し、再度RunCommandしていきます！

SSMドキュメントから実行するドキュメントを指定する

先ほどはRunCommand画面からドキュメントを指定しましたが、ドキュメントの一覧からRunCommand画面を呼び出すことも可能です

ドキュメントが一覧できます
今回は使用しませんが、StepFunction のような、Automationというドキュメントもあるそうです。楽しそう

「ManageAgent」でfilterし、目的のドキュメントをクリックします。

ドキュメントの説明や、コンテンツタブで動作の内容などが確認できます
「コマンドを実行する」をクリックします

RunCommandの画面に遷移しました。先ほどと違い、遷移元のドキュメントがすでに選択されています

Run Commandを実行する

実行のため、オプションを入力していきます

パラメータストア経由でコマンドの詳細を引き渡します
optionalConfigurationLocationに、先ほど作成したパラメータの名前を入力します

ターゲットを先ほど同様に指定します。

S3アップロードを無効化し、その他はデフォルトのまま、コマンドを実行します！!

ステータスが成功になりました！

プチ疑問

ステータス上は成功と表示されるのですが、実行結果詳細画面では以下のように表示されます。

OutPutにamazon-cloudwatch-agent has already been stoppedと表示されたり、
Errorに数行のログが出ていたり、少し不安です

問題ない旨を言及する記事がいくつかあったり、
動作には問題なく、実際のエージェントの起動にも成功しているのですが、少し気持ち悪いですね

Run Command実行結果を確認する

先ほど同様、インスタンスに接続し、CloudWatchエージェントのステータスを確認します

どちらも問題なく動いてそうです！！

ログ配信を確認する

インスタンスにapacheをインストールして動作を確認してみます

ログが転送されていることが確認できました！！

これでCloudWatchエージェントのインストールと設定を、複数のEC2を対象に一括で実行できました、楽で簡単でした！！

プチやらかし

ひとえにapacheサーバーと言っても、ディストリビューションによって使うパッケージやインストールするぷろっグラムが違うことを初めてしりました。

今回の設定だと、apache2をインストールするubuntuインスタンスはアクセスログがCloudWatchに配信されますが、
httpdをインストールするAmazonLinuxインスタンスはアクセスログの場所が異なるため、別途設定を行う必要があります

今回は動作確認のため、メチャクチャ汚くテストしました・・・

おわりに

実際に触ってみることで、SSMへの恐怖感が少し紛れました
SSMを忌避していた理由の一つに、機能の多さ・機能の一貫性のなさ（個人的感想）があるのですが、
少しずつ慣れていければな、と思います。