amazon-web-services - 使用 CloudFormation 和 SAM 部署时如何确保使用最新的 lambda 层版本？

Question

我们使用 CloudFormation 和 SAM 来部署 Lambda (Node.js) 函数。我们所有的 Lambda 函数都有一个通过 Globals 设置的层。当我们对层代码进行重大更改时，我们会在部署过程中遇到错误，因为新的 Lambda 函数会使用旧层部署到生产环境中，并且几秒钟后(在我们的示例中约为 40 秒)它开始使用新层。例如，假设我们向层添加一个新类，并将其导入到函数代码中，然后我们会收到一个错误，在部署期间显示 NewClass is not found 几秒钟(发生这种情况是因为新函数代码仍然使用旧层，没有 NewClass )。

是否可以确保新的 lambda 函数始终与最新的层版本一起推出？

示例 CloudFormation 模板:

    Globals:
      Function:
        Runtime: nodejs14.x
        Layers:
          - !Ref CoreLayer
    
    Resources:
      CoreLayer:
        Type: AWS::Serverless::LayerVersion
        Properties:
          LayerName: core-layer
          ContentUri: packages/coreLayer/dist
          CompatibleRuntimes:
            - nodejs14.x
        Metadata:
          BuildMethod: nodejs14.x
    
      ExampleFunction:
        Type: AWS::Serverless::Function
        Properties:
          FunctionName: example-function
          CodeUri: packages/exampleFunction/dist

示例 CloudFormation 部署事件，您可以看到新层 ( CoreLayer123abc456 ) 在更新 Lambda 函数之前创建，因此它应该可以在新函数代码中使用，但由于某些原因，Lambda 使用旧层版本进行更新和部署几秒钟:

<表类=“s-表”><标题>时间戳逻辑ID状态状态原因 <正文>2022-05-23 16:26:54堆栈名称更新完成-2022-05-23 16:26:54CoreLayer789def456DELETE_SKIPPED-2022-05-23 16:26:53v3uat-farthingUPDATE_COMPLETE_CLEANUP_IN_PROGRESS-2022-05-23 16:26:44示例函数更新完成-2022-05-23 16:25:58示例函数UPDATE_IN_PROGRESS-2022-05-23 16:25:53CoreLayer123abc456创建_完成-2022-05-23 16:25:53CoreLayer123abc456CREATE_IN_PROGRESS资源创建已启动2022-05-23 16:25:50CoreLayer123abc456CREATE_IN_PROGRESS - 2022-05-23 16:25:41堆栈名称UPDATE_IN_PROGRESS用户启动

变更集示例:

    {
      "resourceChange": {
        "logicalResourceId": "ExampleFunction",
        "action": "Modify",
        "physicalResourceId": "example-function",
        "resourceType": "AWS::Lambda::Function",
        "replacement": "False",
        "moduleInfo": null,
        "details": [
          {
            "target": {
              "name": "Environment",
              "requiresRecreation": "Never",
              "attribute": "Properties"
            },
            "causingEntity": "ApplicationVersion",
            "evaluation": "Static",
            "changeSource": "ParameterReference"
          },
          {
            "target": {
              "name": "Layers",
              "requiresRecreation": "Never",
              "attribute": "Properties"
            },
            "causingEntity": null,
            "evaluation": "Dynamic",
            "changeSource": "DirectModification"
          },
          {
            "target": {
              "name": "Environment",
              "requiresRecreation": "Never",
              "attribute": "Properties"
            },
            "causingEntity": null,
            "evaluation": "Dynamic",
            "changeSource": "DirectModification"
          },
          {
            "target": {
              "name": "Code",
              "requiresRecreation": "Never",
              "attribute": "Properties"
            },
            "causingEntity": null,
            "evaluation": "Static",
            "changeSource": "DirectModification"
          },
          {
            "target": {
              "name": "Layers",
              "requiresRecreation": "Never",
              "attribute": "Properties"
            },
            "causingEntity": "CoreLayer123abc456",
            "evaluation": "Static",
            "changeSource": "ResourceReference"
          }
        ],
        "changeSetId": null,
        "scope": [
          "Properties"
        ]
      },
      "hookInvocationCount": null,
      "type": "Resource"
    }

我不明白为什么 target.name: Layers 数组中有 2 个 details 项。其中一个具有 causingEntity: CoreLayer123abc456 ，这是由于新创建的层而预期的，另一个具有 causingEntity: null ，不知道为什么会出现这个。

最初发布在 AWS re:Post here

编辑:

经过几次测试，发现问题是由变更集中的变更顺序引起的。看起来更改是一一应用的。例如，对于以下变更集，它会在仍然使用旧层的同时更新旧功能代码，然后使用最新版本更新功能层，因为 Layers 更改项位于 Code 更改项之后。

    {
      "resourceChange":{
        "logicalResourceId":"ExampleFunction",
        "action":"Modify",
        "physicalResourceId":"example-function",
        "resourceType":"AWS::Lambda::Function",
        "replacement":"False",
        "moduleInfo":null,
        "details":[
          {
            "target":{
              "name":"Layers",
              "requiresRecreation":"Never",
              "attribute":"Properties"
            },
            "causingEntity":null,
            "evaluation":"Dynamic",
            "changeSource":"DirectModification"
          },
          {
            "target":{
              "name":"Code",
              "requiresRecreation":"Never",
              "attribute":"Properties"
            },
            "causingEntity":null,
            "evaluation":"Static",
            "changeSource":"DirectModification"
          },
          {
            "target":{
              "name":"Layers",
              "requiresRecreation":"Never",
              "attribute":"Properties"
            },
            "causingEntity":"CoreLayer123abc456",
            "evaluation":"Static",
            "changeSource":"ResourceReference"
          }
        ],
        "changeSetId":null,
        "scope":[
          "Properties"
        ]
      },
      "hookInvocationCount":null,
      "type":"Resource"
    }

但在某些部署中，顺序是相反的，例如:

    {
      "resourceChange":{
        ...
        "details":[
          ...
          {
            "target":{
              "name":"Layers",
              "requiresRecreation":"Never",
              "attribute":"Properties"
            },
            "causingEntity":"CoreLayer123abc456",
            "evaluation":"Static",
            "changeSource":"ResourceReference"
          },
          {
            "target":{
              "name":"Code",
              "requiresRecreation":"Never",
              "attribute":"Properties"
            },
            "causingEntity":null,
            "evaluation":"Static",
            "changeSource":"DirectModification"
          }
        ],
        ...
    }

在这种情况下，它会使用最新的层版本更新旧函数，然后使用更新的版本更新函数代码。因此，在几秒钟内，旧代码将被最新的层版本调用。

那么是否可以仅一步应用所有这些更改？类似于 Atomicity in databases

Answer 1

我通过使用建议的 Lambda 版本解决了这个问题 here 。对于每个部署，我都会创建一个新的 Lambda 版本，以便新旧 Lambda 使用正确的核心层。

重新发布我在原始帖子中的评论以供引用:

I added a lambda version:

ExampleFunctionVersion:
  Type: AWS::Lambda::Version
  DeletionPolicy: Delete
  Properties:
    FunctionName: !Ref ExampleFunction

and replaced all function references with !Ref ExampleFunctionVersion.

I also tried AutoPublishAlias: live, it worked too but I had to add an AWS::Lambda::Version resource to be able to set DeletionPolicy: Delete