Ignition on Flatcar Container Linux

Flatcar Container Linux startup process

Mon, 01 Jan 0001 00:00:00 +0000

The Flatcar Container Linux startup process is built on the standard Linux startup process . Since this process is already well documented and generally well understood, this document will focus on aspects specific to booting Flatcar Container Linux.

Bootloader

GRUB is the first program executed when a Flatcar Container Linux system boots. The Flatcar Container Linux GRUB config has several roles.

First, the GRUB config specifies which usr partition to use from the two usr partitions Flatcar Container Linux uses to provide atomic upgrades and rollbacks.

Network configuration

Mon, 01 Jan 0001 00:00:00 +0000

Configuring networkd with Ignition is a very straightforward task. Because Ignition runs before networkd starts, configuration is just a matter of writing the desired config to disk. The Ignition config has a specific section dedicated to this.

Each of these examples is written in version 2.0.0 of the config. Ensure that any configuration matches the version that Ignition expects.

Static networking

In this example, the network interface with the name “eth0” will be given the IP address 10.0.1.7. A typical interface will need more configuration and may use all of the options of a network unit .

Ignition Specification

Mon, 01 Jan 0001 00:00:00 +0000

Ignition uses a JSON format that is specified in several major versions: v1, v2 and v3 (which itself has minor versions like 2.3.0). While v1 and v2 are still supported in Flatcar Container Linux, from version 3185.0.0, it’s recommended to write new configuration with v3.

Ignition v3

Starting from release 3185.0.0, Ignition v3 (specification 3.3.0) is supported in addition of Ignition v2. There are some things to be aware of:

Referencing dynamic data

Mon, 01 Jan 0001 00:00:00 +0000

Overview

Sometimes it can be useful to refer to data in an Ignition config that isn’t known until a machine boots, like its network address. This can be accomplished with afterburn (previously called coreos-metadata). Afterburn is a very basic utility that fetches information about the current machine and makes it available for consumption. By making it a dependency of services which requires this information, systemd will ensure that coreos-metadata has successfully completed before starting these services. These services can then simply source the fetched information and let systemd perform the environment variable expansions.