Tutorial: Explore Container Runtimes with Flatcar Container Linux

This tutorial is the second part of a series on Flatcar Container Linux, in which we will get familiar with the container runtimes. It also introduces the concept of running a custom version of containerd runtime as a systemd unit file.

Flatcar Linux instances can be launched in mainstream cloud platforms, including Amazon Web Services, Microsoft Azure, and Google Cloud. We will choose Equinix Metal, which gives us the flexibility to run the OS in the bare metal environment.

After signing up with Equinix Metal, we will launch a new on-demand server instance in the nearest supported region.

I chose the Singapore region, and the x1.small.x86 server configuration.

Next, give your instance a name, associate one of the registered SSH keys, and click on the deploy now button.

Within a few minutes, the server will be ready. You can track the progress in the sidebar of the console.

You can customize the instance by adding cloud-init data in YAML format.

Once the instance is ready, copy the IP address to SSH into it.

Exploring Docker Engine

Flatcar Container Linux supports all of the popular methods for running containers. We can choose to interact with the containers at a low-level, or use a higher-level orchestration engine, which is Kubernetes.

Every Flatcar Container Linux instance comes with a stable version of Docker CE and Docker CLI.

The Docker service gets started as soon as the Docker Socket is activated. You can find the systemd unit files, docker.service and docker.socket at /run/systemd/system directory.

If you want to run the Docker service all the time without having to wait for the socket activation, add the following to the user data. This configuration will help when you want to keep running containers with the restart attribute set to always.

Exploring the containerd Runtime

Flatcar Container Linux comes with the containerd CRI plugin, and Dockershim enabled by default. Let’s explore that further by downloading the crictl CLI tool.

We copied the binary to /opt/bin since /usr/bin is a part of the read-only filesystem.

Assuming Docker service is up and running, we can connect to the Dockershim endpoint through with crictl.

Installing and Configuring a Custom containerd Runtime

It is possible to replace default Docker and containerd runtimes with custom versions. In this example, we will run containerd 1.4.1 instead of the default version, 1.4.3.

Let’s download the containerd 1.4.1 binary and move it to /opt/bin directory.

We will create an empty file that will act as the placeholder for the configuration.

Create a systemd unit file with the below content. We are calling this containerd141.service to avoid the conflict with the current runtime configuration.

Before activating this, let’s stop Docker and container containerd services.

Let’s activate the containerd 1.4.1 service.

We can now test the version of the runtime with the crictl tool.

Notice that we are using the native socket of containerd instead of the Dockershim.

To initialize a custom version of containerd during the boot process, we can embed it in the Ignition file’s configuration, which we will explore in the next part of the series. Stay tuned.

Janakiram MSV’s Webinar series, “Machine Intelligence and Modern Infrastructure (MI2),” offers informative and insightful sessions covering cutting-edge technologies. Sign up for the upcoming MI2 webinar at http://mi2.live.

Feature image by Russ Ward on Unsplash.