AWS CloudFormation
■AWS CloudFormation の特徴
- Infrastructure as Code を実現でき、迅速に同一の何度もプロビジョニングできます。
- 必要なリソースとその依存関係を CloudFormation テンプレートに記述すれば、1 つのスタックとして一括で起動し環境構築ができます。
- リソースを個別に管理する必要はありません。
- 複数の AWS アカウントや、複数の AWS リージョンにわたって、スタックの管理とプロビジョニングが可能です。
■AWS CloudFormation ベストプラクティス
目次
テンプレートセクション
テンプレートには以下のセクションがあります。
形式バージョン (任意)
テンプレートが準拠している AWS CloudFormation テンプレートバージョンを記載します。
Description (オプション)
テンプレートを説明するテキスト文字列を記載します。。
メタデータ (オプション)
テンプレートに関する追加情報を提供するオブジェクトを記載します。
パラメータ (任意)
実行時に (スタックを作成または更新するとき)、テンプレートに渡すことができる値を記載します。
ルール (オプション)
スタックの作成またはスタックの更新時に、テンプレートに渡されたパラメータまたはパラメータの組み合わせを検証します。
マッピング (任意)
条件パラメータ値の指定に使用できる、キーと関連する値のマッピングを記載します。
条件 (オプション)
特定のリソースが作成されるかどうかや、スタックの作成または更新中に特定のリソースプロパティが値を割り当てられるかどうかを制御する条件を記載します。
変換 (オプション)
サーバーレスアプリケーションの場合は、使用する AWS Serverless Application Model (AWS SAM)のバージョンを指定します。
リソース (必須)
EC2 や S3 バケットなどのリソースとそのプロパティを指定します。テンプレートの Resources および Outputs セクションのリソースを参照できます。
出力（Outputs、アウトプット）（任意）
アウトプットセクションは、作成されたリソースのプロパティを返すのに役⽴ちます。
スタックポリシーについて
スタックポリシーを設定することでスタックを更新する際の動作を定義できます。
スタックを更新した際に、意図しない更新から保護するリソースを定義できます。
デフォルトでは、スタックの更新時にすべてのリソースを更新できます。
CloudFormation はリソースのプロビジョニングには適しているがサーバレスのプロビジョニングには適していない
CloudFormation はリソースのプロビジョニングには適しているがサーバレスアプリケーション（Lmabda、API Gateway、DynamoDB 等）のプロビジョニングには適していません。
サーバーレスアプリケーションのプロビジョニングには AWS SAM（AWS Serverless Application Model、サーバレスアプリケーションモデル）を利用します。
テンプレートの構文チェックをする方法
テンプレートファイルの構文チェックをする場合は aws cloudformation validate-template コマンドを実行します。
※注意点
aws cloudformation validate-template コマンドは、テンプレートの構文を確認するためのもので、リソースに対して指定したプロパティの値がリソースで有効であることを確認するためのものではありません。
デフォルトではスタックを削除するとリソースも削除されるので注意
CloudFormation のデフォルト設定ではスタックを削除すると、スタックによって構築されたリソース（VPC、サブネット、EC2インスタンス、RDS等）も削除されます。
ただし CoudFormation では 空でない S3 バケットを削除できないので注意
スタックを削除すると EC2 や VPC やサブネットなどは問答無用に削除されますが、オブジェクト（ファイルとかフォルダとか）が残っている S3 バケットは削除できません。
CloudFormation のスタックを削除する前に S3 バケットを空にしておく必要があります。
ただし、以下の DeletionPolicy を設定することでスタックが削除された際にリソースを保持できます。
DeletionPolicy 属性を使用するとスタックが削除されてもリソースを保持またはバックアップができる
DeletionPolicy 属性（削除ポリシー）を使用すると、スタックが削除された際にリソースを保持または (場合によっては) バックアップできます。
制御する各リソースに対して DeletionPolicy 属性を指定できます。
DeletionPolicy（削除ポリシー）を「Retain」にすると、CloudFormation のスタックを削除しても S3 バケットや EC2 インスタンスや RDS のリソース削除を防げます。
DeletionPolicy 属性が設定されていない場合、スタックを削除するとデフォルトでリソースが削除されます。
■DeletionPolicy 属性の種類
- Delete（削除）（デフォルト）
- Retain（保持）
- Snapshot（スナップショット）
DeletionPolicy 属性
サンプル CloudFormation テンプレート
参考
https://aws.amazon.com/jp/premiumsupport/knowledge-center/delete-cf-stack-retain-resources/
|
Description: AWS CloudFormation DeletionPolicy demo |
DeletionPolicy 属性が Snapshot の場合
DeletionPolicy 属性が Snapshot の場合はどうなるのでしょうか。
スナップショットをサポートするリソースについては、AWS CloudFormation は削除前に、リソースのスナップショットを作成します。
■スナップショットをサポートするリソース一覧
- AWS::EC2::Volume
- AWS::ElastiCache::CacheCluster
- AWS::ElastiCache::ReplicationGroup
- AWS::Neptune::DBCluster
- AWS::RDS::DBCluster
- AWS::RDS::DBInstance
- AWS::Redshift::Cluster
最初は1つのスタックでも範囲が広がったらスタックを分ける
最初は1つのスタックでもいいですが、徐々にスタックで構築・設定する範囲が広がったらスタックを分けていきます。
CloudFormationのベストプラクティス
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html
CloudFormation のベストプラクティスにも記載がありますが、分ける観点としては「ライフサイクル」と「所有権」の2点になります。
例えば Web サーバと DB サーバで構成されるウェブサイトがあるとします。
WebサーバはWebサーバ独自のライフサイクル（ApacheのバージョンとかNginxのバージョンとかパッチとか）がありますし、DBサーバにはDBサーバ独自のライフサイクル（DBのバージョンアップやパッチなど）があります。
また、Webサーバはインフラチームが所有しているが、DBサーバはDBチームが所有していることがあります。
このような観点で「ライフサイクル」と「所有権」でスタックを分けていきます。
変更セットを使用したスタックの更新
変更セットを使用すると、スタックが更新された場合の影響を確認することができます。
スタックを更新する必要がある場合は、変更の実装前に実行中のリソースに与える影響を理解することで、安心してスタックを更新できます。
変更セットの実行を確定したときのみ AWS CloudFormation によってスタックが変更されるため、変更案のまま続行するか別の変更セットを作成して他の変更を検討するかを決定できます。
カスタムリソースとは
カスタムリソースを使用すると、テンプレートにカスタムのプロビジョニングロジックを記述し、ユーザーがスタックを作成、更新、削除するたびに AWS CloudFormation がそれを実行します。
たとえば、AWS CloudFormation のリソースタイプとして使用できないリソースを含める必要があるとします。
リソースタイプの例
- AWS::EC2::Instance
- AWS::EC2::EIP
- AWS::EC2::SecurityGroup
- AWS::RDS::DBInstance
それらのリソースは、カスタム リソースを使用して含めることができます。
この方法により、すべての関連リソースを 1 つのスタックで管理できます。
カスタムリソース
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/template-custom-resources.html
要は「AWS::EC2::Instance」などデフォルトで用意されていないリソースを独自に作成するということです。もちろんサポートはされないので自己責任になります。
カスタムリソースで実行されるアクションには、3 者が関係します。
- template developer（テンプレートデベロッパー） ← カスタムリソースタイプを含むテンプレートを作成します。template developer はサービストークンとすべての入力データをテンプレートに指定します。
- custom resource provider（カスタムリソースプロバイダ） ← カスタムリソースを所有し、AWS CloudFormation からの要求に対する処理と応答の方法を決定します。custom resource provider は template developer が使用するサービストークンを提供する必要があります。
- AWS CloudFormation ← スタックオペレーション中に、テンプレートで指定された要求をサービストークンに送信し、スタックオペレーションを進める前に応答を待機します。
cfn-signal ヘルパースクリプト
cfn-signal ヘルパースクリプトは、Amazon EC2 インスタンスが正常に作成または更新されたかどうかを示すシグナルを AWS CloudFormation に送信します。
インスタンスにソフトウェアアプリケーションをインストールして設定する場合、ソフトウェアアプリケーションが使用できる状態になった時に AWS CloudFormation にシグナルを送信できます。
コメントを残す