はじめに
AWS Lambdaを使ってデプロイするときに、
Dockerイメージを使って、デプロイしたいケースがありました。
すでに、動いているLambdaをLambda Dockerへ変更する際に、
つまずきポイントがあったので、備忘録として、残しておきます
Lambdaでコンテナイメージを利用とは？
Lambdaには、通常のLambda(ソースコードのみを記述するタイプ)と
Dockerイメージを利用するパターンが存在する
※Dockerイメージは、ECRから参照し、Lambda上で実行が出来る
なぜDockerイメージを使うのか？
通常のLambdaとLambda Dockerには、仕様の一部に違う部分が存在している
今回、Lambda Dockerを利用したいと考えたのは、
通常のLambdaよりも、大きいパッケージを展開できる為
●Lambda
50 MB (圧縮、直接アップロード用)
250MB（解凍後）
3 MB (コンソールエディター)
●Lambda Docker
コンテナイメージコードのパッケージサイズ:
10GB
Lambdaに乗せられる容量が大きければ、
利用したいパッケージが多少大きくてデプロイが可能となる
今回Lambda Docker化したい内容
以前、記事に書き起こしたLINEWORKS BOT用のLambdaに
LangChainを実装したかった為、Lambda Docker化する必要があった
つまずきポイント1
LambdaとLambda Dockerのhandlerの宣言方法が異なる
前回の記事で、作成したLambdaのソースコードをそのまま利用し、イメージを作成
デプロイし、動作確認をしたところ、以下のエラーが発生
[ERROR] Runtime.HandlerNotFound: Handler 'handler' missing on module 'lambda_function'
通常のLambdaだと、ランタイム設定の中のハンドラという部分で、宣言が可能
Lambda Dockerだと、GUI上に宣言部分が存在していない
今回、Dockerイメージを作成する際、
AWSが準備しているPythonイメージを利用した
上記のドキュメントによれば、lambda_function.lambda_handlerではなく、
handlerと宣言する必要があった
なお、Dockerfile内の以下を調整することで、
lambda_function.lambda_handlerとすることも可能
CMD [ "lambda_function.handler" ]
Lambda Dockerで、ハンドラの宣言は、Dockerfileの中を確認しましょう
AWSドキュメントのまま、利用する場合は、handlerと宣言しよう
つまずきポイント2
ECR側で、latestを更新しても、Lambda側のイメージが変更されない
イメージの調整が必要と分かり、再度ECRへpushするが、エラーログに変化が出てこない
なぜ？と試行錯誤し、Lambdaの[新しいイメージをデプロイ]を開き、
そのまま保存をすることで、ログに変化が出ていた
latestとしているので、同じタグが付いているものを引っ張ってきてくれると思っていたが、
キャッシュ？ もしくは、latestと記載しているが、SHAで引っ張ってきているのか、
最新イメージで動作している状態ではなかった
なお、コンテナイメージのベストプラクティスでは、
latestは利用しない方がよいと記載されている
今回もlatestではなく、バージョンをきちんと振って、
都度デプロイすれば混乱しなかった
Dockerイメージを運用する場合は、latest運用はやめましょう
さいごに
初めてのLambda Dockerでつまずいたポイントでした
自分が利用するサービス仕様やベストプラクティスは、把握して利用していきたいですね！
それでは、また！