更新自定义资源会导致它们被删除吗？

Question

使用CloudFormation模板时，我发现具有Lambda支持功能实现的“自定义资源”功能对于处理CloudFormation不提供良好支持的各种任务非常有用。

通常，我使用自定义资源在堆栈创建过程中进行设置（例如查找AMI名称）或在删除过程中进行清除（例如从S3或Route53中删除可能阻止删除操作的对象）-这非常有用。

但是，当我尝试实际使用“自定义资源”来管理实际的自定义资源时，必须在堆栈创建期间创建该自定义资源，在堆栈删除期间将其删除，并且-这就是问题所在-有时在堆栈期间使用新值进行更新更新后，CloudFormation集成的行为异常，并导致自定义资源失败。

问题似乎是，在其中一个自定义资源属性已更改的堆栈更新过程中，在堆栈UPDATE_IN_PROGRESS阶段，CloudFormation将更新事件发送到支持Lambda函数，所有值均已正确设置，而旧值的副本发送为好。但是更新完成后，CloudFormation将开始该UPDATE_COMPLETE_CLEANUP_IN_PROGRESS阶段并向后备Lambda函数发送一个delete事件（RequestType设置为Delete）。

发生这种情况时，后备lambda函数将假定堆栈已被删除并删除自定义资源。结果是自定义资源在更新后消失了。

我已经查看了日志中的请求数据，“清除删除”看起来与真实的“删除”事件相同：

清除删除：

{
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
ResponseURL: 'https://cloudformation-custom-resource-response-useast2.s3.us-east-2.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-2%3A1234567890%3Astack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1%7Cresnmae%7C15521ba8-1a3c-4594-9ea9-18513efb6e8d?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20180511T140259Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7199&X-Amz-Credential=AKISOMEAWSKEYID%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Signature=3abc68e1f8df46a711a2f6084debaf2a16bd0acf7f58837b9d02c805975df91b',
StackId: 'arn:aws:cloudformation:us-east-2:1234567890:stack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1',
RequestId: '15521ba8-1a3c-4594-9ea9-18513efb6e8d',
LogicalResourceId: 'resname',
PhysicalResourceId: '2018/05/11/[$LATEST]28bad2681fb84c0bbf80990e1decbd97',
ResourceType: 'Custom::Resource',
ResourceProperties: {
    ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
    VpcId: 'vpc-35512e5d',
    SomeValue: '4'
} 
}

实际删除：

{
RequestType: 'Delete',
ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
ResponseURL: 'https://cloudformation-custom-resource-response-useast2.s3.us-east-2.amazonaws.com/arn%3Aaws%3Acloudformation%3Aus-east-2%3A1234567890%3Astack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1%7Cresname%7C6166ff92-009d-47ac-ac2f-c5be2c1a7ab2?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20180524T154453Z&X-Amz-SignedHeaders=host&X-Amz-Expires=7200&X-Amz-Credential=AKISOMEAWSKEYID%2F20180524%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Signature=29ca1d0dbdbe9246f7f82c1782726653b2aac8cd997714479ab5a080bab03cac',
StackId: 'arn:aws:cloudformation:us-east-2:123456780:stack/stackname/3cc80cf0-5415-11e8-b6dc-503f3157b0d1',
RequestId: '6166ff92-009d-47ac-ac2f-c5be2c1a7ab2',
LogicalResourceId: 'resname',
PhysicalResourceId: '2018/05/11/[$LATEST]c9494122976b4ef3a4102628fafbd1ec',
ResourceType: 'Custom::Resource',
ResourceProperties: {
    ServiceToken: 'arn:aws:lambda:us-east-2:1234567890:function:stackname-resname-J0LWT56QSPIA',
    VpcId: 'vpc-35512e5d',
    SomeValue: '0'
}
}

我看到的唯一有趣的请求字段是物理资源ID不同，但是我不知道将其关联到什么，以检测它是否是真正的删除。

Answer 1

问题似乎sendResponse()是用于将自定义资源完成事件发送回 CloudFormation的函数的示例实现。该方法负责设置自定义资源的物理资源ID。据我了解，此值表示由支持 CloudFormation 自定义资源的 Lambda 函数管理的“外部资源”的全局唯一标识符。

由于可以在可见CloudFormation的“LAMBDA支持自定义资源”的示例代码，以及在cfn-responseNPM模块S”send()和CloudFormation的内置cfn-response模块，该方法具有计算物理资源ID的默认行为，如果没有提供作为第 5 个参数，它使用 CloudWatch Logs 的日志流来处理正在处理的请求的日志记录：

var responseBody = JSON.stringify({
    ...
    PhysicalResourceId: context.logStreamName,
    ...
})

由于 CloudFormation（或 AWS Lambda 运行时？）偶尔会将日志流更改为新的日志流，因此生成的物理资源 IDsendResponse()会不时发生意外变化，从而混淆 CloudFormation。

据我了解，CloudFormation 托管实体有时需要在更新期间更换（一个很好的例子是RDS::DBInstance几乎所有更改都需要更换）。CloudFormation 的策略是，如果资源需要替换，则在“更新阶段”创建新资源，在“清理阶段”删除旧资源。

所以使用默认的sendResponse()物理资源ID计算，过程如下：

1. 一个堆栈被创建。
2. 创建一个新的日志流来处理自定义资源日志记录。
3. 调用支持 Lambda 函数来创建资源，默认行为将其资源 ID 设置为日志流 ID。
4. 过了一段时间
5. 堆栈将使用自定义资源的新参数进行更新。
6. 创建一个新的日志流来处理自定义资源日志记录，并带有一个新的 ID。
7. 调用支持 Lambda 函数来更新资源，默认行为将新资源 ID 设置为新日志流 ID。
8. CloudFormation 知道创建了一个新资源来替换旧资源，并且根据策略它应该在“清理阶段”期间删除旧资源。
9. CloudFormation 到达“清理阶段”并使用旧的物理资源 ID 发送删除请求。

解决方案，至少在我从不“替换外部资源”的情况下，是为托管资源制作一个唯一标识符，将其作为第 5 个参数提供给发送响应例程，然后坚持下去 - 继续发送相同的在更新请求中收到的物理资源 ID，在更新响应中。CloudFormation 将永远不会在“清理阶段”期间发送删除请求。

我的实现（在 JavaScript 中）看起来像这样：

    var resID = event.ResourceProperties.PhysicalResourceId || uuid();
    ...
    sendResponse(event, context, status, resData, resID);

另一种替代方法 - 如果您确实需要替换外部资源并希望遵守在清理期间删除旧资源的 CloudFormation 模型，这可能才有意义 - 是使用实际的外部资源 ID 作为物理资源 ID，以及何时接收删除请求 - 使用提供的物理资源 ID 删除旧的外部资源。这可能是 CloudFormation 设计人员首先想到的，但他们的默认示例实现会引起很多混乱 - 可能是因为示例实现不管理真正的资源并且没有更新功能。CloudFormation 中还有零文档来解释设计和推理。

Answer 2

重要的是要了解自定义资源的生命周期，以防止您的数据被删除。

要知道的一件非常有趣且重要的事情是，CloudFormation将Lambda函数返回的物理资源ID与之前返回的物理ID进行比较。如果ID不同，则CloudFormation假定资源已被新资源替换。然后发生了一些有趣的事情。

资源更新逻辑成功完成后，将使用旧的物理资源ID发送删除请求。如果堆栈更新失败并发生回滚，则会在Delete事件中发送新的物理资源ID。

您可以在此处阅读更多有关自定义资源生命周期和其他最佳实践的信息。