亚马逊云科技 CloudFormation 注册机构的历史和未来路线图

亚马逊云科技 CloudFormation 是一项基础设施即代码 (IaC) 服务，允许您在模板文件中对云资源进行建模，这些模板文件可以用多种语言编写或生成。您可以通过 亚马逊云科技 管理控制台 、亚马逊云科技 命令行接口 (A WS CLI) 或 API 管理部署这些资源的堆栈。CloudFormation 帮助客户快速、一致地部署和管理云资源，但与所有 IaC 工具一样，它面临着跟上 亚马逊云科技 服务的快速创新步伐的挑战。在这篇文章中，我们将回顾 CloudFormation注册表 的历史 ，这是我们为解决扩展和标准化问题以及与其他领先的IaC工具和合作伙伴产品的集成而制定的战略的结果。我们还将介绍CloudFormation资源覆盖范围的当前状态并审查未来状态，其目标是使CloudFormation和其他 IaC 工具与最新的 亚马逊云科技 服务和功能保持同步。

历史

CloudFormation 服务于 2011 年 2 月 首次发布 ，其示例模板展示了如何部署博客和维基等常见应用程序。在发布时，CloudFormation支持了15种可用亚马逊云科技服务中的13项，共有48种资源类型。起初，资源覆盖范围与核心的CloudFormation引擎紧密结合在一起，这些资源的所有开发都由CloudFormation团队自己完成。在过去的十年中，亚马逊云科技 发展迅速，目前总共有 200 多项服务。多年来，一个挑战是客户使用亚马逊云科技服务可以实现的目标与在CloudFormation模板中可能定义的目标之间的覆盖差距。

显而易见，我们需要改变策略，扩大资源开发规模，以适应数百个每天提供新功能的服务团队所设定的快速创新步伐。在过去的十年中，我们的创新步伐加快了近40倍，2011年推出了80项重要的新功能，而2021年的这一数字已超过3,000项。由于CloudFormation是新亚马逊云科技服务的关键采用动力（或阻碍因素），因此这些团队需要一种方法来创建和管理自己的资源。目标是在新服务发布的第一天就提供支持，并全面覆盖CloudFormation资源。

2016 年，我们推出了一个内部自助服务平台，允许服务团队控制自己的资源。这开始解决先前模型中固有的扩展问题，即核心CloudFormation团队必须自己完成所有工作。好处不仅仅是分散开发人员的精力，因为服务团队对其产品拥有深厚的领域知识，这使他们能够创建更有效的 IaC 组件。但是，当我们在该模型上开发资源时，我们意识到需要额外的设计功能，例如可以自动支持漂移检测和资源导入等功能的标准化。

我们启动了一个新项目来解决这些问题，目标是改善内部开发者体验，并提供一个公共注册表，让客户可以使用相同的编程模型来定义自己的资源类型。我们意识到，仅仅推出新模型是不够的，我们必须通过培训活动对其进行宣传，举办工程训练营，构建更好的工具，例如仪表板和部署管道模板，并制作全面的入门文档。最重要的是，我们将CloudFormation支持作为新服务功能启动清单上的必备项目，这一要求不仅限于文档，而且已内置于内部发布工具中（随着时间的推移，有关注册表的培训和意识有所提高，因此这一要求很少有例外）。这是我们在亚马逊经常重复的格言之一的典型例子：好的机制胜于良好的意图。

2019 年，我们在 发布 CloudFormation 注册表 时向客户提供了这项新功能 ，该功能允许开发人员创建和管理私有资源类型。我们随后在2021年推出了 公共注册库 ，第三方可以在 其中发布扩展程序，例如亚马逊云科技合作伙伴网络 (APN) 中的合作伙伴。客户和合作伙伴用于发布第三方注册表扩展程序的开源资源模型与 亚马逊云科技 服务团队为其功能提供 CloudFormation 支持时使用的模型相同。

