cfn-init比userdata有什么好處？

Question

我的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 over userdata中有什么好處？

Answer 1

的主要好處AWS::CloudFormation::Init過UserData是，前者是可更新的-如果修改了AWS::CloudFormation::Init部分，CloudFormation將在地方更新您的EC2實例，而如果修改UserData屬性在模板中更新EC2資源並更新堆棧，CloudFormation將替換該EC2實例。

這很方便，例如，如果要更新EC2實例上安裝的軟件包而不重新創建它。

Answer 2

將CFN-INIT視為用戶數據的定制版本的想法是100％錯誤 - CFN-INIT具有超出用戶數據的功率。

userdata是基於程序的，運行命令

一個

乙

C

d

CFN-INIT是基於期望的狀態。

做這樣的

讓B像這樣。

CFN-INIT可以再次運行 - 例如在堆棧更新期間，更新配置，或者特別是將狀態置於期望的“狀態” - 用戶數據，因為其程序背景不能 - 不能保證能夠第二次運行並移動某個州的實例。

您可以在CFN-INIT中運行命令 - 即它也可以是程序性的 - 但它也可以是基於狀態的...即/tmp/something.txt具有此內容。 或者服務X已啟動。 'Apache Installed'知道沒有apache，最近的apache，apache的版本之間的差異 - 並且它相應地起作用。

Answer 3

最大的好處是，如果您還將其用於其他目的，則不會污染用戶數據。 因此，它存在於CloudFormation Stack中，並存在於每個Instance用戶數據中。

cfn-init基本上從CloudFormation中提取這些數據並運行命令。

根據這種復雜程度，您可以考慮將其烘焙到AMI中，只需在一個命令和一系列命令中調用它。

另一個區別是cfn-init必須烘焙到您用於啟動機器的AMI中。 對於現在幾乎任何AMI來說都是如此，所以並不是真正令人擔憂的原因。