Defining userdata for instances in AWS seems really useful for doing all kinds of bootstrap-type actions. Unfortunately, I have to use a custom CentOS AMI that didn't originate from one of the provided AMIs for PCI reasons, so cloud-init is not already installed and configured. I only really want it to set a hostname and run a small bash script. How do I get it working?
Amazon-web-services – How to set up cloud-init on custom AMIs in AWS? (CentOS)
amazon-amiamazon-web-servicescentoscloud-init
Best Answer
cloud-init is a very powerful, but very undocumented tool. Even once it's installed, there are lot of modules active by default that overwrite things you may have already defined on your AMI. Here are instructions for a minimal setup from scratch:
Instructions
Install cloud-init from a standard repository. If you're worried about PCI, you probably don't want to use AWS's custom repositories.
Edit
/etc/cloud/cloud.cfg
, a yaml file, to reflect your desired configuration. Below is a minimal configuration with documentation for each module.If there is a
defaults.cfg
in/etc/cloud/cloud.cfg.d/
, delete it.To take advantage of this configuration, define the following userdata for new instances:
You can also simply run a bash script by replacing
#cloud-config
with#!/bin/bash
and putting the bash script in the body, but if you do, you should remove all of the hostname-related modules fromcloud_init_modules
.Additional Notes
Note that this is a minimal configuration, and cloud-init is capable of managing users, ssh keys, mount points, etc. Look at the references below for more documentation on those specific features.
In general, it seems that cloud-init does stuff based on the modules specified. Some modules, like "disable-ec2-metadata", do stuff simply by being specified. Others, like "runcmd", only do stuff if their parameters are specified, either in cloud.cfg, or in cloud-config userdata. Most of the documentation below only tell you what parameters are possible for each module, not what the module is called, but the default cloud.cfg should have a complete module list to begin with. The best way I've found to disable a module is simply to remove it from the list.
In some cases, "rhel" may work better for the "distro" tag than "amazon". I haven't really figured out when.
References