【基礎から学ぶ】Serverless Framework と AWS SAM CLI の更新のデプロイの違いを確認する

サービス開発部のくればやしです。

Serverless Framework と AWS SAM CLI は代表的なIaCのツールです。

最近、この2つを使うプロジェクトがあり、比較しながら触っていました。

リソース定義方法の違いはよく注目されると思いますが、個人的には更新の際のデプロイの違いが最初に気になるポイントでした。アレコレ調べた結果、自分の中で整理できたので、本記事で概要を紹介します。

確認バージョン等

$ sam --version
SAM CLI, version 1.145.1

$ sls --version
Serverless ϟ Framework 4.33.0

比較してみる、その前に。(CloudFormationの仕様)

Serverless Framework も AWS SAM CLI も AWS CloudFormationをベースとしているため、最初にCloudFormationの仕様を確認します。CloudFormationではスタックの更新方法に、以下の2種類があります。

直接更新
変更セットによる更新

「直接更新」は即時反映です。「変更セット」は、マネジメントコンソールに注記がある通り以下が可能となります。

変更セットは、スタックの更新を開始する前に、スタックがどのように設定されるのかをプレビューするためのものです。これにより、変更セットを実行する前に設定の変更を調べることができます。

例えば、マネジメントコンソールからスタックに対して変更セットを作成すると以下のように変更セットによる差分等を確認でき、それらを確認してから「変更セットを実行」し、スタックを更新できます。

Serverless Framework の場合

Serverless Framework による更新は、デフォルトでは「直接更新」となります。

ただし、Providerの設定に以下⭐️を加えると、「変更セット」によるデプロイとなります。

provider:
  name: aws
  deploymentMethod: changesets # ⭐️

しかしながら、マネジメントコンソールから変更セットを用いたときのように、一度レビューしてから変更セットを実行、というプロセスは取れません。 Serverless Framework 上でデプロイすると、そのまま変更セットが実行されて、変更が反映されます。

以下のIssueで変更セットを作成して、実行前に停止する提案が提出されていましたが、まだ本体への実装はされていないようです。（実装されているPluginはあるようです）

github.com

AWS SAM CLI の場合

SAM CLI では変更セットを用いたデプロイが行われます。

デフォルトでは、以下のようにデプロイコマンド( sam deploy )の出力の中で、以下の確認が促されます。すなわち、変更セットが作成されたタイミングで一度レビューを行い、問題なければデプロイを実行することとなります。

Previewing CloudFormation changeset before deployment
======================================================
Deploy this changeset? [y/N]:

ただし、 sam init 後に作成される samconfig.toml で以下⭐️のように confirm_changeset を false に変更する、あるいは、コマンドのオプションで -no-confirm-changeset を指定すると、確認作業をスキップして変更セットが実行されます。

[default.deploy.parameters]
capabilities = "CAPABILITY_IAM"
confirm_changeset = false # ⭐️

まとめ

まとめると以下のようになります。

ツール	更新方式	デプロイ前のプレビュー
Serverless Framework	直接更新	なし（プラグインで対応可能な場合あり）
AWS SAM CLI	変更セット	あり

おわりに

今回、Serverless Framework と AWS SAM CLI における更新のデプロイの違いを確認しました。

実際のデプロイに際しては Pull Request のレビュー・マージ等のフローも含めて運用の設計を整理することとなると思いますので、どのタイミングでレビューをするか等の検討に役立てられれば幸いです。

（余談ですが、Serverless Frameworkは2015年登場と歴史が長く、CloudFormationの「変更セット（2016年登場）」よりも先に生まれています。一方、SAMは2016年後半に登場しており、こうした時期の違いが、現在のデフォルトの動作に違いに繋がっているのかもしれません。）