In this video from the 2018 Red Hat Summit, Dan Walsh and Mrunal Patel lead a journey through a set of next generation tools for creating, deploying, and maintaining containers.
[youtube=https://www.youtube.com/watch?v=msdaf3lBOn0&w=560&h=315]
This journey covers tools such as CRI-O, Buildah, and Skopeo, which are being developed with other tools by Red Hat and the community into a complete toolchain for developing, operating, and maintaining Open Container Initiative (OCI)-compliant containers.
At the core of Dan and Mrunal’s presentation of these next generation tools is a straightforward argument. They argue that working with containers is best done by relying upon the strengths of Linux as an OS platform.
One of those main strengths of Linux are the many, many existing tools already built in the UNIX fashion, to which Dan calls attention to with characteristic humor. These are lightweight programs that do a small set of jobs very well, which can be connected with other tools and called in a Bash script. They are already on or packaged for a Linux container host.
The tools the Red Hat container engineering team build and and champion carefully follow the same UNIX/Linux style. This helps achieve a goal Dan and Mrunal introduce, #nobigfatdaemons. That is, going away from a heavy-impact, monolithic daemon approach for a container runtime environment.
After running through the background of what containers are and how they work, Dan spends a little time with key building block libraries. The point here is to show how the next generation tools use these building blocks.
The first building block, containers/image, is a Go library that is used to manipulate containers’ images and container image registries. The second, containers/storage, is for storing filesystem layers, container images, and containers. Neither has a native CLI but the Skopeo program can be used, as described later in the video.
The third building block is a technical specification from the Open Container Initiative, the OCI Runtime Spec. This spec is defined and maintained by the container development community. An implementation of the OCI Runtime Spec is ‘runc’, and is the fourth building block defined.
A fifth building block touched upon are Kata containers, which are lightweight virtual machines that run in containers. Kata containers operate as a container runtime, similar to runc.
From there the duo explain through how CRI-O came about and works. CRI-O is an OCI-based implementation of the Kubernetes Container Runtime Interface. It is a slim, tight daemon focused solely on running for Kubernetes — “nothing more, nothing less.”
By requiring all code going into CRI-O to pass all upstream Kubernetes tests, the CRI-O team are able to release in lock-step with upstream releases.
CRI-O, which is now powering nodes for OpenShift Online, has a simple mission of making running containers in production as boring as possible.
Although CRI-O already uses or plans to use the other next generation tools Dan and Mrunal cover, they are not exclusive to CRI-O. Most of these tools have capabilities to work with other container runtime environments and tools.
- runc — implementation of the OCI runtime specification.
- Buildah — tool that facilitates building and manipulating OCI container images.
- podman — part of the libpod library, podman is a tool for running OCI-based containers in pods. Overall, libpod also is a way to experiment with new ways of creating pods.
- Skopeo — tool for performing operations on container images, such as moving them directly between registries (without having to pull locally, then push to the new remote), moving a container to a container registry or into storage, directly into a daemon or a file, and so forth.
- conmon — a stand-alone mini-daemon utility for monitoring, logging, handling TTY, serving attached client, detecting and reporting out-of-memory conditions, and so forth. (Although this utility is part of the CRI-O project, it can be used stand-alone — such as by podman — and writes to the common Kubernetes log format.)
Throughout the presentation, Mrunal and Dan emphasize that these tools all begin with a desire to experiment with containers using just enough tool to accomplish the task.