时间戳

首页 > 解决方案 > 从 CI/CD 管道部署单个 Lambda 函数

aws-lambda - 从 CI/CD 管道部署单个 Lambda 函数

问题描述

我正在处理一个基础设施，并试图弄清楚如何从 CI/CD 管道部署单个 lambda。

假设在一个 repo 中，您有 20 个 lambda，并且您对一个 lambda 进行了更改，而不是部署所有这些，我只想部署更改后的一个，从而缩短部署时间。

我有一个想法，比如检查与 git 的区别并找出哪些发生了更改，然后只部署那部分功能，但这似乎不是正确的方法。相信有更合适的方法来做到这一点。

我现在正在使用 terraform（转向无服务器框架）我知道 terraform 和无服务器框架在 s3 存储桶上保持状态。但是在我的情况下，当我通过管道运行它时，eventhogh 有一个 terraform 状态并且状态没有变化，它仍然按照实现的方式部署整个事情（我可能错了）。我只是想理清思路，看看人们是如何用他们的管道做到这一点的。

标签： aws-lambdacontinuous-integrationterraformserverless-frameworkcircleci

解决方案

由于您似乎在这里询问 Terraform 和无服务器框架，我假设您正在寻找一般答案，而不是具体如何使用特定工具解决此问题。

解决此问题的一种方法是通过在两者之间添加版本选择机制来将构建过程与部署过程分离。这只是意味着在您的系统中的某个地方，您有一个值可以由您的构建过程写入并由您的部署过程读取，这表明您的每个 Lambda 函数的“当前”工件是什么。

当您的构建过程成功完成时，它可以将有关它构建的工件的信息写入适当的位置，然后触发您的部署过程。然后，您的部署过程将读取工件信息并使用它来决定部署什么。

如果您没有对特定功能的当前工件元数据进行任何更改，那么部署过程可以看到这一点并且不做任何事情。如果特定工件在某些方面存在缺陷，并且您仅在部署后才注意到，您可以将工件元数据设置回之前的元数据并重新运行部署过程以回滚。如果您选择保留历史版本的数据存储，您还将拥有对当前工件的更改日志，这可能有助于了解导致事件的情况。

如果不深入细节，很难说更多。特别是对于 Terraform，工件元数据存储应该是 Terraform 可以使用数据源读取的东西。为了展示一个真实的示例，我将任意选择 AWS SSM Parameter Store 作为该工件元数据存储的位置：

data "aws_ssm_parameter" "foo" {
  name = "FooFunctionArtifact"
}

locals {
  # For this example, we'll assume that the stored parameter is a JSON
  # string shaped like this:
  # {
  #   "s3_bucket": "awesomecorp-app-artifacts"
  #   "s3_key": "/awesomeapp/v1.2.0/function.zip"
  # }
  foo_artifact = jsondecode(data.aws_ssm_parameter.foo)
}

resource "aws_lambda_function" "foo" {
  function_name = "foo"

  s3_bucket = local.foo_artifact.s3_bucket
  s3_key    = local.foo_artifact.s3_key

  # etc, etc
}

根据您的技术选择，这方面的技术细节会有很大差异。如果您不使用 Terraform，那么您将在其他工具中使用类似于数据源的功能，或者您将编写一些包装胶水代码，该代码本身可以检索必要的信息并将其作为参数传递给工具。

无论技术选择如何，主要的事情是在某处明确记录每个功能的最新工件是什么，该工件由您的构建步骤更新并由您的部署步骤读取。这种模式也可以应用于其他工件类型，例如 EC2 的 AMI、docker 映像等。

推荐阅读