The Ignition Trilogy — Bootstrap

Back in 2018, Red Hat acquired CoreOS which built Container Linux, a light weight operating system to run container workloads. It was based on Linux kernel and provided only the functionality required to run containerized applications.

On May 26, 2020, CoreOS Container Linux reached its end of life and it’s official successor was Fedora CoreOS. Red Hat OpenShift container platform uses Red Hat Enterprise Linux CoreOS (RHCOS) based on this upstream version as the only supported operating system for it’s control plane nodes.

One of the pre-requisite of installing CoreOS is you must have an ignition file. This is also a requirement to create OpenShift nodes. In this series, Let’s explore what these ignition files are and what they actually do.

Let’s bootstrap 🚀

Ignition is a provisioning utility that reads system configuration file in JSON format and provisions a CoreOS node. Configuration file contains details about components like systemd units, users, storage and filesystems. It executes only once in the initramfs during the first boot. Ignition files are specified with “.ign” extension and encoded in base64 format.

Butane is a utility that reads a YAML format configuration file and converts it into a config file which is read by the Ignition utility during the boot process.

During OpenShift deployment, three ignition files are generated i.e. bootstrap, master and worker all with “.ign” extension. In this post, we will focus on the “bootstrap.ign” file.

Installation process in OpenShift based on a bootstrap machine which hosts the required information for the control plane to start. Bootstrap node runs a single node etcd cluster and a temporary control plane.

Bootstrap node uses the “bootstrap.ign” file generated by the openshift-install client by consuming the “install-config.yaml” file. In this post, we are going to focus only on the contents of bootstrap.ign file.

Users: As discussed earlier, ignition files contains configuration data. In the OpenShift nodes, by default there is only a single user “Core” created during the installation. It is due to the fact that the ignition file contains this user as well as the SSH keys that are specified in the install-config.yaml file.

Configuration files: There is a lot of configuration data that is present in the bootstrap.ign file. But in this post, we will focus on the important ones only.

1. /etc/containers/registries.conf — By default in a connected environment, this file doesn’t has any information.
2. /root/.docker/config.json — Pull secret required to authenticate against Red Hat hosted repositories to pull images
3. /usr/local/bin/bootkube.sh — Script to trigger the bootstrap deployment process. This in-turn calls several other scripts during the process
4. /usr/local/bin/crio-configure.sh — Configure CRIO which is the container run time interface used by OpenShift
5. /usr/local/bin/release-image-download.sh — Triggers the podman command to download/pull the initial CoreOS image
6. /opt/openshift/manifests — All the manifest files generated using the install-config.yaml file definition are placed under this location
7. Some of the these manifests are also the root-ca certificates that are used to generate certificates for other OpenShift components
8. /opt/openshift/openshift/99_kubeadmin-password-secret.yaml — Default kubeadmin password. This is the static password that is displayed later as part of the cluster installation status
9. /etc/motd — If you have ever logged into a bootstrap node during installation, you would have come across below message. It is due to the motd file updated during the ignition process

“This is the bootstrap node; it will be destroyed when the master is fully up. The primary services are release-image.service followed by bootkube.service. To watch their status, run
e.g. journalctl -b -f -u release-image.service -u bootkube.service”

Systemd Units: Most of the script (.sh) files shared above aren’t executed directly. Instead they are wrapped under a systemd unit file and triggered using it.

For example in the above configuration list there is a “bootkube.sh” script that triggers the bootstrap deployment. This is triggered using a “bootkube.service” systemd unit file.

While most of the ignition process is automated you can always view the contents of the file to understand better. Run the below command to list the contents.

cat $HOME/testconfig/bootstrap.ign | jq

In this initial post, I have provided insights into the contents of the bootstrap ignition file. In the future posts, I will cover about the other two ignition files generated during install process.

If you would like to know more about this topic, feel free to DM or comment on the post.

References:

Installing Fedora CoreOS on bare metal
Creating a ignition file
CoreOS Container Linux

Disclaimer:

The views expressed and content shared are solely of the author and doesn’t associate with author’s employer in any way. All the content shared is based on personal experience. This doesn’t guarantee the correctness of the information provided and it is readers responsibility to verify and use the content. All trademarks are property of their respective owners.