Serverless Frameworkの設定で、新しいプロダクトを作るときやレビューするときに気をつけたい点をまとめました。
他の方のベストプラクティスも知りたいです! ぜひコメントや記事公開してください。
Serverless Frameworkもpackage.jsonに入れておこう
CLIですがグローバルインストールしないで、ちゃんとpackage.jsonでバージョン管理するようにしましょう。
npm install -D serverless
バージョンの違いで動かなった経験、何度かあります。
ログの設定をしよう
ログの設定はしっかりしておきましょう。
provider:
logRetentionInDays: 14 # ログ保持期間
tracing: # x-rayトレースを採る
apiGateway: true
lambda: true
おまじないだと思って定型文的に入れています。
ゴミを残さない設定をしておこう
自動的に作られるデプロイメントバケットですが、気がついたら大量にできてたりします。アカウントで1つあれば十分なので、あらかじめバケットを作っておいて、以下のように既存バケットを使う設定にしておくのがおすすめです。
provider:
deploymentBucket:
# デプロイファイルの置き場に既存バケットcom.serverless.000000000.deploysを使用
name: com.serverless.${aws:accountId}.deploys
同じく、Lambdaのバージョン管理もオフで良いと思います。これが有効だとAWS管理コンソールからLambdaを古いバージョンに切り替えができるのですが、正直この機能を使ったことはないありません。レポジトリの状況とデプロイしているものが乖離するので使わない方が良いと思います。むしろ、このバージョン管理が原因でLambdaコードストレージ(Lambda クォータ)のサイズ制限に引っかかってデプロイの妨げになることが多かったり1。
provider:
versionFunctions: false
権限は必要最低限にしよう
権限は必要最低限のものを与えましょう。
悪い例
provider:
iam:
role:
statements:
- Effect: Allow
Action:
- s3:ListBucket
Resource:
- arn:aws:s3:::*
良い例
provider:
iam:
role:
statements:
- Effect: Allow
Action:
- s3:ListBucket
Resource:
- arn:aws:s3:::my-example-bucket
- ${cf:myStack.bucketName}
より細かく設定したい場合、Serverless IAM Roles Per Functionを導入するとよいかもしれません。
データ層はResourcesに含めない
Serverless.ymlの Resources
ブロックは実質的にCloudFormationテンプレートなので、AWSのリソースならおおよそ何でも作れてしまいます。「やったー! IaCだー!」と何でもかんでもここに突っ込みたくなるところですが、 S3, DynamoDB, Cognito等々の「データ層」のリソースを記述するのはおすすめしません。こういったものについては serverless.ymlとは独立してCloudFormationテンプレートを用意しましょう。
理由は、いつかは sls deploy
がコケて、どうしても sls remove
せざるを得ない状況が訪れるからです2。そうなるとせっかくデータを突っ込んだリソースが消すか、或いは次のデプロイがリソースの重複でコケるかの二択になってしまいます。
データ層だけのCloudFormationスタックを別に用意しておけば、 sls remove
するときも安心ですし、同じデータ層を参照するやつを2つデプロイして先行リリース環境を作ったりBlue-Green Deploymentだったりといったこともできます。ポイントはステージ名(--stage hoge
)だけ変更すればいくらでも複製をデプロイしてすぐ使える状況を作っておくことだと思っています。
${cf:stackName.outputKey}
で他のスタックのアウトプットを参照できることも活用しましょう。
-
Lambdaのバージョン管理を使いたい場合はServerless Prune Pluginというのがあるので、そちらを導入すると良いでしょう。 ↩
-
正確にはServerless Frameworkがコケるというより、
Resources
が原因でコケるケースが大半です。CloudFrontのリソースは割とトラブルが起きやすい印象です。なんにせよ「ないことはない」、いつかは起きる可能性がある事象と覚悟しておいたほうがいいでしょう。 ↩