CloudFormationのスタック(Stack)を更新しても、更新されないリソース

-

まえおき

　CloudFormationを使っているとスタック(Stack)の更新をすることがある。今までCloudFormation内をリソースを更新したときに、更新されなくて戸惑った3つの場合について書いてみる。

 

1. LambdaのコードをS3に保存した場合

　当たり前かもしれないけど、その更新は最新のCloudFormationのテンプレートと旧テンプレートの差分より更新される。つまり、「テンプレートに変更がないとスタック内のリソースに更新は発生しない」ということだ。AWS::Lambda::Function のCode属性の記載方法には２つがある。テンプレート内に直接記載する方法とS3にファイルをアップロードし、そのバケット名とパスを記載する方法だ(関連ドキュメント)。ここで更新時に問題になるのはS3にLambdaファイルを更新する場合だ。S3のファイルを更新しても、CloudFormationテンプレート内のコードは変わることなく、S３ファイルの変化の検知もしないので、Lambdaが更新されない。私は以下の2つの方法で更新した。

 

方法１ S3パスを更新する

　シンプルな方法である。AWS::Lambda::Function のCode属性を変更すれば、テンプレートに変更点が発生するのでLambdaを更新するｋとおができる。私は日付ごとにフォルダを作成、更新するLambdaをおきテンプレートを修正するようにしていた。しかし、当時はCI/CD環境ではなかったので、テストでLambdaに修正点があれば、都度S3にファイルをアップロードして日付を修正＆デプロイまたはテンプレートをロールバック＆デプロイする必要があった。ミスも多く発生していた。そこで、CI/CD環境を整えることと同時に方法2の方法を利用することにした。

 

方法2 SAMを利用する(おすすめ)

　SAM(Serverless Application Package)　を利用する方法だ。SAMテンプレートを書いて、コマンドを実行すると以下が実行される。

  • Lambdaファイルはランダム文字列のファイル名でS3にアップロードされる
  • テンプレートをCloudFormationテンプレートに変換して、S3にアップロードしたLambdaのパスが記載してくれる。

　ちなみに、SAMテンプレートにはCloudFormationの内容も記載できるので、SAMを利用したいところだけSAM文法で書けばよい。変換コマンドAWS CLIのaws cloudformation pacakgeとSAMのsam pacakgeを利用する。sam packageコマンドは、aws cloudformation package のエイリアスなので、違いはない。ただ、下のStepfunctionに出るが最新のアップデートはsam packageの方でアップデートされ、まだaws cloudformation packageではできない場合もあるので、sam packageを利用した方がいいかもしれない。この方法の短所は変換過程が必要なことと、1つのLambdaを直しても変換をするときにテンプレート内のすべての(SAMで記述された)lambda関数に対してアップロードをされるので、微々たるものだけどS3容量の無駄(?)が発生すること。でも、アップロードする手間を防げる点では方法１よりはこっちの方法をおすすめする。ついでに、CodePipelineでCodeCommit(またはGithub)→CodeBuild(ここで変換)→Cloudformationのパイプラインを組んでおくと楽に変換とデプロイができる。

参考ページ

 

2. StepFunctionsをS3に保存した場合

　上記のLambdaと同じようにStepFunctionsのテンプレートコードをAWS::StepFunctions::StateMachineのDefinitionS3Location属性を利用してS3上ファイルに保存した場合にDefinitionS3Location内の内容が変更されないと変更がないこととなり、StateMachineが更新されない。詳細は前回書いたCloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになったを参照。更新方法としてもLambdaと同じように、S3パスを更新するか、SAMを利用すればよい。SAMを利用する場合は、DefinitionS3Locationは割と最新アップデートなので、SAMやCLIのバージョンが古いとうまく変換＆アップロードしてくれないことに注意する必要がある。(私が何か月前に触ったときはSAM packageはできたが、Cloudformation pacakgeではエラーとなった)

 

3. REST API Gatewayを更新してもデプロイされない

　REST API形式のAPI Gatewayを利用している場合は、設定を更新するとデプロイを行う必要がある。問題はCloudformationでAPI Gatewayを更新する場合、設定の更新はされるがデプロイまではしてくれないことだ。ネットを探しても、手動でデプロイするか、カスタムリソースを使ってデプロイをする方法しかないみたい。

　またはsam deployを利用してデプロイまで行えばできそうな気もするが、SAM CLIでアプリケーションを管理しないといけなさそうだったので、まだ試してはいない。ちなみに業務では手動でデプロイする方法を利用している。リリースルール上、決められたリリース日に本番環境に入ってリリースをしないといけないので、パイプラインで配布が終わった後にAPIGatewayのデプロイをする流れでやっている。

　ちなみに、このことについて記事？ネット情報があまりなかったけど、みんな当たり前なことだと思っているのかな？私はデプロイされないことを知って結構驚いたけど…。

 

まとめ

　Cloudformationでスタックを更新しても更新されない場合について書いてみた。ここら辺のことは、学習時はわからない場合が多く、実際に業務を行ってからわかるようになることが多いように思われる。今後、追加で更新されないことがあれば追記するようにしたい。

Popular Posts

CloudWatch EventsはAmazon EventBridgeになるらしい

-
イメージ
まえおき 　最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge（以前のCloudWatch Events）は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い 　全く同じサービスであるというと若...
続きを読む

PythonのDict型をDynamoDB形式のJsonに変換する

-
pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ＆蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/
続きを読む

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

-
イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私　：CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。 　　　これが私がCDKを押す理由の一つなんですよ。 Aさん：LambdaみたいにS３バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私　：あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん：うん?これでできないんだけ？(CloudFormationのドキュメントURLを共有) 私　：できるじゃん!? 　送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備 　State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)   　jsonファイルで保存し、S3のバケットに保存する。 　これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備 　 CloudFormationの StepFunctions::StateMachi...
続きを読む