What are the benefits of cfn-init over user data?

My CloudFormation template got quite a bit of time. One reason is because my AWS::CloudFormation::Init section has become quite huge. This is a very small sample of what I have:

 "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" } } }, 

Wouldn't it be better to just put this in the userdata section as a bunch of commands?

 /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 

What are the benefits of leaving this in Initiation over user data?

+5
source share
1 answer

The biggest advantage is that you do not pollute user data if you also use it for other purposes. Thus, he lives in CloudFormation Stack and lives in each user information of an instance.

cfn-init basically retrieves this data from CloudFormation and simply runs the command.

Depending on how difficult it is, you can think about it in AMI and just call it in one team compared to a number of teams.

Another difference is that cfn-init needs to be baked in the AMI that you use to start the machine. This is the case for almost any AMI at the moment, so it is not really a matter of serious concern.

+3
source

Source: https://habr.com/ru/post/1241857/


All Articles