Container Runtimes (3): Advanced container runtime

introduction

This is the third article in the series. In the first article, the container runtime is outlined, and the difference between the low-level container runtime and the high-level container runtime is introduced; in the second article, I detailed the low-level The container runtime and build a simple low-level container runtime. The technology stack of the high-level container runtime is higher than that of the low-level container runtime. The low-level container runtime is responsible for the actual operation of the container, and the high-level container runtime is responsible for container image transfer and management.

Generally, the high-level runtime provides daemon applications and APIs, and remote applications can use them to logically run the container and monitor it, but they are located in the underlying runtime or delegated to the underlying runtime or other high-level runtimes for actual work .

The high-level runtime can also provide functions that sound a bit low-level, but these functions can be used in various containers on the computer. For example, one of the functions may be the management of the network name space and allow the container to join the network name space of another container.

Here is a conceptual diagram to understand how the various components fit together:

Advanced runtime example

To better understand the advanced runtime, please look at some examples. Like the low-level runtime, each runtime implements different functions.

Docker

Docker is one of the earliest open source container runtimes. It is developed by dotCloud, a company that provides PaSS services, and is used to run its users' web applications in containers.

Docker is a container runtime, which includes building, packaging, sharing and running containers. Docker has a C/S architecture and was originally built as a whole daemon, dockerd and docker client programs. The daemon provides most of the logic for building containers, managing images, and running containers, as well as an API to get information from the daemon by running commands from the client command line.

It is the first popular runtime, and it integrates all the functions needed in the life cycle of building and running a container.

Docker initially implemented both high-level and low-level runtime functions, but later these parts were broken down into separate projects for runc and containerization. Docker now includes dockerd daemon, docker-containerd daemon and docker-runc. docker-containerd and docker-runc are just versions of "vanilla" containers and runc packaged by Docker.

dockerd provides functions such as building images, while dockerd uses docker-containerd to provide functions such as image management and running containers. For example, the build steps of Docker are actually just some logic that interprets the Dockerfile, uses containerd to run the necessary commands in the container, and saves the generated container file system as an image.

containerd

Containerd is an advanced runtime separated from Docker. Just like runc is decomposed into low-level runtime components, contained is also decomposed into high-level runtime components of Docker.

containerd implements downloading images, managing images, and running containers from images. When the container needs to be run, it decompresses the image into the OCI runtime bundle, and then packages it into runc to run it.

Containerization also provides APIs and client applications that can be used to interact with it. The container command line client is ctr.

ctr related commands
Extract the container image:

$ sudo ctr images pull docker.io/library/redis:latest

List all current mirrors:

$ sudo ctr images list

Run a container from the image:

$ sudo ctr container create docker.io/library/redis:latest redis

List running containers:

$ sudo ctr container list

Stop the container:

$ sudo ctr container delete redis

These commands are similar to the way users interact with Docker. However, compared with Docker, containerd only focuses on running containers, so it does not provide a mechanism for building containers. Docker focuses on use cases for end users and developers, while containerd focuses on operating specific container instances, such as running containers on servers, while tasks such as building container images are left to other tools.

rkt

In the previous article, I mentioned that rkt has both low-level and high-level features of the runtime. Like Docker, rkt allows you to build container images, obtain and manage container images in a local repository, and run them with a single command. rkt lacks the functionality of Docker because it does not provide long-running daemons and remote APIs.

You can use the following command to get the remote mirror:

$ sudo rkt fetch coreos.com/etcd:v3.3.10

List local mirrors:

$ sudo rkt image list
ID                      NAME                                    SIZE    IMPORT TIME     LAST USED
sha512-07738c36c639     coreos.com/rkt/stage1-fly:1.30.0        44MiB   2 minutes ago   2 minutes ago
sha512-51ea8f513d06     coreos.com/oem-gce:1855.5.0             591MiB  2 minutes ago   2 minutes ago
sha512-2ba519594e47     coreos.com/etcd:v3.3.10                 69MiB   25 seconds ago  24 seconds ago

Delete the mirror:

$ sudo rkt image rm coreos.com/etcd:v3.3.10                       
successfully removed aci for image: "sha512-2ba519594e4783330ae14e7691caabfb839b5f57c0384310a7ad5fa2966d85e3"
rm: 1 image(s) successfully removed

Although rkt does not seem to be actively developed, it is an interesting tool and an important part of the history of container technology.