服务团队将其资源引入新资源模型并构建预期的创建、读取、更新、删除和列表 (CRUDL) 处理程序后，无需额外的开发工作即可支持 漂移检测 和 资源导入 等托管体验。CloudFormation 支持一项热门新功能的最新例子 是 Lambda 函数 网址，它为单功能微服务提供了内置 HTTPS 端点。我们还在2022年9月将 亚马逊关系数据库服务（Amazon RDS） 数据库实例资源（亚马逊云科技:: RDS:: dbInstance）迁移到新的资源模型，不到一个月， 亚马逊RDS就为CloudFormation中的亚马逊Aurora无服务器v2提供了 支持。 之所以能够加快交付，是因为团队现在可以利用分散的注册表所有权模型独立发布。

当前状态

我们正在这种新的标准化资源模型的基础上为CloudFormation服务构建未来的创新，以便客户可以从事件处理程序的持续实施中受益。我们在这个新的资源模型的基础 上构建了 亚马逊云科技 Cloud Control API 。Cloud Control API 采用为新资源模型编写的 Create-Read-Update-Delete-List (CRUDL) 处理程序，并将其作为用于配置资源的一致性 API 使用。诸如 HashiCorp Terraform、Pulumi 和 Red Hat Ansible 之类的 APN 合作伙伴产品使用云控制 API 与 亚马逊云科技 服务的发布保持同步，无需重复开发工作。

图 1。云控制 API 资源处理器图

除了第三方应用程序支持外，开发者社区还可以使用公共注册表在 亚马逊云科技 服务之上创建有用的扩展。扩展 CloudFormation 资源功能的常见解决方案是编写 自定义资源 ，这通常涉及内联 亚马逊云科技 Lambda 函数代码，该代码在堆栈操作期间 为 响应 创建 、 更新 和 删除信号而运行。现在，可以通过改为编写注册表扩展资源类型来解决其中一些用例。有关定制资源和资源类型以及两者之间差异的更多信息，请参阅 使用 亚马逊云科技 CloudFormation 资源类型 管理 资源。

CloudFormation 注册表模块是以 JSON 或 YAML 编写的构建块，为客户提供了一种方法，可以将脆弱的复制粘贴模板重用替换为在注册表中发布并像资源类型一样使用的模板片段。最佳实践可以封装并在整个组织中共享，这使基础设施开发人员能够使用抽象出资源配置的复杂细节的模块化组件轻松遵守这些最佳实践。

CloudFormation 注册表挂钩 为安全和合规团队提供了在创建、修改或删除任何资源之前验证堆栈部署的重要工具。基础设施团队可以在账户中激活挂钩，以确保堆栈部署无法避免或抑制挂钩处理程序中实施的预防性控制。严格限于客户端的配置工具没有这种强制性级别。

将资源类型发布到公共注册表的一个有用的副产品是，您可以通过 GitHub 上名为 cdk-cloudformation 的实验性开源存储库自动获得对 亚马逊云科技 云开发套件 (CDK) 的支持。 在大型组织中，通常会看到混合使用声明性模板的CloudFormation部署和使用TypeScript和Python等语言中的CDK的部署。通过将可重复使用的资源类型发布到注册表，所有开发人员都可以从更高级别的抽象中受益，无论他们选择哪种工具来创建和部署应用程序。（请注意，此项目仍被视为开发者预览版，可能会发生变化）

如果您想查看给定的 CloudFormation 资源是否在新的注册模型上，请通过调用 desc ribeType API 并检查 ProvisioningType 响应元素 来检查配置类型 是完全可变 还是 不可变 。

以下是一个 CLI 命令示例，用于描述新注册表模型上的 亚马逊云科技:: Lambda:: Function 资源。

$ aws cloudformation describe-type --type RESOURCE \
    --type-name AWS::Lambda::Function | grep ProvisioningType

   "ProvisioningType": "FULLY_MUTABLE",

