Service Catalog 木偶 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

Service Catalog 木偶

Service Catalog Puppet 是使用 AWS Boto3 API 在 Python 中实现的。此工具为配置和配置 Service Catalog 产品提供了多项强大功能。开发人员可以使用用作清单的 YAML 模板来配置 Service Catalog 产品和产品组合配置信息。Service Catalog Puppet 配置工作流支持需要比 Service Catalog 更复杂的部署流程的产品。它们还支持性能优化,以便在紧迫的时间窗口内大规模配置产品。

Service Catalog Puppet 在部署时访问服务目录 CloudFormation 模板以进行产品配置。它 CloudFormation 直接调用为产品部署配置模板堆栈,并绕过 Service Catalog 自己的堆栈集配置过程施加的限制。如果配置模板使用宏来包含其他 CloudFormation 脚本或使用嵌套 CloudFormation脚本,则必须在置备工作流程的引导部分提供对目标账户中这些脚本的访问权限。

有关更多信息:

  • 请参阅 Service Catalog Puppet 文档GitHub存储库

  • 如果您想使用 Service Catalog Puppet SDK 以编程方式与该工具交互以启动产品和产品组合配置,请参阅 SDK 文档。

  • GitOps是管理 Service Catalog Puppet 环境的默认机制。

Service Catalog Puppet 对开发者来说相当容易学习。它需要熟悉 CloudFormation才能实现产品配置模板,需要熟悉 YAML 模板才能实现清单。有不错的研讨会可以让新开发者快速上手,比如自定进度的研讨会

Support 对配置工作流程的支持

Service Catalog Puppet 使用 Python Luigi 任务编排引擎来实现引导和配置工作流程。这些工作流程中的所有步骤均作为 Luigi 工作流程任务来实现。有关 Luigi 的概述以及它与其他流行的工作流程工具的比较,请参阅 Data Revenue 博客上的 Airflow vs Luigi vs Argo MLFlow vs. KubeFlow

Luigi 允许 Service Catalog Puppet 控制与工作流任务关联的工作人员数量,并控制工作流程的其他方面,以实现更好的扩展和性能。Service Catalog Puppet 还提供了一种 depends_on 机制,用于管理产品和步骤依赖关系以及协调产品配置。此功能可帮助您实施和操作管理精细的产品定义和复杂的依赖关系。

配置模式

Service Catalog Puppet 支持三种执行模式:中心、分支和异步。所有三种模式都在已在 Service Catalog 中定义的产品组合中配置产品。他们依靠与目标客户共享服务目录产品,并使用服务目录管理员和启动角色在这些目标中实现配置。Service Catalog Puppet 根据 YAML 配置文件中提供的角色配置在同一个组织内执行引导步骤。该工具还支持通过单个中心账户向多个组织进行配置。在这种情况下,必须在外部组织中手动执行引导,以允许 Service Catalog Puppet 在外部组织的帐户中执行所需的置备操作。

在所有配置模式下,Service Catalog Puppet 无需调用服务目录的配置流程即可直接实现产品配置。您可以将配置清单配置为使用现有 Service Catalog 堆栈集约束中的角色和目标账户规范。Service Catalog Puppet 使用这些信息对 Luigi 工作流程进行自己的配置。

除了直接指定 OUs 或帐户外,您还可以根据帐户标记方法定义产品组合配置的目标。在基于账户标签的配置中,产品组合产品将配置给具有指定清单配置标签集中的所有标签的所有账户。例如,如果您想向美国东部地区的所有机构生产账户发行投资组合产品,则可以指定标签type:prod partition:us-east、和scope:institutional-client。您还可以声明账户和 OU 排除项,以禁止向 OUs 具有您指定标签的账户,或者向属于 OU 指定目标成员的账户进行配置。有关账户标记的更多信息,请参阅 S ervice Catalog 工具文档

集线器模式

在集线器配置模式下,分支账户的所有 Luigi 工作流程均通过指定的中央中心帐户进行管理。中心账户扮演一个 IAM 角色,允许其在分支账户中执行操作,但任务的管理是在中心账户内进行的。中心账户会同步等待,直到所有分支账户配置任务成功或失败完成。然后,它会报告最终状态。中心账户模式是最古老、最成熟的配置模式。但是,许多用户已转向分支配置模式,以实现更高的配置并发性和速度。

