Introducing Ignition: The new CoreOS machine provisioning utility [feedly]

----
Introducing Ignition: The new CoreOS machine provisioning utility
// CoreOS Blog

We are excited to officially introduce Ignition, the next-generation machine provisioning utility from CoreOS. Those who follow along closely may have noticed that Ignition has been a part of CoreOS for the better part of a year. The project has had time to be tested and to mature, and the features and user interface are in a place where we are happy to encourage daily, heavy duty use. It's also a good time to welcome the community to test and help improve Ignition. Before diving into the details, let's understand why we built Ignition in the first place.

Why build Ignition?

CoreOS Cloud-Init

It's been more than three years since we originally shipped our flavor of Cloud-Init. This tool runs after boot, reading a user-provided configuration and fetching platform-specific metadata, then applying that configuration to the running machine. The vast majority of our users employ this utility to configure CoreOS machines, performing a variety of tasks from adding SSH keys to starting an etcd cluster.

CoreOS cloudinit uses a language extremely similar to YAML to describe its configuration, the cloud-config. One of the few differences from standard YAML is that the cloud-config requires a comment on the first line indicating that the remainder of the document is a cloud-config. This, coupled with YAML's type-inferencing nature, makes it difficult to programmatically generate or manipulate a cloud-config. Many languages have a YAML-parsing library, but very few have a library for parsing the CoreOS cloud-config variant. This results in bugs like the leading comment being stripped, thereby invalidating the config, or octal file permissions being converted to decimal, yielding unintended and potentially invalid file modes on disk. Sometimes, a configuration's "off" can even be rewritten as "false", and many failures cascade from there.

It is difficult for cloudinit to properly configure early system services, especially networking, because it runs later in the boot process. Most system services are already up and running by the time cloudinit starts, requiring a reconfiguration that is more prone to errors.

Ignition

Ignition is a new machine provisioning utility designed to solve the same problems as coreos-cloudinit while adding a host of new capabilities with clearer semantics. At the the most basic level, Ignition is a tool for manipulating disks during early boot. This includes partitioning disks, formatting partitions, writing files, and configuring users.

On the first boot, Ignition reads its configuration from a designated source, like a remote URL, a network or cloud provider metadata service, or a hypervisor bridge, and applies that configuration to the machine. Rather than a YAML variant, Ignition uses pure JSON for its configuration format. JSON's type system eliminates the problems that arose with cloud-config YAML, and makes it very easy to write tools to generate new configs or manipulate existing ones.

Ignition runs very early in the boot process. In fact, it runs before systemd is invoked by the kernel as PID 1, before any permanent storage is mounted. This allows Ignition to configure foundation system services and features, like reformatting the root filesystem, creating a RAID array, or configuring the network to use bonded interfaces. Running before systemd helps ensure that all services established by Ignition are known to and can be managed by systemd when it subsequently starts. This allows systemd to do what it does best: concurrently start services as quickly as possible. This results in a simpler startup, a faster startup, and the ability to accurately inspect systemd's unit dependency graphs.

Using Ignition

On first boot, Ignition fetches and evaluates a configuration describing the desired state of the machine. Much like cloud-config, configuration is provided in a file, with the cloud-config simply being replaced by an Ignition config. Unlike coreos-cloudinit, Ignition only runs on the first boot of a machine. It is safe for system administrators or other software tools to make subsequent modifications to the system without them being continually overwritten by original configuration at every reboot.

Ignition's configuration format is versioned to allow clear deprecation points for possible changes to the format in the future. The Ignition v0.4.0 executable accepts configurations in the v2.0.0 Ignition config format. It will also accept v1 configs and transparently convert them.

The simplest Ignition configuration is shown below:

{  "ignition": {  "version": "2.0.0"  }  }  

This configuration isn't very useful since it doesn't actually declare any desired state. The next example is more interesting:

{  "ignition": {  "version": "2.0.0"  },  "storage": {  "files": [  {  "filesystem": "root",  "path": "/home/core/coreos_production_image_pcr_policy.zip",  "mode": 292,  "contents": {  "source": "http://alpha.release.core-os.net/amd64-usr/1010.1.0/coreos_production_image_pcr_policy.zip",  "verification": {  "hash": "sha512-d7c87dad692a1948d729e44184feb2bdc5de24d26561c597a02263a96accfc2a88f87735c8fdccbfea5d90e63cddd986260da007b114d47b7ad4c5a5fc295d2b"  }  }  }  ]  },  "systemd": {  "units": [  {  "name": "unzip-pcr.service",  "enable": true,  "contents": "[Unit]\nConditionFirstBoot=yes\n\n[Service]\nType=oneshot\nExecStart=/usr/bin/unzip /home/core/coreos_production_image_pcr_policy.zip -d /home/core\n\n[Install]\nWantedBy=multi-user.target"  }  ]  }  }  

This configuration will download and unzip a file containing the TPM validation hash values for CoreOS v1010.1.0, using the SHA-512 hash provided in the config to verify the contents of the validation hashes file itself.

Many more examples can be found in the Ignition documentation, including how to construct a RAID array and bond multiple network interfaces.

Supported platforms

Ignition v0.4.0 is included in CoreOS starting in version 1010.1.0, currently in the Alpha channel, and is currently supported on bare metal installations and PXE-booted environments. While older editions of CoreOS shipped with previous Ignition versions, Ignition v0.4.0 is the first to use the v2.0.0 configuration format.

PXE & bare metal

Ignition is particularly helpful on bare metal for network configuration and advanced disk operations because it runs even before PID 1 starts. A URL pointing to an Ignition configuration can be provided with the coreos.config.url kernel command-line parameter. The CoreOS install script also accepts Ignition configuration files, installing them into the OEM partition.

For PXE booting, supply the coreos.first_boot=1 parameter to trigger Ignition. This forces Ignition to run in PXE scenarios where a GPT disk GUID may not exist.

Cloud providers

If you're feeling adventurous, Ignition has experimental support for Microsoft Azure, Amazon EC2, and VMware, with many more providers coming soon. The project is under active development, so expect the supported platforms list to expand in the coming months. Configuration is provided via the same mechanism as CoreOS Cloud-Init, so it's easy to switch to Ignition. Instead of providing your machine with a cloud-config, you can provide an Ignition config.

For more information, check out the official documentation and join us on IRC at freenode/#coreos. Fire up Ignition and let us know what you think! You can also learn more about Ignition and other projects at CoreOS Fest Berlin and CoreOS Fest SF.

----

Shared via my feedly reader

Sent from my iPhone