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

Question

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

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

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

此外，某些AMI不支持运行该init框，并需要额外的脚本cfn-init来添加它的详细信息。

Answer 1

我能想到的好处是：

• 简单的声明性DSL。
• 功能类似于cfn-init提供的日志记录。
• cfn-hup可用于在运行更新堆栈时检测资源元数据中的更改。

如果您喜欢与Puppet＆Chef相似的简单声明式DSL，请使用AWS :: CloudFormation :: Init。

如果发现它很麻烦，则可能是UserData更合适。太多的configSet可能表明您使用了错误的工具（或订购了不需要订购的东西！）。

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

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

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

这几天，我的首选是将Shell脚本保留在CloudFormation之外，对它们进行外部单元测试，然后将它们作为base64编码的字符串作为参数输入。 （但是请注意，参数不能超过4096个字符！）。

当然，这还取决于配置的复杂性。您不想在UserData的Shell脚本中做太多事情，因为它很快变得难以维护。