AWS Lambda Layer 统一管理

关键要点

本文由 Debasis Rath、Kanwar Bajwa 和 Xiaoxue Xu 撰写。

企业通常管理一个 AWS Lambda 层的库存，这些层为 Lambda 函数提供共享的代码和库。这些 Lambda 层可以跨 AWS 账户和 AWS Organizations 共享，从而促进代码的一致性、可重用性和效率。随着企业在 AWS 上的扩展，跨越来越多的功能和账户管理共享 Lambda 层最好通过自动化来完成。

本博客文章旨在统一管理 Lambda 层，以确保符合企业的治理标准，并促进基础设施的一致性。通过检测型配置方法，系统性地识别使用过时 Lambda 层版本的不合规 Lambda 函数，并采取纠正措施，通过更新它们来解决这些问题。

该解决方案采用 AWS 服务，如 AWS Config、Amazon EventBridge Scheduler、AWS Systems Manager (SSM) 自动化 和 AWS CloudFormation StackSets。

解决方案概述

该解决方案提供两个部分的层管理：

这是第一个部分的架构。拥有必要权限的用户可以使用 AWS Config 高级查询 获取过时 Lambda 函数的列表。

任何 Lambda 函数的当前配置状态由成员账户中的 配置记录器 捕获。这些数据随后由管理账户中的 AWS Config 聚合器 聚合。聚合的数据可以通过查询进行访问。

该图展示了第二部分的架构。管理员必须手动部署 CloudFormation StackSets，以启动过时 Lambda 函数的自动修复。

使用手动修复触发器，而不是完全自动化的解决方案。管理员将此手动触发器安排为变更请求的一部分，以尽量减少对业务的影响。所有拥有受影响 Lambda 函数的业务利益相关者应接收此变更请求通知，并有足够的时间进行单元测试以评估影响。

在收到业务利益相关者的确认后，管理员部署 CloudFormation StackSets，随后自动部署 CloudFormation 堆栈到指定的成员账户和区域。CloudFormation 堆栈部署后，EventBridge 计划调用一个 AWS Config 自定义规则 来进行评估。该规则识别不合规的 Lambda 函数，并使用 SSM 自动化运行手册对其进行更新。

以下走查展示了使用集中管理层的两部分架构。分散管理和更新 Lambda 层在账户之间进行，使得执行更为困难且容易出错。

该解决方案的代码也可在 GitHub 上获取。

先决条件

为了进行解决方案走查，您需要满足以下先决条件：

编写按需查询以查找过时的 Lambda 函数

首先，您需要编写并运行 AWS Config 高级查询，以确定过时 Lambda 函数所在的账户和区域。这可以帮助终端用户了解影响的范围，并识别负责的团队以便通知。

按照以下步骤使用 AWS CLI 理解影响范围：

运行以下 AWS CLI 命令。将 YOURAGGREGATORNAME 替换为您的 AWS Config 聚合器的名称，将 YOURLAYERARN 替换为过时 Lambda 层的 Amazon 资源名称ARN。

bashaws configservice selectaggregateresourceconfig expression SELECT accountId awsRegion configurationfunctionName configurationversion WHERE resourceType = AWSLambdaFunction AND configurationlayersarn = YOURLAYERARN configurationaggregatorname YOURAGGREGATORNAME query Results output json jq r [] fromjson [accountId awsRegion configurationfunctionName configurationversion] @csv gt outputcsv

结果将保存为当前工作目录中的名为 outputcsv 的 CSV 文件。该文件包含当前使用指定的 Lambda 层 ARN 的账户 ID、区域、名称和版本。请参考文档以了解如何从 AWS CloudShell 下载文件 如何下载文件。

要探索更多的配置数据并利用 Amazon Athena 和 Amazon QuickSight 等服务进一步改善可视化，请参阅 通过 Amazon Athena 和 Amazon QuickSight 可视化 AWS Config 数据。

部署自动修复以更新过时的 Lambda 函数

接下来，您需要将自动修复 CloudFormation StackSets 部署到受影响的账户和区域，确保过时的 Lambda 函数得到更新。您可以使用上一节中概述的查询来获取账户 ID 和区域。

更新 Lambda 层可能会影响现有 Lambda 函数的功能。至关重要的是在修复之前通知受影响的开发团队，并协调单元测试以防止意外干扰。

为从管理账户创建和部署自动修复的 CloudFormation StackSets，执行以下步骤：

在 CloudShell 中运行以下命令以克隆 GitHub 仓库：

bashgit clone https//githubcom/awssamples/lambdalayermanagementgit

运行以下 CLI 命令以上传模板并创建 Stack Set 容器：

bashaws cloudformation createstackset stacksetname layersremediationstackset templatebody file//lambdalayermanagement/layermanageryaml

运行以下 CLI 命令，将所需账户和区域中的栈实例添加到您的 CloudFormation StackSets。请在运行此命令之前替换账户 ID、区域和参数。您可以参考 AWS CLI 命令参考 中的语法。NewLayerArn 是更新后的 Lambda 层 ARN，OldLayerArn 是原始 Lambda 层 ARN。

bashaws cloudformation createstackinstances stacksetname layersremediationstackset accounts ltLISTOFACCOUNTSgt regions ltYOURREGIONSgt parameteroverrides ParameterKey=NewLayerArnParameterValue=ltNEWLAYERARNgt ParameterKey=OldLayerArnParameterValue==ltOLDLAYERARNgt

运行以下 CLI 命令来验证栈实例是否成功创建。操作 ID 在第3步的输出中返回。

bashaws cloudformation describestacksetoperation stacksetname layersremediationstackset operationid ltOPERATIONIDgt

这个 CloudFormation StackSet 部署了一个 EventBridge 调度程序，该程序立即触发 AWS Config 自定义规则进行评估。此规则编写在 AWS CloudFormation Guard 中，检测当前在成员账户中使用过时 Lambda 层版本的所有 Lambda 函数。通过使用 AWS Config 的 自动修复 功能，SSM 自动化文档将在每个不合规 Lambda 函数上运行，以使用新层版本更新它们。

其他考虑事项

提供的修复 CloudFormation StackSet 使用 UpdateFunctionConfiguration API 直接修改 Lambda 函数的配置。这种更新方法可能会导致与您原始基础设施即代码 (IaC) 服务例如，您用于配置过时 Lambda 函数的 CloudFormation 堆栈的 漂移。在这种情况下，您可能需要增加额外步骤以 解决漂移 问题。

另外，您可能想直接更新您的 IaC 代码，引用最新版本的 Lambda 层，而不是如前所述部署修复的 CloudFormation StackSet。

清理

请参考文档以获取 从您的账户中删除所有创建的栈实例 的说明。之后，请继续 删除 CloudFormation StackSet。

结论

在多个账户和区域管理 Lambda 层在规模上的挑战是显而易见的。通过结合使用 AWS Config、EventBridge Scheduler、AWS Systems Manager (SSM) 自动化和 CloudFormation StackSets，可以简化这一过程。

示例提供了对受影响 Lambda 函数的按需可视化，并允许按计划修复受影响的函数。AWS SSM 自动化进一步简化了维护、部署和修复任务。通过这种架构，您可以高效地管理 Lambda 层的更新，确保符合您组织的政策，节省时间并减少无服务器应用中的错误。

要了解有关使用 Lambda 层的更多信息，请访问 AWS 文档。有关更多无服务器学习资源，请访问 Serverless Land。

标签 贡献 无服务器