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

Question

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

通常，我使用自定义资源在堆栈创建期间进行设置(例如查找 AMI 名称)或在删除期间清理内容(例如从 S3 或 Route53 中删除会阻止删除的对象) - 这非常有效。

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

问题似乎是，在堆栈更新期间，其中一个自定义资源属性发生更改，在堆栈的 UPDATE_IN_PROGRESS 阶段，CloudFormation 向支持 Lambda 函数发送一个更新事件，其中所有值均设置正确，并提供了旧值也发送。但更新完成后，CloudFormation 启动 UPDATE_COMPLETE_CLEANUP_IN_PROGRESS 阶段并向支持 Lambda 函数发送删除事件( 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

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

如CloudFormation's "Lambda-backed Custom Resource" sample code中所示，以及 cfn-response NPM module的 send() 和 CloudFormation's built-in cfn-response module ，如果未作为第 5 个参数提供，此方法具有计算物理资源 ID 的默认行为，并且它使用正在处理正在处理的请求的日志记录的 CloudWatch Logs 日志流:

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

由于 CloudFormation(或 AWS Lambda 运行时？)偶尔会将日志流更改为新的日志流，因此 sendResponse() 生成的物理资源 ID 会不时发生意外变化，并使 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 发送删除请求。

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

我的实现(在 JavaScript 中)看起来像这样:

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

另一种替代方案(可能仅在您确实需要替换外部资源并希望遵守在清理期间删除旧资源的 CloudFormation 模型时才有意义)是使用实际的外部资源 ID 作为物理资源 ID ，并且当收到删除请求时 - 使用提供的物理资源 ID 删除旧的外部资源。这就是 CloudFormation 设计者最初可能想到的，但他们的默认示例实现会引起很多困惑 - 可能是因为示例实现不管理真正的资源并且没有更新功能。 CloudFormation 中也有零文档来解释设计和推理。