FULLY_MUTABLE 和 IMMUTAB LE 之间的区别 在于更新处理 程序的存在。 FULLY_MUTABLE 类型包括一个更新处理程序，用于在堆栈更新操作期间处理该类型的更新。然而， IMMUTAB LE 类型不包含更新处理程序，因此该类型无法更新，而必须在堆栈更新操作期间替换。传统资源类型将 不可调配。

改进的机会

在我们继续努力实现实现全面功能覆盖和完全摆脱传统资源模式的最终目标的同时，我们一直在寻找改进的机会。我们目前正在解决所支持资源中的功能缺口，例如 标记对 EC2 VPC 终端节点的支持 ， 以及扩大资源类型的覆盖范围以支持偏移检测、资源导入和云控制 API。我们已经完全迁移了 130 多个资源，并承认还有许多资源要做，而且迁移所花费的时间比我们最初预期的要长。我们的首要任务是维护现有堆栈的稳定性——我们根本不能为了满足最后期限而破坏向后兼容性，因此我们会谨慎行事。像CloudFormation这样的服务器端配置引擎的最大好处之一是操作稳定性——无论您在多久之前部署堆栈，未来对其进行的任何修改都将起作用，无需担心升级客户端库。我们仍然致力于简化服务团队的迁移流程，使其尽可能简单和高效。

开发人员在创建注册表扩展程序方面的体验有一些艰难的优势，特别是对于 Java 以外的语言，Java 是 亚马逊云科技 服务团队针对其资源类型的首选语言。需要更容易地编写架构、编写处理函数和测试代码以确保其按预期运行。 我们正在投入更多资源来维护 CLI 以及 Python 、 Typescript 和 Go 插件。 我们对 aws-cloudformation GitHub 组织中这些存储库和其他存储库中的问题和拉取请求的响应速度没有达到应有的速度，我们正在进行改进。一个例子是 cloudformation-cli 存储库，自 2022 年 10 月以来，我们在其中合并了 30 多个拉取请求。

要了解资源覆盖的进展，请查看 CloudFormation 覆盖路线图 ，这是一个 GitHub 项目，我们在其中列出了所有待解决的未决问题。您可以在此存储库中提交与资源覆盖范围相关的错误报告和功能请求，并密切关注未完成请求的状态。我们最近为改善对 GitHub 上报告的功能请求和错误的响应而采取的措施之一是创建一个系统，在我们的内部问题跟踪器中将 GitHub 问题转换为问题单。这些票证直接发给负责的服务团队—— Amazon RDS 资源提供商 就是一个例子 ，它合并了数百个拉取请求。

我们最近宣布了一个名为 社区注册表扩展的新 GitHub 存储库，我们正在 其中管理公共注册表扩展 的命名空间。你可以提交和讨论新的扩展想法，并为任何相关项目做出贡献。我们负责 AWSCommunity:: 命名空间下所有资源的测试、验证和部署，可以在任何 亚马逊云科技 账户中激活该命名空间以供您自己的模板使用。

要开始使用 CloudFormation 注册表，请访问 用户指南 ，然后深入阅读详细的开发者指南，了解如何使用 CloudFormat ion 命令行接口 (CFN-CLI) 编写自己的资源类型、模块和挂钩。

我们最近创建了一台专用于CloudFormation的新的 Discord服务器。 请加入我们，提问、讨论最佳实践、提供反馈或出去玩！我们期待在那里见到你。

结论

在这篇文章中，我们希望您能深入了解 CloudFormation 注册表的历史，以及我们在向可由 亚马逊云科技 服务团队、客户和 APN 合作伙伴共享的标准化、可扩展的资源开发模型演变过程中做出的设计决策。我们在此过程中吸取的一些经验教训可能适用于您自己公司的复杂设计计划。我们希望能在 Discord 和 GitHub 上见到你，因为我们共同构建了一组丰富的注册资源！

作者简介：