Setup
- VS 代码
- 地形 (v0.11(
问题
我很难理解如何在dotnet core 2.0项目中管理Lambda函数
当前方法(未实现只是我认为它可以工作的方式(
- 在地形中创建函数结构
- 在 dotnet 核心项目中创建函数代码,如此处所述
- 压缩发布文件夹并上传到 S3
- 根据适用于 c# 的 AWS 文档,在 Terraform 函数定义中引用函数的处理程序(程序集::命名空间.class-name::方法名称(
地形 Lambda 函数示例
resource "aws_lambda_function" "this" {
function_name = "test_function"
role = "lambda_exec_role"
s3_bucket = "my_bucket"
s3_key = "object_key/package.zip"
handler = "MyApp::Example.Hello::MyHandler"
runtime = "dotnetcore2.0"
}
这种方法意味着,如果我更改项目中的单个函数,我必须将整个代码库上传到 S3,这感觉不像是处理代码更改的干净方法。
替代方法
- 使用 dotnet 核心 CLI 管理 Lambda 函数而不是 Terraform
- 使用 dotnet 核心 CLI
dotnet lambda deploy-function
部署每个函数
从 Lambda代码版本管理的角度来看,这种方法感觉更干净,但这意味着我不再使用 Terraform 来管理我的 Lambda 函数。
我之前使用过 NodeJs 和 Go 来创建 Lambda 函数,每个函数似乎都比 dotnet 方法更轻量级(因为分离每个函数源代码更容易(。
问题
这些设置中的任何一个看起来都是最佳的吗?
我知道这个问题是在大约一年前从这个回复中提出的,所以我不知道从那时起一切都发生了多大变化,但这就是对我有用的:
我开始使用dotnet
CLI Lambda 工具,就像您建议的那样,它工作得很好。它开箱即用,需要最少的配置。我遇到的问题是我需要设置一些Cloudformation不允许的特定配置。那时我开始使用Terraform。经过一番挖掘,我决定使用Terraform,因为它解决了这个问题。
现在,您提到了使用Terraform的陷阱是您必须将整个代码上传到S3...但我发现 CLI 工具dotnet
完全相同。如果您签出执行dotnet lambda deploy-function
的输出,您将看到:
Zipping publish folder
... zipping: some.dll
... zipping: another.dll
Created publish archive (---)
Uploading to S3. (Bucket: ---)
... Progress: 11%
... Progress: 55%
... Progress: 100%
Creating new Lambda function some_lambda
所以,简而言之,我决定坚持使用Terraform,简单地编写一个自定义shell脚本,该脚本首先运行dotnet restore
,然后dotnet build
,最后terraform apply
。这就是我将应用程序部署到 AWS 所需的全部内容。我发现这是一种比将Cloudformation的无服务器与dotnet CLI一起使用更可定制的方法。
我希望这有帮助!