While we were leaning towards specifying the entire contents of configuration files in the files property of cfn-init configs, this just doesn't seem like a realistic solution, for the following reasons:
When the default configuration contains dozens of lines, and we only want to change one line, why clutter up the CF template with a bunch of superfluous, default lines? We can use sed to modify only the lines we care about.
To add fewer lines to the CF template, we were going to remove all comments from the configuration files. This is problematic when we don't know the config syntax/options very well, and the default config files contain lots of comments that would have otherwise been instructive.
The main reason we were leaning towards the files property is because we could then use the files sub-property of the services property, so that services could be restarted automatically by cfn-init when their configuration files changed. However, we can just call service restart ourselves in the commands property.
By using the files property, we could be sure that services only restarted when their config files changed, and not just every time that cfn-init ran. However, restarting a service isn't a super taxing action, and production servers won't have their CloudFormation::Init metadata updated very often anyway, so manually restarting services in the commands property seems valid.
Long story short, instead of defining config file contents in the files property, we should be using the following pattern:
files:
/etc/danware/derp.sed
content: !Sub |
s|oldValue1|newValue1|
s|oldValue2|newValue2|
...
commands:
modifyConfig:
command:
sed --file /etc/danware/derp.sed --in-place /etc/path/to/program.conf
service program restart
services:
program:
enabled: true
ensureRunning: true
While we were leaning towards specifying the entire contents of configuration files in the
files
property ofcfn-init
configs, this just doesn't seem like a realistic solution, for the following reasons:sed
to modify only the lines we care about.files
property is because we could then use thefiles
sub-property of theservices
property, so that services could be restarted automatically bycfn-init
when their configuration files changed. However, we can just callservice restart
ourselves in thecommands
property.files
property, we could be sure that services only restarted when their config files changed, and not just every time thatcfn-init
ran. However, restarting a service isn't a super taxing action, and production servers won't have theirCloudFormation::Init
metadata updated very often anyway, so manually restarting services in thecommands
property seems valid.Long story short, instead of defining config file contents in the
files
property, we should be using the following pattern: