使用 AWS::CloudFormation::Init 的好处

Question

我使用 cloudformation 模板已经有一段时间了，我一直在问自己以下问题：

与将这些语句直接添加到UserData 块相比，使用AWS::CloudFormation::Init 有什么好处？

到目前为止，我发现AWS::CloudFormation::Init 的方式更加冗长，尤其是当您需要多个configSets 来确保对您的语句进行某种排序时。

此外，某些 AMI 不支持开箱即用地运行该 init 块，并且需要额外的脚本 cfn-init，这会增加更多的冗长性。

Answer 1

我能想到的好处是：

• 一个简单的声明式 DSL。
• cfn-init 提供的日志记录等功能。
• cfn-hup 可用于在您运行 update-stack 时检测资源元数据的变化。

如果您喜欢类似于 Puppet 和 Chef 的简单、声明性 DSL，请使用 AWS::CloudFormation::Init。

如果您觉得它很麻烦，可能是 UserData 更合适。过多的 configSet 可能表明您使用了错误的工具（或订购了实际上不需要订购的东西！）。

另外，请注意 AWS::CloudFormation::Init 是旧的，它早于 CloudFormation 对 YAML 模板的支持。

在支持 YAML 之前，将脚本放入 UserData 是很困难的，因为您的 shell 脚本的每一行都需要在 JSON 数组中进行编码。这使得它难以阅读，并且容易出错。

在我看来，仅考虑到这两个选择，使用 AWS::CloudFormation::Init 更有意义。

这些天来，我的偏好是将 shell 脚本保留在 CloudFormation 之外，在外部对它们进行单元测试，然后将它们作为 base64 编码字符串作为参数提供。 （但请注意参数的 4096 个字符限制！）。

当然，这也取决于您的配置的复杂程度。您不希望在 UserData 的 shell 脚本中做太多事情，因为它很快就会变得无法维护。