■概要
- Lambdaをデプロイする際のパターンを洗い出したので、適宜プロジェクトに合っているものを組み合わせて利用する
■使えるアーキテクチャ
- CI/CDツール(CodePipeline,Jenkins)
- CloudFormation(Sam,ServerlessFramework)
- AWS_CLI
- AWS_SDK(各プログラミング言語)
■悩めるポイント
- メタ情報(不随するもの)が多すぎて、単純にLambdaのソースだけを相手にするわけにはいかない。
- 少なくともIAMロール、環境変数、イベント、メモリ、タイムアウト値などなどの様々なメタ情報を一緒に管理しなければならない。
- 対象Lambdaをデプロイする際に、他のリソースの影響範囲も考えなければならない。
- 例えばバッチ処理でLambdaを利用している際、影響範囲によっては数か所の変更のためにバッチ全体を止めなければならない状態になってしまったりする。
※これらのポイントを考慮してデプロイ運用のパターンをいくつか考えてみる。
■デプロイ運用のパターン
- 手動で全て行うパターン
- CloudFormationで全てのリソースを管理するパターン
- code兄弟(CI/CDツール)を使って自動化するパターン
◆手動で全て行うパターン
- そのプロジェクトのリソースが少ない時や、マネージメントコンソールに頼りきってしまっている時に使われるパターン。
- 他の環境に横展開する際の手間や、手順書を作る工数を考えると、ツールを使った方が効率が良くなるのであまりお勧めしない。
◆CloudFormationで全てのリソースを管理するパターン
- 後述のCI/CDなどは特に行う必要がなく、リソースだけプロジェクト単位などで管理したい場合に使われるパターン
- 新規作成も更新もコマンド一発で出来るので環境差分などパラメータ化すれば汎用的に利用できる
- Sam,ServerlessFrameworkなどのツールを使えばローカル環境から簡単にデプロイができる(shellで実装しても良い)
●CloudFormationを使ってLambdaをデプロイする時の注意点
- IAMロールのRoleNameを固定にすると上手く設定が行かずはまるので注意
- Lambdaをzipでアップロードするときに、ファイル名を固定にすると、ソースを更新する際に「変更なし」とされて、更新されないので毎回zip名は変える事
◆code兄弟(CI/CDツール)を使って自動化するパターン
- gitにソースコードを載せておけば、圧縮からデプロイ、さらにテストやエイリアスの切り替えまで出来るので、フルセットで自動化する場合に使われるパターン
- CloudFormationを使うこともできるので上記のCloudFormationのパターンを内包しているともいえる
- Aws側でバージョン管理等している場合($LATESTではなく、ALIASを使っている)は、そこも込みでデプロイしないといけないのでこちらを使う
■最後に
以上、フィードバックやご指摘等いただけると大変ありがたいです!!よろしくお願いいたします!!