使用 CloudFormation 实现 Lambda 支持的自定义资源的最佳实践有哪些?

1 分钟阅读
0

使用 AWS CloudFormation 实现 AWS Lambda 支持的自定义资源时,我想遵循最佳实践。

解决方法

使用 AWS CloudFormation 实现 AWS Lambda 支持的自定义资源时,请考虑以下最佳实践。

构建您的自定义资源,以报告、记录和处理故障

异常可能导致您的函数代码退出而不发送响应。CloudFormation 需要 HTTPS 响应来确认操作是成功还是失败。未报告的异常会导致 CloudFormation 等到操作超时后再开始堆栈回滚。如果在回滚期间再次出现异常,则 CloudFormation 会再次等待超时,然后以回滚失败告终。在此期间,您的堆栈不可用。

为避免超时问题,请在为 Lambda 函数创建的代码中包含以下内容:

  • 用于处理异常的逻辑
  • 记录故障排除场景失败的能力
  • 通过确认操作失败的 HTTPS 响应对 CloudFormation 作出响应的能力
  • 让您可以捕获和处理未完成运行的死信队列
  • 用于向 CloudFormation 发送响应的 cfn-response 模块

设置合理的超时时间段,并在临近超时期限时进行报告

如果一个操作没有在既定的超时时间段内执行,则函数会引发异常,并且不会向 CloudFormation 发送响应。

为避免此问题,请考虑以下操作:

  • 将 Lambda 函数的超时值设置得足够高,从而应对各种情况下的处理时间和网络状况。
  • 在函数中设置一个计时器,以便在函数即将超时时以错误消息对 CloudFormation 作出响应。计时器可以帮助防止自定义资源延迟。

处理 Create、Update 和 Delete 事件

根据堆栈操作,CloudFormation 向您的函数发送 CreateUpdateDelete 事件。由于每种事件的处理方式不同,请确保在收到这三种事件类型中的任何一种时都不会发生意外行为。

有关更多信息,请参阅自定义资源请求类型

了解 CloudFormation 识别和替换资源的方式

当更新操作发起对物理资源的替换时,CloudFormation 会将您的 Lambda 函数返回的 PhysicalResourceId 与之前的 PhysicalResourceId 进行比较。如果 ID 不同,则 CloudFormation 会假定资源已被新的物理资源替换。

但是,为了允许潜在的回滚,不会隐式删除旧资源。堆栈更新成功完成后,将用旧物理资源 ID 作为标识符发送 Delete 事件请求。如果堆栈更新失败并发生回滚,则将在 Delete 事件中发送新的物理资源 ID。

使用 PhysicalResourceId 唯一标识资源,以便在接收到 Delete 事件时,在替换期间仅删除正确的资源。

用幂等性设计函数

幂等函数可以用相同的输入重复执行多次,结果与只执行一次相同。幂等性可确保重试、更新和回滚不会产生重复的资源或造成错误。

例如,如果 CloudFormation 调用您的函数来创建资源,但是未接收到已成功创建资源的响应,则 CloudFormation 可能会再次调用该函数,从而创建第二个资源。然后,第一个资源可能会变成孤立资源。

实施您的处理程序,以正确处理回滚

当堆栈操作失败时,CloudFormation 会尝试回滚,将所有资源还原到其之前的状态。根据更新是否造成了资源替换,此回滚操作可能会导致不同行为。

为了确保成功完成回滚,请考虑以下几点:

  • 在接收到 Delete 事件之前,避免隐式删除旧资源。
  • 使用 GitHub 网站上的 Accustom自定义资源帮助程序帮助您按照最佳实践在 CloudFormation 中使用自定义资源。

相关信息

自定义资源

AWS 官方
AWS 官方已更新 1 年前