辐条模式

在分支模式下,Service Catalog 中心账户启动 Luigi 工作流程,使其在指定的自举分支账户中运行。分支工作流程完成后,中心账户会收到通知。分支账户中的失败会上升到中心账户。中心账户对分支账户进行轮询以查看其是否已完成并确定状态。

分支模式要求增加 AWS 服务 配额的可能性最小,因为几乎所有内容都在单独的分支账户中运行。在保持中央控制的同时,分支模式还提供比集线器模式更高的并发性。与集线器模式相比,它可以将配置速度提高 800%。Spoke 模式支持通过产品之间的DependsOn关系进行产品链接,从而确保所依赖的产品已经配置完毕。包含链式产品的产品也可以提供组件链式产品。您也可以使用专门的 AWS Lambda 函数调用来执行所需的步骤。一个辐条中的故障与其他辐条隔离开来。

分支模式适用于在多达 7 个地区拥有超过 980 个账户的企业。这些企业通常能够在一小时内向其基础设施中的所有地区和客户提供产品。

注意

这些结果可能会因网络基础架构、工作负载以及 AWS 组织中心和分支账户的配额等因素而异。它们还取决于正在配置的产品资源、其固有的创建时间以及对其他资源的依赖性。

同步模式

异步模式在分支账户中启动配置工作流程,但它不会等待或接收来自分支账户的完成响应。

缓存

Service Catalog Puppet 用来优化工作流程速度的另一种机制是缓存代表工作流中步骤的常见任务。缓存的任务完成后,它会将其输出写入亚马逊简单存储服务 (Amazon S3) Service。下次在同一个会话中使用相同的参数调用任务时,Service Catalog Puppet 将使用缓存的值而不是重新运行该任务。有关更多信息,请参阅 Service Catalog Puppet 文档中的缓存

DevSecOps 生命周期支持

Service Catalog Puppet 包括对管理 DevSecOps 管道的支持。您可以使用 Service Catalog Tools 操作(如服务目录 Puppet 概述中所示)来自动测试和在整个 AWS 生命周期账户中推广产品,包括推荐的金丝雀账户。有关更多信息,请参阅 Service Catalog Puppet 文档中的管理您的环境

为了确保在广泛生产使用之前检测到与产品变更相关的任何问题,Service Catalog Puppet 要求至少有一个金丝雀帐户进行初始部署。在您测试新版本并获得对新版本的信心之后,您可以将其推广到非 Canary 生产账户。如果您发现任何问题,则可以回滚该版本,并在问题解决后重新引入该版本。使用这种方法时,如果您发布的金丝雀版本对生产账户有问题,则可能会出现生产问题。作为另一种方法,您可以在将变更发布到生产环境之前,对每个产品变更进行全面的回归测试。这会给 CI/CD 流程带来额外的开销,但有助于避免生产问题。 DevSecOps 管理员有责任为其开发团队确定最佳的功能发布场景和方法。

Service Catalog Puppet 允许多个团队同时开发和测试服务目录产品解决方案的配置。作为最佳实践,一个产品不应由多个开发人员同时更改。相反,您可以将产品分解成更细粒度的组件,以进行单独的同步修改。

Service Catalog Puppet 还通过提供静态和单元测试功能的断言语句来帮助自动进行测试。您可以使用策略模拟器测试服务控制策略 (SCPs) 和 IAM 策略。这些是技术 end-to-end测试,但可以在系统集成测试 (SIT) 环境中使用。有关更多信息,请参阅 Service Catalog Puppet 文档中的使用策略模拟和应用服务控制策略

成熟度、完整性和支持

尽管 Service Catalog Puppet 没有得到官方支持 AWS 服务,但它已被广泛采用。在过去的几年中,大型组织一直在使用此工具在所需的配置时间窗口内成功地将产品集中配置到数百个 OU 帐户。事实证明,它可以大规模提供容错产品配置。在使用 Service Catalog Puppet 时遇到任何问题的用户可以将其登录到GitHub 存储库中,由本 AWS 实验室解决方案的贡献者来解决。