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

Question

我即将重写我的许多aws部署代码，以使用boto控制的cloudformation来启动所有内容，而不是使用boto自行调出每个元素。有没有人知道它的“最佳实践”是使用一个巨大的模板文件，它可以将所有内容组合在一起，还是许多较小的模板文件？

一个巨人的优势似乎是AWS为您处理所有依赖性，因此会稍微加快速度。明显的缺点是维持这似乎是一场噩梦。

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

Answer 1

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

• 当你编写几个小模板时，写一个主模板，它将调用小模板（嵌套堆栈）。如果要更新小文件，请在文件中进行更改，然后更新主文件。只更新已更改的资源，并且堆栈更新的结果将是原子的（全部清除或回滚所有内容）。 CloudFormation仍将并行运行嵌套堆栈，因此 更慢。

• CloudFormation中有关资源数量的限制（每个堆栈200个资源）。如果您已获得SecurityGroupIngress / Egress规则，则很容易触及。不确定支持是否可以更新此限制。

另一方面，

• 将参数提供给嵌套堆栈可能导致大文件没有那么多信息...考虑到这一点：你必须将所有参数提供给调用，在嵌套堆栈中你必须再次声明所有参数。两个级别的嵌套是一种真正的痛苦，相信我！

我发现的最佳解决方案是使用CloudFormation模板前端（我在python中使用troposphere），因此您真正将基础架构描述为代码，具有代码的所有优点（循环，条件） ，外部文件，功能）最后，您获得了真正的CloudFormation模板。

我已经能够用这个系统编写庞大的CloudFormation模板，没有任何维护噩梦......

Answer 2

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

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

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

他们建议基于层或共享位的组合来打破堆栈，例如：身份，基础网络，共享服务，后端服务，前端服务。

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

Answer 3

我不确定有关此问题的任何官方指导，但我的感觉是，如果您要进入CloudFormation路径，将整个堆栈放入一个模板是有意义的。这样，正如您所提到的，您可以获得CloudFormation的交易性质，并且可以创建整个堆栈。

Answer 4

我知道本次讨论迟到了，但是我想分享cfpack.js CLI工具，该工具可让您创建多个小型CloudFormation模板，这些模板将被组合成一个大的CloudFormation模板并部署到CloudFormation堆栈中。