はじめに
今までLambdaの開発はソース・パッケージをZipファイルに圧縮してS3バケットにアップロード、その後にデプロイというZip方式ばかり採用してきましたが、今回、コンテナイメージを作成しECRにイメージをPushしてデプロイというコンテナ方式を試してみました。
この記事ではコンテナ方式のLambdaをデプロイする際の変更箇所について記載しています。
なぜ、コンテナ方式を採用したのか？
Zip方式のLambdaでも要件として問題はなかったのですが、次の理由からコンテナ方式のLambdaを採用しました。
- ソースの規模が大きい。
ライブラリを含めると200Mを越しており、Zip方式の250MBの制限が少し不安 - コンテナで起動したいケースがある
ローカルのPCでプロジェクトを実行する場合やCI/CDとして運用する時に、Lambdaとして動作させるより、Docker上でコンテナ起動する方が現状お手軽でした。
作業内容
コンテナ方式にLambdaを変更するにあたって実施した作業を記載します。
1. CloudFormationテンプレートの書換
LambdaのデプロイにCloudFormationを利用しました。Lambdaのリソース設定の記載でZip方式から変更する箇所は以下の通りです。
1. パッケージタイプの変更と格納先の変更
パッケージタイプをZipからImage(コンテナ)に変更します
変更前
PackageType: Zip
Code:
S3Bucket: !Sub "${S3BucketName}"
S3Key: !Sub "${S3でのZipファイルのPath}"
変更後
PackageType: Image
Code:
ImageUri: !Sub "${ECR上のImage Path}"
2. Runtime設定の削除
コンテナ作成時のDockerfileにRuntimeの設定やHandlerが設定されているため、CloudFormationのテンプレートにこれらの設定が記載された状態で実行すると、「コンテナに登録されているため記載不要」という旨のメッセージが表示されエラーとなります。
そのため、テンプレートから下記箇所を削除しました。
Handler: app.main.lambda_handler Runtime: python3.12 RuntimeManagementConfig: UpdateRuntimeOn: Auto
2. ECRの用意
コンテナイメージを格納するECRを用意します。
また、LambdaはECRからイメージ取得するため、LambdaのRoleにECRに対する許可アクション設定が必要です。
{
"Effect": "Allow",
"Action": [
"ecr:GetDownloadUrlForLayer",
"ecr:BatchGetImage",
"ecr:BatchCheckLayerAvailability"
],
"Resource": "arn:aws:ecr:{Region}:{AWS Account}:repository/{ECR Name}"
}
コンテナ方式を使ってみた結果
コンテナ方式だとZip方式より起動が遅いなど不安があったのですが、そんなこともありませんでした。（正確なデータがなくすみません）
また、コンテナをAWS Batchに流用する計画もありますので開発工数の削減につながってくれることに期待です。
