[レポート] AWS CloudFormationのベストプラクティス #DOP302 #reinvent
本記事はAWS re:Invent 2019のセッション「DOP302-R - [REPEAT] Best practices for authoring AWS CloudFormation」についてレポートします。
セッション情報
スピーカー
- Olivier Munn - Sr Product Manager Technical, Amazon Web Services
- Dan Blanco - Developer Advocate, Amazon Web Services
セッション概要
Incorporating infrastructure as code into software development practices can help teams and organizations improve automation and throughput without sacrificing quality and uptime. In this session, we cover multiple best practices for writing, testing, and maintaining AWS CloudFormation template code. You learn about IDE plug-ins, reusability, testing tools, modularizing stacks, and more. During the session, we also review sample code that showcases some of the best practices in a way that lends more context and clarity.
インフラストラクチャをコードとしてソフトウェア開発プラクティスに組み込むことで、チームと組織は品質と稼働時間を犠牲にすることなく自動化とスループットを改善できます。 このセッションでは、AWS CloudFormationテンプレートコードを記述、テスト、および保守するための複数のベストプラクティスについて説明します。 IDEプラグイン、再利用性、テストツール、スタックのモジュール化などについて学びます。 また、セッション中に、より多くのコンテキストと明確さを提供する方法でいくつかのベストプラクティスを紹介するサンプルコードを確認します。
レポート
アジェンダ
- Infrastructure as codeの紹介
- オーサリング
- テスト
- デプロイ
- マルチアカウント、マルチリージョン
- メンテナンス
CloudFormaitonを簡単に言うと
- YAML/JSONにコードを書く
- ローカルファイルをマネジメントコンソールカラップロード。またはパイプラインを使用
- スタックの作成。コンソール、CLI、SDKで作成
- StackSetsの作成
- マルチアカウント、マルチリージョン
- スタック、StackSets、リソースの運用管理
Inforastracture as Code の要素
- ソース
- すべてのテンプレートと設定をバージョンコントロール
- ビルド
- 静的解析とテスト
- テスト
- 統合テストを行うためのテスト用環境
- Promote
- 稼働している環境へデプロイ
パイプラインから始める
- テンプレートをCodeCommitへプッシュ
- CodePipeline
- CodeBuildで静的解析
- cfn-lint
- stelligent/cfn_nag
- TaskCat
- ステージング
エディタを選ぶ
- モダンなエディタを使おう
cfn-lintでシンタックスチェックしよう
- Atom、Visual Studio Code, Sublime、VIMのプラグイン
- 複数のファイルを処理可能
- conditions/Fn::If を処理
- SAM Localと統合
オートコンプリート機能を追加しよう
- aws-cloudformation/aws-cloudformation-template-schema
- Visual Studio Code、PyCharmで動作
- リソースタイプや必須属性のオートコンプリート
- 必要な属性のオートコンプリート
- リソースのドキュメントへのリンク
エディタを強化する
オーサリング ベストプラクティス
- Parameters
- 値をハードコーディングしない
- 認証情報などは AWS Systems Manager Parameter Store や AWS Secrets Manager に入れる
- Mappings
- Conditions
- インポート、エクスポート
!Join
よりも!Sub
を使おう- 最新のAMI IDの取得には SSM parameter storeを使おう
静的解析
- テンプレートをpush
- cfn-lintで静的解析
- ヘッドレスで動作
- エラーがあればパイプライン停止
- プルリクエストやオープンソースプロジェクトに最適
TaskCat
- AWS QuickStart Teamが作っているオープンソースプロジェクト
- 同時に複数リージョンでスタックを作成しテスト
- 単一のテンプレートやスタックでは検知できない問題を検知できる
- リージョンごとに失敗、成功のレポートを作成
- StackSetsにも使える
AWS CloudFormation StackSets
StackSetsとは
単一操作でマルチアカウント、マルチリージョンにスタックを作成、更新、削除が行える機能
- インスタンス更新のきめ細やかな制御
- New: デフォルトのより高いリミット
- 100 StackSets、2000インスタンス
- New: OUの新規アカウントに自動デプロイ
- New: OUで信頼関係の自動管理
StackSetsの一般的なユースケース
- アカウントを使用する前に、重要な必須設定を行う
- CloudTrail
- IAM
- Config
- 同様の目的を持つアカウントのグループを個別に設定
- Developers、QA、admins
- 複数のアカウント、リージョンへのリソース変更をコントロール
- 複数リージョンの本番環境
StackSetsのベストプラクティス
- StackSetsの更新を部分的にデプロイして不具合の影響を最小限にする。健全性テスト、増分リリースに最適
- 速度のニーズに応じて、より高い同時アカウント制限の設定を検討
- パラメーターのオーバーライドを使用して、アカウントとリージョンのペアで特定のパラメーターを定義
- 機能と必要な変更の頻度によってスタックを分離
スタックのライフサイクル
レイヤーによってライフサイクルが変わってくるのでうまく分ける
スタックのリファクタリング
インポート機能を使用してスタックをリファクタリング
まとめ
- すべてをバージョン管理するところから始める
- モダンなエディタ、プラグインを活用
- エディタをCloudFormationに最適化
- パイプラインを使用
cfn-lint
をエディタとパイプラインで行う- TaskCatを使って異なる環境でテスト
- チェンジセットとパイプラインを使って安全にデプロイ
- 再利用できるようにリファクタリング
- 小さいテンプレートにしておくことでテスト、メンテナンスが用意になる。デプロイも素早くできる
- 大きなスタックはImport機能を使ってリファクタリング
- ドリフトを検知、解消する
- StackSetsのクロスアカウント、クロスリージョンのユースケースを考える
まとめ
基本的な内容も多めでしたが、Import機能を使ったリファクタリングはなるほどと思いました。