Cloud Automatorはなにをやっているのか

こんにちは。okeeeです。

師走ですね。気がついたら以前にBlogを書いてから1年以上が過ぎていました。個人的に2017年は色々と激動な1年であっという間に過ぎていった気がします。1年前と変わったことは主食がブロッコリー+ハイボールになったこととAmazon Echoデバイスが4台に増えたことです。


さて、記憶にないのですが気がついたらCloud Automator Advent Calendar 2017にエントリーしていました。おそらく酔っているときに見つけて勢いでエントリーしたのでしょう。忘れたまま年を越してもよかったのですがリマインダーメールが来てたのでなにか書くことにします。

Cloud Automatorについて

今回のAdvent Calendarの1日目に @uchimanajet7 さんがとてもいい感じに緩いエントリーを上げてらっしゃるのでそちらをご覧ください。公式ページによると「豊富なプロジェクトノウハウ から生まれた AWS運用自動化の最適解」がCloud Automatorです。なぜCloud Automatorが必要なのか?については19日目に @idacchi さんが上げてらっしゃるエントリーがエモくてオススメです。

Cloud Automatorはなにをやっているのか

出来ることは公式ページを見ていただくとして、以前から疑問だったのが「Cloud Automatorはなにをやっているのか」です。Cloud Automatorの中の人のスライドがいくつか公開されています。
構成レビュー自動化はAWS Config Rules(※)、ジョブ自動化はAmazon SWFを利用(※)して実現されている模様です。
※いずれも資料公開時点の情報。

さて、Cloud Automatorの使い方としては、Cloud Automatorのアカウントを取得し、そのアカウントにAWSアカウントのIAM Access key / Secret keyを登録して、Cloud Automatorのコンソール上でジョブを設定して、各種AWSリソースの操作を自動化していく、という感じになります。

見てみる

IAM Access keyを使っている、ということはAWS CloudTrailでAPI呼び出しの内容を覗き見ることができるのでやってみました。

AWS CloudTrailの設定

CloudTrailコンソールの左側メニューの「認証情報」を選択し「認証の作成」をクリックします。
 認証情報の作成では「認証名」、CloudTrailのログを保存する「S3バケット」を指定し「作成」をクリックします。今回はサクッと見てみるだけなので他のパラメータについてはよしなに。
サクッとできました。
この後にCloud Automatorで色々操作したりジョブを実行したりすると指定した「S3 バケット」にログが出力されていきます。
このままS3に出力されるログを覗いてもいいのですがgz形式だったり都度ダウンロードするのが面倒なので、CloudWatch Logsへの配信を設定してCloudWatch側で中を覗けるようにします。

CloudWatch Logsへの配信設定

CloudWatch Logsへの配信設定もCloudTrailコンソールから設定可能です。
作成した認証情報の名前をクリックします。
設定の下の方にCloudWatch Logの項目があるので「設定」をクリックします。
クリックするとロググループの指定ができるので任意のロググループを入力して「次へ」をクリックします。
するとCloudTrailからCloudWatch Logsのロググループに配信するためのIAM Roleの設定になるのでよしなに入力して「許可」をクリックします。
元の画面に戻り、ロールの検証後に上記のような表示になります。CloudWatchコンソールに移動して配信対象に設定したロググループを見てみます。

いっぱいありますね。このままだと欲しい情報にたどり着けないので「イベントのフィルター」を指定して絞り込みます。ここで使うのはCloud Automatorに設定したIAM Access keyです。

見てみた


上記はCloud Automatorでジョブを作成中のログです。"DescribeInstances"を"ap-northeast-1"で実行していることがわかります。またuserAgentが"aws-sdk-ruby/1.67.0 ruby/2.4.2 x86_64-linux memoizing"となっており、Cloud AutomatorがRubyで開発されていることやLinuxインスタンスからAPIを実行していることなどがわかります。

こちらはWindowsインスタンスへのWindowsUpdateの実行ジョブを実施した時のログです。ssmに"SendCommand"を行っているようです。先のログと微妙にuserAgentが異なるのはなんなんでしょうか。

まとめ

とうことでCloudTrail + CloudWatch Logsを用いてCloud Automatorが裏側でどんなことをやっているのかを簡単に見ることができました。もっと色々やりたい場合はAmazon Elasticsearch Serviceにログをストリームで送っていい感じに可視化したり、Amazon AthenaやAmazon QuickSightを組み合わせて分析したりとAWSのサービスを組み合わせることで様々なことが実現できます。
またaccess keyを用いた3rd Partyのアプリケーション、サービスであれば同じ方法でどんなことをやっているのかを覗き見ることができます。
ちなみにCloud Automatorで使用しているAWSのAPIについてはこちらで公開されています。
https://github.com/CloudAutomator/iam-policies/wiki/Cloud-Automator-IAM-policies
Oct 13以来更新されていないみたいですがおそらく最新なのでしょう。

明日(12/23)は神谷町のガッキーさんがとても勉強になる内容を書いてくれるみたいですよ。

あとCloud AutomatorのArchitectureに興味がある方はこんなまどろっこしいことをせずに @oko_chang に直接聞くのが早いと思います。もれなく自転車沼への猛烈な勧誘がついてくるのでそちらはお好みで必要に応じて沼に入ってみてください。

ではまた。
Next Post Previous Post