About cloud-init¶
Cloud-init is a versatile server deployment tool developedd by Canonical, the people that bring us Ubuntu, MAAS, and Snaps, etc.
Cloud-init relates to MAAS in a sense that MAAS leverages cloud-init to do automated system deployment of any system you can setup with Hashicorp’s Packer, or standard “cloud images.”
A “cloud-image” is the beginnings of a new Operating system in the form of a compressed raw disk image. We can download these images with CLI tools and script out creating a VM, or we can crack open the image and extrapolate that data onto new hard drives with a little bit of PXE dust and a skilled Linux artist.
How does it work?¶
We install and run cloud-init on a system when we are ready to scale up resources. After cleaning up after ourselves, the admin installs and runs cloud-init to configure system reconfiguration early during the next operating system boot.
If you are familiar with “sysprep” with old school Windows imaging, you can imagine what cloud-init does. It tells the computer to get ready for new SSH keys, Network configuration, and resets logging.
Doing all this work efficiently on the very first boot is impressive, yet what comes next is even better. By supplying additional special files during that magic first boot, we can add/remove configuration and settings to dynamically configure systems.
In a hypervising context, we’ll usually generate a tiny cidata.iso file that is mounted to a virtual CD-ROM drive. The .iso hands off these files to cloud-init to instruct with:
Metadata: Unique identifiers for the machine. Machine-ID, and Hostname
Vendordata: Configuration for the very first boot, and only that boot. Vendor data is where I configure SSH, the QEMU guest agent, and networking: the non-negotiables for ensuring that the systems deploy and are sheparded into the network.
Userdata: Configuration that will run if we attach another cidata.iso and reboot. In ProxMox, we can apply userdata to configure user-credentials, run package manager updates, or to reconfigure Netwworking.
Network-config: Reconfigure netwworking at boot. Very handy for setting a new IP after migrating and instance to a new networking space.
Not working with a VM? It’s all good! We can pass cidata to baremetal hosts using a PXE server and the right kernel-line parameters..
Fun with YAML¶
Cloud-init configuration comes in different attitudes called “Datasources” that support different commands across multiple configuration blocks. The ironically named “NoCloud” datasource offers a very flexible API that supports layers of configuration while the “wsl” datasource that applies to the operation of a Microsoft wsl container. The wsl datasource can’t specify a manual IPv4 address while NoCloud can setup any aspect of your host networking.
Some datasources differ in whether they support Vendordata. How cloud-init decides on which datasource applies to your cidata is complex, so you’ll want to generally pick one datasource to write to. Combining datasources is possible, but requires a little extra work on setting up the cidata, not a typical out-of-the-box feature.
Regardless of which set of Documentation you decide to follow, you’ll be writing YAML. Datasources may differ in how the keys are expected to be named, but you may be able to adapt code from one datasource to another with an edit or two.
Be prepared to write small configuration files right inside the userdata, like a “heredoc”.
It’s a handy trick for placing an authorized_keys file or configuring /etc/hosts.
YAML is a joy to edit, but you’ll want to use yamlint and learn the ways of vim or emacs.
With great power…¶
Cloud-init should not be installed lightly. Leveraging cloud-init puts your host in a vulnerable state, and without instruction at boot, it’s going to try to get a DHCP address on the first interface it sees. For clustered services, losing track of hosts like this can be catastrophic.