公開したアプリケーションはこちらです。記事を読まずに飛びたい方はどうぞ。
先週、ついにdetect stack drift のAPIがついにリリースされました！
re:Invent 2017でも発表されていましたが、待望の機能がついにリリースされて嬉しく思います。
これにより、AWSCloudformationを使用した運用が安心して回せるようになりますね！
AWS News Blog
AWS CloudFormationで手動で行った変更が検出可能になりました！！！
今回のアップデートであるドリフト検知はre:Invent 2017のセッションで発表されていた機能で、現在の状態とCloudFormationで定義されているあるべき状態の差分を検知することができる機能です。
初期の構築ではCloudFormationを利用するが、後のアップデートではUpdate Stackを実行せずに手動で変更したりCloudFormation以外の手段で変更してしまうことが多々あります。一旦別の手段へ変更してしまうと、テンプレートとの差が分からなくなりCloudFormationを利用した構成管理が行えなくなり、大きな問題になっていました。
実際のリソースとCloudFormationテンプレートの内容に乖離があることをドリフトと言い、それが可視化できる様になりました。
ということで、早速使ってみましょう。
ドラフト検知をコンソールから実行する
そのままだとdetect driftのステータスがスタックの一覧から確認できないので、設定しましょう。
右上の歯車のアイコンからDrift status, Last drift check timeにチェックを入れればOKです。
旧コンソールだとたしかデフォルトで表示されていたような・・・
設定ができました。
スタックを初期構築した時点だとドリフト検知は行われていないのでコンソールから実行してみましょう。
スタックを選択して、Actions > Detect drift で実行です。
ドリフト検知が完了すると、IN_SYNCのステータスになるかと思います。
スタックとして構築されたリソースを変更してみる
さて、次は構築されたリソースの一部をAWSコンソールから手動で変更してみましょう。
今回Cloudformationによって作成されたセキュリティグループのルールを変更してみます。
インバウンドルールに3306ポートをパブリックに解放するルールを追加してみました。
これでテンプレートに記述した状態と、実際に構築されているリソースとの間に差が生まれました。
さっそくドリフト検知をしてみましょう。
ドリフトが検知できました。
どの部分がテンプレートと差があるのか詳細を追ってみてみましょう。
リソースを選択して、View drift resultから確認です。
今回は想定通り、セキュリティグループにインバウンドルールを追加したことが見て取れます。
これでCloudformationを使用する際に怖がることは無くなりますね！
実運用のつらみ
AWSコンソールからドリフト検知が行えるようになったのはとても嬉しいのですが、
実際にチーム開発をしていると、ふとした時に誰かがリソースを勝手に変更してしまうというケースはよくあるかと思います。
さらに言えば、スタックが１つ２つの場合は手動で実行してみれば良いのですが、スタックの数が５０、６０個と増えてくるとそういうわけにも行きません。
そこですべてのスタックに対して毎日ドリフト検知を行うバッチを作ってしまいましょう。
今回はLambdaで実装してみましたので、せっかくなのでServerlessRepositoryに公開しました。
作成したものはこちらのアプリケーション🎁です。
右上のdeployボタンを押せばすぐにこのアプリケーションをデプロイすることができます。
Lambdaのコンソール画面に移動しますのでIAMロールが作成されることを許可して（チェックボックスにチェック）デプロイしましょう。
アプリケーションが作成され始めます。
作成完了したら、完成したLambdaをテスト実行してみましょう。
CloudwatchEventsで毎日10時に起動するようにはしているのですが、テストイベントをぶち込めば実行が可能です。
Lambdaの画面からテストイベントを作成してテストを押せばOKです。
最後にスタックの一覧を確認しておきましょう。
全てのスタックに対してドリフト検知が行われました。
Lambdaで作成したアプリケーションをServerless Repositoryに公開する方法はまたの機会に記事にしようと思います。
まずは取り急ぎ、ドリフト検知のご紹介でした✋