High-level launch environments

From the translator

This is a translation of the article link

Author of the original article: Ian Lewis.

Link to the previous part

This is the third part of my runtime series. A lot of time has passed since the first part, in which I talked about launch environments and the difference between low-level and high-level environments. In the second part, we dived into the details of low-level environments and put together the simplest runtime.

High-level environments are the highest link. Low-level environments are responsible for launching containers, while high-level environments are responsible for transporting and managing container images, unpacking and transferring the container to low-level environments for launch. Usually high-level runtimes consist of a daemon and an API that allows applications to start and monitor containers, they pass the necessary commands to low-level or other high-level environments.

High-level runtimes support the features of low-level runtimes, but they use a separate container for this. For example, one of these functions is to manage the network, and allow the container to use the network of another non-space.

Here is a conceptual diagram to understand how the components interact with each other:

Examples of high-level launch environments

For a better understanding of high-level environments, it’s best to look at live examples. Like low-level environments, each high-level environment has its own quirks.

Docker

Docker is one of the first container runtime open source projects. It was developed by dotCloud under Platform as a Service and was used to run web applications in containers.

Docker can build, package, share, and run containers. Docker is a client-server architecture and is a monolithic application – it consists of the dockerd daemon and the docker client application. Together with the API, the daemon is responsible for the logic of building containers, managing images, and launching the containers themselves. The client is responsible for sending commands and working with information coming in response from the daemon.

It was the first popular launch environment to combine all the features needed for the build life cycle and run containers.

Docker includes the features of low-level and high-level runtimes at the same time, but it has been split into two separate runc and containerd projects. Now Docker consists of dockerd, docker-containerd, docker-runc daemons. docker-containerd, docker-runc is a vanilla version of the containerd and runc packages.

Dockerd is responsible for building the images and uses docker-containerd to manage them and run containers. Building a container image is the logical interpretation of commands from the Dockerfile using containerd, and saving the result to the container’s file system as an image.

containerd

containerd it is a high-level runtime that has been stripped from Docker into a separate project. Like runc, which has been separated as a low-level environment, containerd has been separated from Docker into its own high-level runtime environment. Containerd allows you to download images, manage them, and run containers. When a container needs to be started, Containerd unpacks the image using the OCI standard and passes the necessary information to runc to start it.

Containerd has an API and a client application to interact with the launch environment. This client is ctr.

Crt is used to download images:

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

View all images:

$ sudo ctr images list

Starting a container:

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

View running containers:

$ sudo ctr container list

And container stops:

$ sudo ctr container delete redis

These commands show how easy it is for a user to use Docker. Unlike Docker, Containerd is focused solely on running containers, so it does not provide a mechanism for creating containers. Docker was focused on user and developer use cases, while containerd was focused on specific functionality, such as running containers on servers. To create container images, other tools are used.

rkt

In the last post, I mentioned that rkt includes the functions of two types of environments (low-level high-level). Like Docker, rkt allows you to build, manage images in a local repository, and run containers with just one command. Rkt lacks the functionality of Docker, it does not have an API.

You can download images from other repositories:

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

You can see local images:

$ 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

And remove them:

$ 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 is no longer very actively developed, it is an interesting tool and an important part of the history of container technologies.

Onward, Upward

In the next post we will talk about orchestrators and I will talk about the perspective of Kubernetes and how it works. Be sure to add my RSS feed or subscribe to tweetoreto be notified of new posts.

In the meantime, you can explore Kuber here:

If you have any suggestions or ideas for a blog, please send them to me on Twitter. @IanMLewis

Thank you Craig Box, Marcus JohanssonSteve Perry, and Nicolas Lacasse for proofreading drafts of this post..