The public SSH key I just added to the instance is an example of instance personalization.
We are now going to look at other ways of personalizing an instance.
This slide makes you believe that the keys are somehow uploaded to the
instance, but as you will see in a moment, the instance actually
actively retrieves them from the so called metadata service provided by Nova.
Using metadata, you can personalize an instance in many other ways.
The most basic kind of metadata are simple key-value pairs.
This is how they are submitted to the server.
Key-value pairs have no meaning to Nova or OpenStack.
In this example, you might provision several web servers from the same
image, and use a key and servers to configure the number of worker
processes on each instance. A more sophisticated example of metadata
is a script. When launching a server, you can send it a Shell script
or a script in another language that is available on the server,
Perl, Python, whatever it might be. With a script, you can do
practically anything, you can configure user accounts,
add software packages, configure applications that run on the server,
and so on. The script is executed when the server starts up.
Rather than writing scripts, you can also submit a file in cloud-config format.
Cloud-config is a YAML-based descriptive language that describes the
desired outcome, rather than the steps that lead to the outcome.
Finally, you can also copy a file to the server.
You provide the destination file on the instance and the source file
on the current system, for example, like this here.
The db.cfg file will be copied from the local file system onto the
instances file system to/root. There can only be one user data
option, but key-value pairs and file options can be repeated.
You can, by the way, do the same with the Nova client,
only the key-value option is slightly different.
You often hear the term injection, such as injecting SSH keys or
injecting files into an instance. This is a misleading term.
In fact, the instance has to run software that retrieves the data and processes it.
The standard solution for that is cloud-init.
It is installed on all those cloud-ready images, which you can
download from vendors and communities. Cloud-init uses the metadata
service to retrieve the user-data file. If it detects that user data
is a script, it just executes it. If it detects that user data has
the cloud-config format, it has to process this file.
Cloud-init supports other file formats, which we will not cover here.
The formats are determined by the first characters in the user data file.
For documentation, just use the readthedocs site.
In contrast to procedural scripts, cloud-config files are declarative.
A cloud-config file tells the server what changes you want,
but leaves the specific steps up to the server.
Example for changes are adding accounts or software packages.
Cloud-config files are written in YAML, which stands for YAML is not
a Markup Language. The advantage of the descriptive method is simplicity.
Cloud-config files are simpler and more compact than procedural
scripts, and for that reason, they require less development time,
and they generate fewer errors.