从 CI/CD 管道部署单个 Lambda 函数答案

【问题标题】：Deploying Single Lambda Function From CI/CD pipeline从 CI/CD 管道部署单个 Lambda 函数
【发布时间】：2019-12-12 12:31:00
【问题描述】：

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

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

我有一个想法，例如检查与 git 的差异并找出哪些已更改，并仅部署那部分功能，但这似乎不是正确的方法。相信有更合适的方法来做到这一点。

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

【问题讨论】：

您可以尝试使用 Cloudformation 和 Ansible。您可以编写多个 Play，在更新单个 lambda 时，您的 ansible play 只会更新 cf.

标签： aws-lambda continuous-integration terraform serverless-framework circleci

【解决方案1】：

您似乎添加了terraform、serverless-framework (I called it sls) 和aws-lambda 的标签。所以它们都适合你。

terraform - Terraform 本身会处理 lambda 需要更新的差异。但如果您需要安装相关的软件包，它对 lambda 不友好。
serverless framework (sls) - 用来管理 lambda 函数很好，但作为副作用，它必须与 api 网关一起管理。我不确定 sls 团队是否解决了这个问题。需要一些确认。

SLS 将负责安装相关软件包。

不好的是，sls不能diff要部署和计划的资源。

cloudformation - 这是 AWS 拥有的 Infrastructure as Code (IaC) 管理 aws 资源的工具，您应该可以使用它来管理 lambda 资源。您将遇到与 Terraform 相同的问题，即您必须在部署堆栈之前安装相关软件包。

不好的是，cfn (cloudformation) 也没有diff 功能，此外，它没有适当的工具来管理其 aws cli 命令，您必须使用其他工具，例如 shell 脚本、Ansible甚至 Terraform 来管理 coudformation 模板更新。

aws cdk - 最新的方法是使用aws-cdk，它确实有差异功能cdk diff 最适合您当前的工作，但它是一个非常新的项目，还有很多功能等待开发。

您可以接受这些并与your team's skill sets 一起思考。始终选择您和您的团队最有信心的工具。

【讨论】：

【解决方案2】：

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

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

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

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

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

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 映像等。

【讨论】：