この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
先日、GolangのLambda関数をTerraformでデプロイするというエントリを書きました。
ですが、デプロイしたLambda関数はAmazon Linux(以下AL1)上で実行されているということがわかりました。AL1は現在long-term support(LTS)期間が終わり、2023年12月30日までのメンテナンスサポート期間内にあります。というわけでAmazon Linux2(以下AL2)への移行が推奨されています。せっかくなので今回作った関数もAL2に移行させたいです。
変更点
2箇所の変更だけで移行完了することができました。
aws_lambda_function.runtime
resource "aws_lambda_function" "sample" {
function_name = "sample"
s3_bucket = aws_s3_bucket.lambda_assets.bucket
s3_key = data.aws_s3_object.golang_zip.key
role = aws_iam_role.iam_for_lambda.arn
handler = "sample"
source_code_hash = data.aws_s3_object.golang_zip_hash.body
- runtime = "go1.x"
+ runtime = "provided.al2"
timeout = "10"
}
Golang用のAL2の専用ランタイムは用意されておらず、カスタムランタイム用のprovided.al2
を使います。
バイナリファイルの名前をbootstrap
にする
AWS公式情報でGolangのLambda関数の実行環境をAL2にする例がSAMでの実装ばかりだったのでこの部分が最初よくわかりませんでした。
前項「aws_lambda_function.runtime」で説明したとおり、GolangのLambda関数をAL2上で実行するというのは実質カスタムランタイムを使用することになります。そしてカスタムランタイムを使用する場合、ランタイムはbootstrap
という名前の実行可能ファイルにする必要があります。Golangの場合、go build
で生成するバイナリファイルの名前をこれ(bootstrap
)にすれば良いです。
locals {
golang_codedir_local_path = "${path.module}/lambdas/cmd/sample"
- golang_binary_local_path = "${path.module}/lambdas/bin/sample"
+ golang_binary_local_path = "${path.module}/lambdas/bin/bootstrap"
golang_zip_local_path = "${path.module}/lambdas/archive/sample.zip"
golang_zip_base64sha256_local_path = "${local.golang_zip_local_path}.base64sha256"
golang_zip_s3_key = "archive/sample.zip"
}
このlocal.golang_binary_local_path
がnull_resource
でビルドする際に使われています。
provisioner "local-exec" {
command = "GOARCH=amd64 GOOS=linux go build -o ${local.golang_binary_local_path} ${local.golang_codedir_local_path}/*.go"
}
provisioner "local-exec" {
command = "zip -j ${local.golang_zip_local_path} ${local.golang_binary_local_path}"
}