この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
全国のCloudFormationファンで、CloudFormation大好きな皆様！マニアックですね！
re:Invent2017において、以下のセッションに参加したので、そのレポートをお届けします。
DEV317 Deep Dive on AWS CloudFormation
せっション概要はこちら。
AWS CloudFormation enables software and DevOps engineers to harness the power of infrastructure as code. As organizations automate the modeling and provisioning of applications and workloads with CloudFormation, repeatable processes and reliable deployments become more critical.
This session guides you through various techniques to improve your infrastructure automation, including protecting your AWS resources and stacks with safety guardrails while monitoring infrastructure changes. In addition, we’ll cover efficient ways to provision resources across accounts and regions, as show you how to test and improve the reliability of your deployments
CloudFormatrionで構築したリソースをメンテナンスする上での永遠の課題。スタックとリソース内容の差分を検証する機能のリリース告知やデモがあったり、様々なユースケースにおけるCloudFormation活用のベストプラクティスが詰まった非常に濃いセッションでした。
CloudFormationが好きな方は、是非御覧ください。
__ （祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 CloudFormationﾀﾞ ﾜｯｼｮｲ |_|＿| し'´Ｊ
以下、スピーカーのノリを折り込みながら、セッションレポートしていきいます。
セッション内容
このセッションでは、こんなことを喋るぜ。
- システム管理者向け:CloudFormation利用における安全性の確保
- システム管理者向け:サーバープロビジョニングのスケール手法
- 開発者向け：テンプレートのテストと検証手法
- 開発者向け：サーバーレスアーキテクチャへの適用
このセッションから得られる学び
- スタックを保護しながら、リソースの変更を検知する方法
- リソースに対する、マルチリージョン、マルチアカウントでのプロビジョニング手法
- バリデーション機構によるデプロイの信頼性確保
- サーバーレスアプリケーションのデプロイ手法
CloudFormationに対する話題がてんこ盛りだ。さぁ、みんなついてきておくれよ！！
システム管理者向け:CloudFormation利用における安全性の確保
ここに来ている物好き連中には当然のことかもしれないが、一応、CloudFormationについて、その概要をおさらいしておくぜ。
YAMLやJSONで記述されたテンプレートファイルを、S3かローカルファイルシステムに格納。WebコンソールかAPIかCLIを利用してスタックを作成し、それを元に、リソースを作成していく。
CloudFormationの利用状況はこんな感じだ。
- 35万以上のアカウントがCloudFormationを利用している
- AWS利用料トップ1万アカウントにおいて、75%以上がCloudFormationを利用している
- 240万を超えるスタックが存在している
4つの層に分けて、スタックとリソースを保護していく考え方が重要だ。
- スタック自身の保護
- スタック自身でのポリシー適用
- グループ単位でのリソースに対する制限
- リソール自身でのポリシー適用
- クリティカルなリソースに対する、きめ細かい制御
- ユーザー自身でのポリシー適用
- テンプレートやリソースを変更できるユーザーの制御
1.スタック自身の保護
先日リリースされた、スタックレベルの保護機能を利用すると、スタック削除を防ぐことができる。
2. スタック自身でのポリシー適用
スタックに対するポリシー適用の例。
このポリシーでは、RDSリソースに対する更新を制御している。このようにスタックに対するポリシーの適用により、そのスタックが更新することのできるリソースを制限することができるので、スタック編集時の予期しない自己を未然に防ぐことができる。
3. リソース自身でのポリシー適用
この例では、リソースに対してポリシーを適用し、バックアップ/スナップショットの削除を保護している。
4. ユーザー自身でのポリシー適用
この例では、IAMに対してポリシーを制御し、そのユーザーがスタックを作成することができないようにポリシーを設定している。
（最重要）CloudFormationにおいて必ず起こる課題とその解決策
CloudFormationを長期にわたり利用していて必ず発生する課題。それが、スタックとリソースとの差分。インフラ修正を全てスタックに集約しておいたつもりでも、運用において、スタック以外の手操作でリソースを直接編集してしまうことはよくある。
これは、非常によくない事態だ。
この、スタックの内容と実際のリソースの状態が異なることを、drift状態にあるという。以下の理由で、こういう状態に陥ることはよくある。
- スタックリソースのプロパティを変更した
- スタックリソースの初期値を変更した
- スタックリソースを削除した
drift状態の定義は以下の通り。
- Expected values：スタックが構築するリソースの初期値や状態
- Current values：現在のリソースの実際の値
- drift：Current valuesとExpected valuesの差分
では、一体我々になにができるのか？
CloudFormationの外で変更された内容と、CloudFormationにより定義されている内容の差分を可視化することだ。
可視化 → 特定 → 比較
この、driftの検知機能が、 2018年にリリースされる！！
全リージョンで利用できるようになる予定だ。みんな、楽しみにしてろよな！！
DRIFT DETECTIONのデモ
ここでは、その機能をデモしていく。
こんな感じだ！
（筆者注：AWS CLIを利用した、DRIFTの確認をデモで見ることができました。使い方は簡潔で簡単だという印象でした）
Webコンソールももちろんあるぜ！
このようにコンソール上で、現在のスタックにdrift状態かどうかが表示される。
コンソール上で、現在のリソースとスタックの差分を表示することが可能だ。
既に、スタック外で削除されたリソースも確認できる。
どうだ。すげぇだろ。CloudFormationに対する長年の運用課題に対する真正面からのソリューションだ。リリースまであと少し。俺らは寝ずにやってるぜ。楽しみに待ってろよな！
システム管理者向け:サーバープロビジョニングのスケール手法
ここでは、サーバープロビジョニングをどうやってスケールさせていくかについて説明する。
企業が成長していけば行くほど、アカウントやリージョンはどんどん増えていく。
ここでは、ユースケースとして、こんな企業をあげておく。
- 2800ユーザー有り。将来的には10000ユーザーまで拡張予定
- 9つのリージョンを利用している。将来的には11リージョンまで拡張予定
- 管理対象リソースはVPC、EC2、IAM、Subnet、セキュリティグループ等多数
これらのプロビジョニングは、むちゃくちゃ難しい。チャレンジングだ。手作業での操作は、必ずエラーを起こす。スクリプトのメンテナンスも大変だ。サードパーティーツールの導入にはコストがかかる。
そんな時に利用したいのが、スタックセット。単一のオペレーションで複数アカウントやリージョンのスタックを管理できる。
コアとなるコンセプトはこんな感じだ。
スタックセットによるプロビジョニング戦略について語る。
- 新アカウントのセットアップ時
- アドミンS3バケットを利用して、CloudTrailを全て有効化する
- 適切なタグリソースに対して、AWS Configを設定する
- AWS KMSキーをセットアップする
- グローバル展開しているアプリケーションに対する個別デプロイ
- アプリケーションスタックをマルチリージョンで管理する
- 新リージョンセットアップ時にCloudFormationを活用しスピードアップする
- 事業継続性とディザスタリカバリ
- S3バケットのクロスリージョンレプリケーションを設定する
- RDSのリードレプリカを設定する
どうだい？アプリケーションが順調に拡大してきたら、必然的に利用に迫られるはず。その時は、スタックセットを思い出すんだ。
開発者向け：テンプレートのテストと検証手法
デベロッパーとテスターは、いつもこんな感じだろう？ haha
インフラストラクチャー ＝ Codeだ。テンプレートコードは、もちろん、リポジトリ管理するべき。
- イシューの履歴を追跡
- リポジトリコミットされたら、即テストせよ
- ツールを利用して、テンプレートにバリデーションをかける
- リポジトリコミットをフックして、Jenkins、Ansible、Chef、Puppetを使う・・・
けどちょっとまて。実際に、どうやってテンプレートをテストするかって？そこで役に立つ考え方が、VALIDATION PIPELINEだ。AWSマネージドで完結する。
テンプレートに対して論理的なテストを 走らせる。AWSマネージドのGitリポジトリ、CodeCommitを利用すれば、以下のCodeシリーズも利用可能だ。
- AWS CodePipeline
- AWS CodeBuild
- AWS Lambda
実装方法例はこちらだ。すげぇだろ。
（筆者注：ここに詳細は記述できないぐらいの仕組みです。別途AWSで記事にされているので、こちらを参考に。テンプレートのテストをどうやって実施するかの非常に有用な戦略が、詳細に記載されています。
AWS CloudFormation Validation Pipeline – AWS Answers）
開発者向け：サーバーレスアーキテクチャへの適用
CloudFormationは、様々な種類のアプリケーション・アーキテクチャーに対応している。
- サーバーレスリソースの生成に対応
- サーバーレスアプリケーションモデル（SAM）のトランスフォーム
- Chalice MicroFramework
セッションに関連するリソース
最後に、本セッションで参照したリソースについて共有する。このセッションと共にこれらを参考にすれば、グレイトだぜ！
- Protecting a Stack From Being Deleted - AWS CloudFormation
-
Working with AWS CloudFormation StackSets - AWS CloudFormation
濱田まとめ「CloudFromationの一歩踏み込んだ活用方法満載のセッション」
なんせ、最初から最後まで、スピーカーのテンションが高く、それでいて、非常に内容が充実したセッションで大満足でした。文中、妙にアゲアゲな口調なのは、その雰囲気を忠実に再現しているからですYO
なんといっても、2018年リリース予定のDRIFT DETECTIONが、楽しかった。この発表のときは、キーノートでアンディが新サービス発表したときのように、会場が興奮していたのを思い出します。それぐらい、CloudFormation界隈としては重要なアップデートになるかと思っています。早く使えるようになるのが楽しみですね。
それ以外にも、ポリシー設定による事故防止方法や、テンプレートのテスト手法など、新しい発見が多数あったセッションでした。それらの機能も、おいおい試してみようと思います。
それでは、今日はこのへんで。濱田でした。
2
