Amazon web services 与userdata相比，cfn init有哪些好处？

我的CloudFormation模板已经很长了。一个原因是因为我的

AWS:：CloudFormation:：Init

部分变得非常庞大。这是我拥有的一个非常小的样本：

"ConfigDisk": {
    "commands": {
        "01formatFS": {
            "command": "/sbin/mkfs.ext4 /dev/xvdf"
        },
        "02mountFS": {
            "command": "/bin/mount /dev/xvdf /var/lib/jenkins"
        },
        "03changePerms": {
            "command": "/bin/chown jenkins:jenkins /var/lib/jenkins"
        },
        "04updateFStab": {
            "command": "/bin/echo /dev/xvdf /var/lib/jenkins ext4 defaults 1 1 >> /etc/fstab"
        }
    }
},

将其作为一组命令放入userdata部分不是更好吗

/sbin/mkfs.ext4 /dev/xvdf
/bin/mount /dev/xvdf /var/lib/jenkins
/bin/chown jenkins:jenkins /var/lib/jenkins
/bin/echo /dev/xvdf /var/lib/jenkins ext4 defaults 1 1 >> /etc/fstab

---

与用户数据相比，将其保留在Init中有什么好处？

最大的优点是，如果您还将用户数据用于其他用途，则不会污染用户数据。因此，这存在于CloudFormation堆栈中，而不是存在于每个实例用户数据中

cfninit基本上从CloudFormation中提取这些数据，然后运行命令

根据这个复杂程度的不同，你可以考虑把它烘焙成AMI，只需用一个命令调用一系列命令就可以了。p>

---

另一个区别是cfninit必须烘焙到您用来启动机器的AMI中。现在几乎所有的AMI都是这样，因此不太值得关注。

认为CFN-INIT是用户数据的定制版本是100%错误的-CFN-INIT的功能远远超出了用户数据

userdata是基于过程的，运行命令

A

B

C

D

CFN-INIT是基于所需状态的

像这样做

让B像这样

CFN-INIT可以再次运行-例如，在堆栈更新期间，更新配置，或特别是将某个状态设置为所需的“状态”-由于其过程背景无法设置用户数据-不保证能够再次运行并将实例移动到某个状态

---

您可以在CFN-INIT中运行命令，也就是说，它可以是过程性的，但也可以是基于状态的。。i、 e/tmp/something.txt包含此内容。或服务X已启动。”安装了Apache，它知道没有Apache，最新的Apache，Apache的一个版本之间的区别，并相应地采取行动。

AWS:：CloudFormation:：Init

优于

UserData

的一个主要好处是前者是可更新的——如果您修改

AWS:：CloudFormation:：Init

部分，CloudFormation将就地更新EC2实例，而如果您修改模板中EC2资源的

UserData

属性并更新堆栈，CloudFormation将替换该EC2实例

---

例如，如果您想在不重新创建EC2实例的情况下更新已安装在EC2实例上的软件包，则此操作非常方便。

本文档提供了更多上下文信息。