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

时间:2019-08-04 23:30:17

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

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

比方说,在一个回购中,您有20个lambda,并且您为一个lambda进行了更改,而不是全部部署,我只想部署更改后的lambda,因此节省了部署时间。

我有一个想法,例如检查与git的差异并弄清楚哪些已更改,然后仅部署功能的那一部分,但这肯定不是正确的方法。相信有更合适的方法可以做到这一点。

我现在正在使用terraform(移至无服务器框架),我知道terraform和无服务器框架在s3存储桶上保持一种状态。但是,以我为例,当我通过管道运行它时,会出现一个terraform状态,并且状态没有任何变化,它仍然将整个事情部署到可以实现的程度(我可能是错的)。我只想弄清楚自己的想法,看看人们是如何用管道来做到这一点的。

2 个答案:

答案 0 :(得分: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,则将使用与其他工具中的数据源类似的功能,或者编写一些包装器粘合代码,这些代码本身可以检索必要的信息并将其作为参数传递给工具。 / p>

最重要的是,无论选择哪种技术,都有一个明确的记录某处是每个功能的最新工件,该记录由构建步骤更新并由部署步骤读取。这种模式也可以应用于其他工件类型,例如EC2的AMI,泊坞窗映像等。

答案 1 :(得分:0)

似乎您已添加标签terraformserverless-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来管理编码模板更新。

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

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