最近CloudFormationを触り始めました、AWSのリソースをテンプレートから作成できるのは便利なのですが、その反面注意する必要がある点もあったので、備忘録も兼ねて紹介したいと思います。
対象読者
- CloudFormation初心者
前提
本記事では以下の構成のCodePiplineでリソースを作成することを前提として話していきます。
私がその構成でしかCloudFormationを扱ったことがないので、
他の構成やでは当てはまらない点もあるかもしれませんが、その点についてはご了承お願い致します。
CodePipeline
- 1. Source ステージ
- CodeCommit上のリポジトリのmasterブランチ
- 2. Build ステージ
- 必要なyamlファイルを生成し、
artifactsで指定して後続のステージで参照できるようにしています
- 必要なyamlファイルを生成し、
- 3. MakeChangeset ステージ
- CloudFormationのアクション「変更セットの作成または置換」で各stackのchangesetを作成します
- 4. Deploy ステージ
- CloudFormationのアクション「変更セットの実行」で各stackの作成または更新を行います
stackで作成されたリソースはコンソール上から変更、削除しない
コンソール上からStackでリソースの設定を変更すると。CodePipelineを実行した時に、テンプレート通りのパラメータに設定されず、コンソール上で設定したパラメータが残ってしまう場合があります。
私は特にLambdaに対してやっていましたが、
APIGatewayをトリガー設定を間違ったパラメータで変更してしまい、CodePipelineを再実行しても設定が戻らず、
必ずエラーになるAPIを作成してしまったことがあります。
設定を元の状態に戻せるのであれば問題ないかもしれませんが、基本的にstackで作成されたリソースをコンソール上から変更するのはやめましょう。
stackで作成されたリソースはコンソール上から削除しない
コンソール上からリソースを削除するとChangeset作成の段階で失敗します。
Changeset作成時はどうやら変更前のリソースは存在するものという前提で動いているようです。
もし削除してしまった場合、一番確実な対象法はstackを削除して再度作り直すことです。
私も次のCodePipelineの実行でLambdaが再作成されるだろうと思い、下手にパラメータを変更したLambdaを削除してしまいました。。
泣く泣くstackを削除して再度作り直しましたが、まだlambdaだけのstackで良かったです。
（実際どうなるのかはわかりませんが、これがDynamoDBだったりRDSだったらと思うとゾッとします）
DynamoDBの1テーブルに対して複数のGSI変更はできない
これはDynamoDBの仕様でもあるのですが、一つのテーブルに対してGSIの変更は一つずつしか変更できません。
- 新規テーブルを作成する場合
- 複数のGSIの作成は可能です。
- 既存テーブルに対して複数のGSIの作成または変更した場合
- エラーとなり更新に失敗します。
もし既存テーブルに対して複数のGSIの変更を行いたい場合は面倒ですが、一つのGSIを変更するたびにデプロイする必要があります。
VPC内のLambdaを含むstackを削除する場合、VPC内のLambda削除に40分の遅延が発生する
これはよくStackOverflowでもissueが上がってたりしますが、VPC内のlambdaを含むstack削除するとそのLambdaの削除に40分程時間がかかります。
これはLambdaに紐付いているENIが削除されるまで待機しているのが原因のようです。
対応としては(本来やって大丈夫かはともかく)コンソール上でENIのリストからLambdaに紐付いているENIを削除することで、遅延を減らすことができます。
Serverless Frameworkではstack削除時に並行してENIを削除するためのプラグインも公開されています。
まとめ
CloudFormationは便利な半面扱いづらい箇所も多く、使えば使うほど、悩まされる部分も増えている気がします。
今後も何かしら気づいた点があれば、記事を更新して（ついでにもっと読みやすくして）いきたいと思います