自定义资源在部署时不能正常运行

Question

两天多来，我一直在尝试使用无服务器框架部署 CloudFormation 堆栈。问题是，作为堆栈的一部分，我有一个RDS集群以及一个自定义资源，该资源依赖于一个Lambda函数（用Python编写）来实现以下功能 初始化 一些数据库表。

在serverless.yml文件中，这个自定义资源的细节如下。

rdsMigration:
  Type: Custom::DatabaseMigration
  DependsOn: rdsCluster
  Properties:
    ServiceToken: !GetAtt MigrateDatabaseLambdaFunction.Arn
    Version: 1.0

当部署使用 sls deploy簇和lambda函数被正确创建，但在创建过程中卡住了 rdsMigration 资源。

在Lambda代码中，我一直小心翼翼地在所有可能的情况下生成响应，包括异常。然而，这似乎不是问题所在。

显然，函数没有被调用......某种程度上，因为连图表都看起来很奇怪。

你可以看到没有任何调用 但在 "错误数和成功率 "中，有一个红点 大约在下午5: 15，也就是资源创建开始的时间。另外，没有绿点，可以看到图例中的警告，声称 "由于非数值（NaN、-Infinite、+Infinite），一个或多个数据点被丢弃"。这怎么可能？我假设这不是标准行为，因为其他Lambda函数（必须使用API网关端点调用）不会显示这种奇怪的图表。

此外，CloudWatch 中没有日志流。它完全是空的，就像该函数从未被调用过一样（除了资源创建时的奇怪 "红点 "之外，情况似乎就是这样）。

最后，如果我使用 "AWS CloudFormation Create Request "模板运行测试用例，该函数正常运行，它为DB创建了我所期望的初始表（并非总是如此，但这是另一回事）并返回响应。

你知道这里发生了什么吗？最糟糕的是，我需要在测试之间等待两个小时，因为CFN堆栈在创建和销毁步骤中被卡住，直到超时发生。

谢谢!

Answer 1

问题在于您的 lambda 函数。你必须把SUCCESS或FAILURE信号发回给CFN。由于您的lambda函数没有发送任何信号，因此它在等待超时（2小时），Cloudformation就会失败。

1.The custom resource provider processes the AWS CloudFormation request and 
  returns a response of SUCCESS or FAILED to the pre-signed URL. AWS 
  CloudFormation waits and listens for a response in the pre-signed URL location. 

2.After getting a SUCCESS response, AWS CloudFormation proceeds with the stack 
  operation. If a FAILURE or no response is returned, the operation fails.

请在您的 lambda 函数中使用 cfnresponse 模块将 SUCCESSFAILURE 信号发送回 Cloudformation。

更多详情。https:/docs.aws.amazon.comAWSCloudFormationlatestUserGuidecfn-lambda-function-code-cfnresponsemodule.html。

Answer 2

我终于找到了问题的解决方案，尽管它不能解释我在问题中解释的图表的奇怪行为。

我的问题与Abhinaya在她的回答中所建议的类似。由于编程错误，Lambda函数没有正确发送信号。基本上，我把代码从 文件 (Python 3的那个，从最后开始的第二个片段)，显然我错误地删除了检索 ResponseURL. 当然，这是失败的。

关于这个问题的一个补充说明：在使用 Python 的 cfnresponse 库，甚至是我在文档中链接的代码片段。它依靠的是 botocore.vendored 已被废弃，在最新的 botocore 版本。因此，如果你的代码依赖于这个库的新版本，它就会失败（就像我的例子）。一个简单的解决方案是替换 botocore.vendored.requests 随着 requests 库。

不过，我还是无法理解一些奇怪的行为。在创建时，Lambda 函数没有将任何内容记录到 CloudWatch，并且在图表中出现了我在问题中解释的奇怪行为。但是，这只发生在创建时。如果手动调用该函数，或者作为删除过程的一部分调用该函数（删除 CFN 堆栈时），那么它确实会写入 CloudWatch。因此，该问题显然只发生在第一次调用时。

最好的。