CloudInit: The Good Parts

Cloud-Init is the de facto industry standard for early-stage initialization of virtual machines in the cloud, but few engineers are familiar with everything that it has to offer.

All Linux virtual machines have Cloud-Init in their boot phase, whether they're as small as a t3.nano instance in AWS, as large as a Standard_HB60rs in Azure, or and on-premise OpenStack instance. Originally designed for Ubuntu in EC2, Cloud-Init provides at-first-boot configuration support across most Linux distributions and all major clouds.

Many operators are familiar with supplying a shell script via user-data when provisioning their compute resources, but Cloud-Init has a massive amount of other functionality that is, more often than not, left untapped.

In this talk, Event Store co-founder James Nugent explores that untapped potential by looking through some of the features of Cloud-Init and how to take advantage of them to improve the operability and resilience of your cloud operations.

Transcript

1. Cloud-Init: The Good Parts James Nugent Event Store Ltd @jen20 jen20
2. Why Cloud-Init? • The de-facto industry standard for early-stage initialisation of virtual machines in the cloud running Unix-derived operating systems. • Used to specialise a generic operating system image at runtime to by provisioning a given set of configuration. • Originally developed by Canonical for configuring Ubuntu Linux running in Amazon EC2. • Now prevalent across all major clouds and most Unix-based operating systems.
3. Why Cloud-Init?
4. Why Cloud-Init?
5. Why Cloud-Init? • Building a new machine image for each role a virtual machine must play in your infrastructure can be costly in terms of time: • The cycle of booting a machine, customising it, and imaging can take anywhere from 5 minutes to over an hour. • For rapidly evolving software, building an image for each version of a program increases the amount of time it takes to get that version to production. • Correctly constrained, runtime customisation can provide many of the benefits of an image-based workflow, with different trade-offs. • Image-based workflow can still make use of CloudInit in the image building process!
6. Configuring Cloud-Init
7. Configuring Cloud-Init • The cloud-init package is installed in the operating system images supplied by most clouds. On systemd-based Linux, cloud-init.service usually runs at boot, as a oneshot service. • When started with the init sub-command, cloud-init runs the commands defined in a sequence of modules to specialise the operating system installation for the intended purpose. • Configuration comes from two sources: • Cloud provider-supplied metadata • User-supplied configuration
8. Configuring Cloud-Init
9. Example A Shell Script in User Data
10. A Shell Script in User Data
11. A Shell Script in User Data
12. A Shell Script in User Data
13. Example #cloud-config
14. #cloud-config
15. #cloud-config
16. #cloud-config
17. #cloud-config Schema • #cloud-config is a complex YAML schema, whose valid components are affected by which modules are installed. • Documentation is somewhat hit-and-miss. Most of the information is in the docs, somewhere. All of the information is in the (python) source code of cloud-init. • Unless referring constantly to the code, writing the configuration files can be an iterative process of trial and error until you have a sufficiently large collection of reusable sections which you can cargo-cult into doing what you want. • cloud-init(1) has limited built-in schema validation functionality, but most modern editors will do just as well here with a YAML plugin.
18. #cloud-config Schema
19. #cloud-config Schema
20. #cloud-config Schema
21. Example Host SSH Keys
22. Host SSH Keys
23. Host SSH Keys
24. Host SSH Keys • There is no built-in module for specifying host keys at first boot, so we’ll need to build this ourselves. • Breaking this task down, we’ll need to do a few different things: • Generate some known host keys, and get them to the virtual machine • Move the keys into /etc/ssh before the first time the ssh.service unit starts • To do this correctly, it’s necessary for us to dig into the cloud-init default configuration to see what order modules run in, and choose the correct places to insert our logic.
25. Host SSH Keys • Cloud-init runs in three phases: • Init - essential configuration that must be done early on • Config - configuration that doesn’t affect other stages of boot • Final - configuration that must be run as late as possible • The configuration (by default) lives in /etc/cloud/cloud.cfg, and is YAML. • One of the pieces of configuration sets in cloud.cfg is which modules run in which phase.
26. Host SSH Keys
27. Host SSH Keys
28. Host SSH Keys
29. Host SSH Keys
30. Host SSH Keys
31. More about write-files • File content needs to be provided embedded in the YAML configuration file. • If we wanted to provide them from a remote source, we could use a script to download and verify checksums of whatever files we downloaded. • Properties we can set for each file are: • Content (in one of a variety of encodings) • Path • Owner • Mode
32. Host SSH Keys
33. Generating Host Keys
34. Generating Host Keys
35. Generating Host Keys
36. Generating Host Keys
37. Write-Files Configuration
38. Write-Files Configuration
39. Additional Configuration
40. Multi-part Configuration for User-Data
41. Generating Multi-part Cloud Config
42. Booting a Virtual Machine
43. Booting a Virtual Machine
44. About those docs…
47. ssh_keys Configuration
48. ssh_keys Configuration
49. Debugging
50. ssh_keys Configuration
51. Other Use Cases • Some of the use cases we didn’t look at today, but are easy enough to accomplish: • Change the filesystem types for attached volumes (e.g. to XFS) • Configure a package repository (yum or apt) and install packages at boot • Install Docker, pull and run an image from Docker Hub • Run Chef or Puppet in standalone mode on boot, after downloading or installing the configuration from a package • Write out an /etc/machine-role to use as a base for accessing SSM Parameter Store trees • Join a node to a Serf or Consul cluster • Post a notification to Slack using the “phone home” module
52. Summary • Cloud-init packs in a huge amount of functionality, however it’s not necessarily very discoverable. • It is worth learning at least the basics if: • You want a runtime-specialisation-based workflow • You work across a diverse range of clouds or operating systems and want a common configuration tool
53. Thanks!