The examples I'm going to show you now are all from the cloud-init documentation site.
The first example is almost self explanatory I would think.
It sets the server's time zone. A quick word about YAML syntax,
YAML files consist of key-value pairs, in this case the key is timezone.
The colon separates it from the value, and the value is a string.
Values can also be numbers. Strings can be written with quotes,
but that is optional. It makes code more readable sometimes.
Note that there is no indication how the time zone is set.
Depending on the image, that might be done by different commands or different procedures.
We just tell the server set the time zone, and we hope that the server
knows best how to do that. The second example shows how cloud-config
can be used to install additional software packages on the server.
Again, we have a single key, packages. This time the value is a list
of three items, and the third item is itself a list.
A YAML list can be written on a single line with square brackets or on
several lines, each list item marked with a dash.
So what does this do? This YAML file specifies packages that will be
installed on the server when it starts for the first time,
namely pwgen, pastebinit, and libpython2.0.
A specific version of libpython is requested.
The name and the version of this package are written as a list inside
the package list. Note that this same user-data file could be used no
matter what package manager the server has, be it yum, APT, Zipper, or whatever else.
Of course in this particular case, it requests a very specific Ubuntu
version of the libpython package, so that probably doesn't work on
CentOS or SUSE. This example also deals with packages.
It upgrades all packages that are installed on the server.
Again, it works no matter which package manager is installed.
The final example here configures NTP on the server.
Not only that, if NTP is not installed, cloud-init will install it,
and then it will configure the three NTP servers shown here.
The YAML syntax is interesting here, since we have again a single key,
NTP, whose value is another key-value pair.
This structure is called a map in YAML. If you are curious and want
to know more about YAML syntax, you'll find many guides on the internet.
If you are like me, allow me to recommend the Complete idiot's
introduction to YAML.
Now that you know how personalization data can be submitted to a
server, you may wonder how it is actually processed and executed.
To ingredients are required, Nova's metadata API and the cloud-init
package or something equivalent. It is through the metadata API that
Nova makes metadata available to a server.
The server retrieves it from this specific URL, and it receives it in
JSON format, JavaScript Object Notation. There is a second method of
making metadata available to the instance, namely as a CDROM named the config drive.
You just add the option --config-drive=true when you launch the server.
It is up to the server to retrieve SSH keys and generic metadata like
key-value pairs, scripts, and cloud-config files from the metadata API
or from the config drive. It's also up to the server then to process them.
The cloud-init package is probably the most popular solution,
but CirrOS images don't include cloud-init, they have their own method
to process SSH keys and scripts, but they can't deal with cloud-config files.