Question

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

通常，我使用自定义资源在堆栈创建过程中设置东西（例如查找AMI名称）或在删除过程中清理东西（例如从S3或Route53中删除会阻止删除的对象） - 这样做效果很好。 / p>

但是当我尝试实际使用“自定义资源”来管理实际的自定义资源时，必须在堆栈创建期间创建，在堆栈删除期间删除，以及 - 这就是问题所在 - 有时用新值更新在堆栈更新期间，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   比较Lambda函数返回的物理资源ID   你之前回来的那个。如果ID不同，   CloudFormation假定资源已被替换为新资源   资源。然后发生了一些有趣的事情。

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

您可以阅读有关自定义资源生命周期和其他最佳做法的更多here

Answer 2

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

从CloudFormation's "Lambda-backed Custom Resource" sample code以及cfn-response NPM module的send()和CloudFormation's built-in cfn-response module中可以看出，此方法的默认行为是计算物理资源ID（如果未作为第5个参数提供），并使用CloudWatch Logs＆＃39;正在处理正在处理的请求的日志记录的日志流：

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

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

据我了解，CloudFormation管理实体有时需要在更新期间进行替换（一个很好的例子是RDS::DBInstance，需要替换几乎任何更改）。 CloudFormation策略是，如果资源需要替换，则在＆＃34;更新阶段期间创建新资源＆＃34;在＆＃34;清理阶段＆＃34;。

中删除旧资源

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

创建堆栈。
创建新的日志流来处理自定义资源日志记录。
调用支持Lambda函数以创建资源，默认行为将其资源ID设置为日志流ID。
一段时间过去了
使用自定义资源的新参数更新堆栈。
创建一个新的日志流来处理自定义资源日志记录，并使用新的ID。
调用支持Lambda函数来更新资源，默认行为将新资源ID设置为新的日志流ID。
CloudFormation了解创建了一个新资源来替换旧资源，根据该策略，它应该在＆＃34;清理阶段删除旧资源＆＃34;。
CloudFormation到达＆＃34;清理阶段＆＃34;并使用旧的物理资源ID发送删除请求。

解决方案，至少在我的情况下，我从来没有＆＃34;取代外部资源＆＃34;是为受管资源制作唯一标识符，将其作为发送响应例程的第5个参数提供，然后坚持使用 - 在更新响应中继续发送更新请求中收到的相同物理资源ID。然后，CloudFormation将永远不会在＆＃34;清理阶段＆＃34;。

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

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

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

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

清除删除：

真实删除：

2 个答案: