本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Service Catalog Puppet
Service Catalog Puppet 是使用 AWS Boto3 API 在 Python 中实现的。此工具为配置和预调配 Service Catalog 产品提供了多项强大功能。开发者可以使用用作清单的 YAML 模板来配置 Service Catalog 产品和产品组合预调配信息。Service Catalog Puppet 预调配工作流程支持需要比 Service Catalog 更复杂的部署流程的产品。它们还支持性能优化，以便在紧迫的时段内大规模预调配产品。
Service Catalog Puppet 在部署时访问 Service Catalog CloudFormation 模板以进行产品预调配。它直接调用 CloudFormation 来部署产品的预调配模板堆栈，并绕过 Service Catalog 自身堆栈集预调配过程施加的限制。如果预调配模板使用宏来包含其他 CloudFormation 脚本或使用嵌套的 CloudFormation 脚本，您必须在预调配工作流程的引导部分提供对目标账户中这些脚本的访问权限。
有关更多信息：
-
请参阅 Service Catalog Puppet 文档
和 GitHub 存储库 。 -
如果您想使用 Service Catalog Puppet SDK 以编程方式与该工具交互以启动产品和产品组合预调配，请参阅 SDK 文档
。 -
GitOps
是管理 Service Catalog Puppet 环境的默认机制。
对开发者来说，Service Catalog Puppet 相当容易学习。要实现产品预调配模板，需要熟悉 CloudFormation；要实现清单，需要熟悉 YAML 模板。有不错的讲习会可以让新开发者快速上手，比如自主进度讲习会
支持预调配工作流程
Service Catalog Puppet 使用 Python Luigi 任务编排引擎来实现引导和预调配工作流程。这些工作流程中的所有步骤都作为 Luigi 工作流程任务来实现。有关 Luigi 的概述以及它与其他热门工作流程工具的比较，请参阅数据收入博客上的 Airflow vs. Luigi vs. Argo vs. MLFlow vs. KubeFlow
Luigi 允许 Service Catalog Puppet 控制与工作流程任务关联的 Worker 数量，并控制工作流程的其他方面，以实现更好的扩展和性能。Service Catalog Puppet 还提供了一种 depends_on 机制
预调配模型
Service Catalog Puppet 支持以下三种执行模式：中心、分支和异步
在所有预调配模式下，Service Catalog Puppet 无需调用 Service Catalog 的预调配流程即可直接实现产品预调配。您可以将预调配清单配置为使用现有 Service Catalog 堆栈集约束中的角色和目标账户规范。Service Catalog Puppet 使用此信息通过 Luigi 工作流程进行自身的预调配。
除了直接指定 OU 或账户外，您还可以根据账户标记方法定义产品组合预调配的目标。在基于账户标签的预调配中，产品组合产品将预调配给具有指定清单预调配标签集中所有标签的所有账户。例如，如果您想向美国东部区域的所有机构生产账户发行投资组合产品，则可以指定标签 type:prod、 partition:us-east 和 scope:institutional-client。您还可以声明账户和 OU 排除项，以禁止向 OU 或具有您指定标签的账户，或者向属于 OU 指定目标成员的账户进行预调配。有关账户标记的更多信息，请参阅 Service Catalog 工具文档
中心模式
在中心预调配模式下，分支账户的所有 Luigi 工作流程都通过指定的中央中心账户进行管理。中心账户扮演一个 IAM 角色，允许其在分支账户中执行操作，但任务管理是在中心账户内进行的。中心账户将同步等待，直到所有分支账户预调配任务完成（无论成功还是失败）。然后，它会报告最终状态。中心账户模式是最古老、最成熟的预调配模式。但是，许多用户已转向分支预调配模式，以实现更高的预调配并发性和速度。
分支模式
在分支模式下，Service Catalog 中心账户启动 Luigi 工作流程，使其在所指定引导的分支账户中运行。分支工作流程完成时，中心账户会收到通知。分支账户中的故障会上报到中心账户。中心账户会轮询分支账户，以查看其是否已完成并确定状态。
由于几乎所有服务都在独立的分支账户中运行，因此分支模式最不可能需要增加 AWS 服务配额。与中心模式相比，分支模式还可提供更高的并发性，同时保留集中控制。与中心模式相比，它可以将预调配速度提高 800%。分支模式支持通过产品之间的 DependsOn 关系实现产品链，从而确保所依赖的产品已经预调配。由链式产品组成的产品也可以预调配组件链式产品。您也可以使用专门的 AWS Lambda 函数调用来执行所需的步骤。一个分支中的故障与其他分支相隔离。
拥有超过 980 个账户、遍布多达 7 个区域的企业可以使用分支模式。这些企业通常能够在一小时内向基础设施中的所有区域和账户提供产品。
注意
这些结果可能会因网络基础设施、工作负载以及 AWS 组织中心和分支账户的配额等因素而异。它们还取决于正在预调配的产品资源、其固有的创建时间及对其他资源的依赖性。
异步模式
异步模式在分支账户中启动预调配工作流程，但它不会等待或接收来自分支的完成响应。
缓存
Service Catalog Puppet 用来优化工作流程速度的另一种机制是缓存代表工作流中步骤的常见任务。在缓存的任务完成时，它会将其输出写入 Amazon Simple Storage Service（Amazon S3）。下次在同一会话中使用相同的参数调用任务时，Service Catalog Puppet 将使用缓存的值而不是重新运行该任务。有关更多信息，请参阅 Service Catalog Puppet 文档中的 Caching
DevSecOps 生命周期支持
Service Catalog Puppet 包括对管理 DevSecOps 管线的支持。您可以使用 Service Catalog 工具操作（如 Service Catalog Puppet 概述
为了确保在广泛生产使用之前检测到与产品更改相关的任何问题，Service Catalog Puppet 要求至少有一个金丝雀账户进行初始部署。在您测试新版本并获得对新版本的信心之后，您可以将其推广到非金丝雀生产账户。如果您发现任何问题，则可以回滚版本，并在问题解决时重新引入该版本。使用此方法时，如果将存在问题的金丝雀版本发布到生产账户，则可能会出现生产问题。另一种替代方法是，在将更改发布到生产环境之前，可以对每个产品更改运行完整的回归测试。这会给 CI/CD 流程带来额外的开销，但有助于避免生产问题。DevSecOps 管理员有责任为其开发团队确定最佳的功能发布场景和方法。
Service Catalog Puppet 允许多个团队同时开发和测试 Service Catalog 产品解决方案的预调配。作为最佳实践，一个产品不应由多个开发者同时更改。相反，您可以将产品分解成更精细的组件，以进行单独的同步修改。
Service Catalog Puppet 还通过提供静态和单元测试功能的断言语句来帮助自动进行测试。您还可以在策略模拟器中测试服务控制策略（SCP）和 IAM 策略。从技术上讲，这些是端到端测试，但可以在系统集成测试（SIT）环境中使用。有关更多信息，请参阅 Service Catalog Puppet 文档中的 Using policy simulations
成熟度、完整性和支持
虽然 Service Catalog Puppet 不是官方支持的 AWS 服务，但它已被广泛采用。在过去几年中，大型组织一直在使用此工具在所需的预调配时间段内成功地将产品集中预调配到数百个 OU 账户。事实证明，它可以大规模提供容错产品预调配。遇到 Service Catalog Puppet 任何问题的用户都可以在 GitHub 存储库
