AWS cloudformation：一个大模板文件还是许多小模板文件？

Posted 2023-03-04

【中文标题】AWS cloudformation：一个大模板文件还是许多小模板文件？

【英文标题】：AWS cloudformation: One big template file or many small ones?

【发布时间】：2014-10-06 01:41:06

【问题描述】：

我将重写我的许多 AWS 部署代码，以使用由 boto 控制的 cloudformation 启动所有内容，而不是使用 boto 单独启动每个元素。有谁知道是“最佳实践”是使用一个巨大的模板文件（将所有内容一起启动），还是使用许多较小的模板文件？

一个巨大的优势似乎是 AWS 为您处理所有依赖项，因此会使事情变得更快。明显的缺点是维护起来就像一场噩梦。

有没有人尝试在运行时合并他们的模板文件，以便将它们视为一个大文件，或者这很难维护？

【参考方案1】：

我知道我迟到了，但我想分享cfpack.js CLI 工具，它允许您创建多个小型 CloudFormation 模板，这些模板将组合成一个大模板并部署到 CloudFormation 堆栈。

【参考方案2】：

没有简单的答案，但要牢记几个要点：

当您编写多个小模板时，请编写一个主模板，该模板将调用小模板（嵌套堆栈）。当你想更新一个小的时，在文件中进行更改，然后更新主文件。只有发生变化的资源才会被更新，堆栈更新的结果将是原子的（全部清除或回滚一切）。 CloudFormation 仍将并行运行嵌套堆栈，因此速度不会那么慢。

CloudFormation 在资源数量方面存在限制（每个堆栈 200 个资源）。例如，如果您有 SecurityGroupIngress/Egress 规则，就很容易到达。不确定支持人员是否可以更新此限制。

1234563再次声明所有参数。两层嵌套真的很痛苦，相信我！

我发现的最佳解决方案是使用 CloudFormation 模板前端（我在 python 中使用troposphere），这样您就可以真正将基础设施描述为代码，并具有代码的所有优点（循环、条件、外部文件、函数），最后，您得到了一个真正的 CloudFormation 模板。

我已经能够使用这个系统编写巨大的 CloudFormation 模板，而无需任何维护噩梦......

【讨论】：

堆栈集是否也可以提供帮助？

【参考方案3】：

我们从一个大型模板中的所有内容开始，但最终对其进行了一些重构，以包含一个包含一些资源的嵌套堆栈，以避免在其他模板中重复。

我发现的最大挑战之一是，拥有单一堆栈会使零碎更新变得更加困难，并且当存在依赖于单体资源的其他堆栈（例如安全组）时也会变得尴尬.

在 re:Invent 2014 上有一个会议，其中包含许多有用的提示：APP304 - AWS CloudFormation 最佳实践。 Slides/Video

他们建议根据层或共享位的组合来分解堆栈，例如：身份、基础网络、共享服务、后端服务、前端服务。

虽然我不喜欢处理大量参数和输出（在堆栈之间提供它们很烦人），但它似乎是一种更灵活的组合所需基础架构的方式。

【参考方案4】：

我不确定有关这方面的任何官方指导，但我的感觉是，如果您打算采用 CloudFormation 路径，将整个堆栈放入一个模板是有意义的。这样一来，正如您所提到的，您可以让 CloudFormation 的事务性质为您工作，并且将创建或不创建整个堆栈。