AWS CloudFormation
# AWS CloudFormation
https://d1.awsstatic.com/webinars/jp/pdf/services/20181128-AWS-BlackBelt-CloudFormation.pdf
## 概要
シンプルなテキストファイル(テンプレート)を使用してAWSリソースをプロビジョニングできるサービス
- 他のプロビジョニングサービスとの位置付け
## コンセプト
## セクション
- Parameters
- 外部から入力できる変数を宣言
- 組み込み関数
- 擬似パラメータ
- Mappings
- Conditions
- Transform
- テンプレートの処理を使用する一つ以上のマクロを指定
- AWS SAM はこれを利用している
- マクロは自分で書くこともできる
- Outputs
- スタック構築後に取得・表示したい情報の定義
- Nested スタックや、他のスタックからの参照をする際に使用
- 他のスタックから利用するためにグローバル変数のように扱いたい場合はExport を利用
## 機能
- 作成
- テンプレートに従ってスタックを作成
- 変更
- スタックに前回のテンプレートとの差分を適用
- リソース変更時は無停止・再起動・再作成のいずれかが発生
- Change Set で差分の内容を確認可能
- Drift Detection で実際のリソースとの差分を検出可能(手動変更された時の差分確認など)
- 削除
- 依存関係を解決しつつリソースをすべて削除
- データストアは保持・スナップショット取得が可能
## 設計周りの機能
- Nested Stacks
- 書くテンプレートの共通部分を専用テンプレートとして作成
- ユースケース
- テンプレートの再利用
- 1つのスタックを管理するために複数のテンプレートを使用する
- 利点
- 管理が容易
- 作成順序と依存関係を記述可能
- 考慮点
- 更新やロールバックの影響範囲が広い
- カスタムリソース名を持つテンプレートの再利用に注意
- Cross Stack Reference
- あるスタックから値をエクスポートし、別のスタックで参照
- ユースケース
- 共用リソースのシェア
- 個別のスタックを個別のライフサイクルで独立管理できる
- 利点
- 利害関係の分離
- DBやVPCの共用
- 障害時影響範囲の限定
- 考慮点
- リプレースアップデートになると物理IDが変更になるため、これを利用しているスタックの更新が必要
- 個別スタックの作成順序を管理する必要がある
- Macros
- テンプレートの標準的な機能では実現できない処理をLambda関数を呼び出すことで実現
- AWS SAM(AWS Serverless Application Model)
- AWSでサーバレスアプリケーションを管理および展開するもの
- Macro の一種
- Dynamic References
- AWS CDK
- インフラをコードで記述して、Cfnでプロビジョニング
- コードとしてかけるためテストコードがかける
- yml に不慣れな人でもかける
- CDK -> コンパイル -> template -> スタック
## 運用周りの機能
- Change Set
- 変更を要求した箇所とその変更により影響を受ける箇所を事前に確認可能
- 変更時には無停止変更・再起動・再作成のいずれかが発生
- Drift Detection
- テンプレートと現状のリソースの差分を検出
- テンプレートに記述されていないことはチェックしない
- AWS Config のマネージドルールにより、差分が発生したらすぐに検知可能
- Rollback Triggers
- StackSets
- 1つのテンプレートを複数のAWSアカウント及び複数のリージョンに展開可能
- AWS CloudFormation Designer
- グラフィカルにテンプレートに記述されたリソースを見られる
- スタックとリソースの保護
- スタックやリソースが誤って変更・削除されないように保護するための機能
- 親のスタックの設定は子スタックに継承される
- スタックポリシーファイルに記述してテンプレートに適用すると、指定したリソースに対して実行できるアクションを定義することができる
## ベストプラクティス
- テンプレート分割
- 設計観点
- 依存関係
- ライフサイクル
- ステートレス・ステートフル
- 所有権
- 実装
- Cross Stack Reference
## 雑感
CloudFormation はAWSをプロダクション環境で利用するには絶対に必要なってくるものだと考えている。複数人で運用していると環境が見えにくくなってきて構成ドリフトが生まれてきてしまう。そう言うのをなくすにはIaCの仕組みを取り入れていく必要がある。
マクロの機能がありAWS SAM はこの機能を利用して実現しているが、安易に自作することは避けいたと思ってしまった。
Terraform や AWS CDK があるのでテンプレートをyaml で記述すべきか否かは議論が分かれると思うが、まずはIaCできていることが重要だと思うし、それを実現できるサービスであるCloudFormation はいいものであるとおもう。(ただ、yaml の中に他のyaml を書くのは辛い)