Don´t use Docker in production! Use this…

The rise of Docker led to an explosion in the popularity of containers. Since then, there have been a growing number of tools and standards to help regulate the use of this technology.

Unfortunately, it is quite difficult to keep up with the development. The “battles” between the major technology companies add to the confusion for many of us as well.

In this article, I’ll tackle all the important names you’ve heard and try to decipher the jargon for you, and explain how the container ecosystem will work together in 2021.

And if you think you’re the only one who doesn’t understand all this yet, don’t worry…. You’re not alone!

Understanding Docker
There are a difference between Docker (enterprise), Docker containers, Docker images, and the Docker developer tools we’re all used to:

As you can see, you’re not the only one confused. Joe Beda, co-developer of Kubernetes, feels the same way.

This is a perfect opportunity to clear up some of the confusion and help you understand when it’s Docker, contained, or CRI-O. This is especially important if you want to learn about Kubernetes.

It is important to remember the following:

Containers are no longer hardwired to the Docker name. There are quite a few container tools out there. Docker is one of them, and Docker (the company) supports some of those, but not all.

If you still think containers are just about Docker, then read on! We will now take a closer look at the ecosystem around containers.

An overview of the container ecosystem
The container ecosystem is made up of many technologies, technical terminologies, and competing companies. Fortunately, companies sometimes negotiate a fragile truce to agree on certain standards.

These standards help achieve interoperability between different tools and avoid dependency on a particular company or project (technology). The basic standards to consider are:

Container Runtime Interface (CRI) defines an API between Kubernetes and the container runtime.
Open Container Initiative (OCI) defines a standard for images and containers.
The diagram below shows how Docker, Kubernetes, CRI, OCI, contained, and runc fit together in this ecosystem:

The relationship between docker, CRI-O, containerd and runc — in a nutshell.

1. these are tools used to run containers in development or production.

2. CRI (Container Runtime Interface) is a Kubernetes API (application programming interface). CRI defines the way Kubernetes interacts with different container runtimes. Since it is standardized in a specification, you can choose which CRI implementation to use or possibly write your own.

3. you can choose a runtime yourself that conforms to the Container Runtime Interface (CRI) specification. containerd was developed by Docker. CRI plugin is a plugin natively integrated into containerd and enabled by default (from version 1.1). This allows you to run Kubernetes with containerd as a container runtime.

CRI plugin

CRI-O is an open-source project and alternative to containerd and is supported by a number of well-known companies.

4. OCI is an open industry-standard specification that contains two specifications: the runtime specification (runtime-spec) and the image specification (image-spec).

5. runC is an OCI compliant tool for creating and running containers. runc is used to create and run containers according to the OCI specification.

6. our containers are now running…

Docker
We’ll start with Docker, as it is currently the most popular container tool. For many, the name “Docker” itself is synonymous with the word “container.”

Docker has started this whole containerization revolution. Docker has created a very ergonomic and easy-to-use tool for working with containers, which is also called Docker.

1. users/administrators create and launch containers using Docker command.

2. containerd pulls images, manages networks and storage, and uses runc to run containers

3. runc does the low-level “staff” to create and run containerized processes

docker can be installed on a client operating system or on a server operating system. docker includes a set of tools that simplify the work of developers and DevOps engineers. Using the docker -CLI, you can create container images, retrieve them from repositories, and create, launch and manage containers.

Docker consists of three projects:

docker-CLI — is a command-line utility that you interact with using the docker command.

containerd — is a Linux daemon that manages and launches containers. The downloads images from the repository manage storage and networks and monitor container execution.

runc — is a low-level container runtime that actually creates and runs containers. It includes libcontainer, a native Go-based implementation for creating containers.

When you run a container with docker, you actually run it through the Docker daemon, containerd, and then runc.

Dockershim: Docker in Kubernetes.
It is important to note that Kubernetes can only serve container runtimes that support the Container Runtime Interface (CRI). However, Docker cannot directly support this standard. Therefore, Kubernetes includes a component called dockershim, which is required to work with Docker.

In the future (starting with version 1.23), Kubernetes will stop supporting dockershim and, accordingly, Docker, and will only work with container runtimes that support the Container Runtime Interface (CRI) — containerd or CRI-O. (Dockershim Deprecation FAQ)

However, this does not mean that Kubernetes will not be able to run Docker-formatted containers. Both containerd and CRI-O can run Docker-formatted (OCI-formatted) images. They simply do it without having to use the docker command or Docker daemon.

Shim — Technically, a shim is a component in a software system that acts as a bridge between different APIs or as a compatibility layer. Sometimes a shim is added when you want to use a third-party component. You virtually need some “glue code” to make it work.

Docker images
What many people refer to as Docker images are actually images packaged in the Open Container Initiative (OCI) format.

If you want to download an image from Docker Hub or another repository, you can do so with a docker command or with the podman utility, or with another tool that supports the OCI image format specification.

Container Runtime Interface (CRI).
CRI is an API that Kubernetes uses to control the various container runtimes to create and manage containers.

CRI makes it easier for Kubernetes (or rather kubelet) to use different container runtimes. Instead of supporting every possible container runtime separately, only the supported CRI standard is used. In this case, the task of container management lies entirely with the container runtime.

Container Runtime Interface (CRI).
CRI is an API that Kubernetes uses to control the various container runtimes to create and manage containers.

CRI makes it easier for Kubernetes (or rather kubelet) to use different container runtimes. Instead of supporting every possible container runtime separately, only the supported CRI standard is used. In this case, the task of container management lies entirely with the container runtime.

So, if you prefer to use containerd to run your containers, feel free to do so. Or, if you prefer to use CRI-O, then you can use that as well without hesitation. This is because the CRI specification has been implemented in both of these runtimes.

If you are an end-user, the type of implementation should mostly not matter to you. The CRI implementations are designed to be pluggable and seamlessly changeable.

FYI, Red Hat (the OpenShift project) uses CRI-O and is responsible for its maintenance (security, bug fixes, etc.). While containerd continues to be wrapped by Docker.

Which container runtime is used in Kubernetes?
The kubelet (an agent running on each node) is responsible for interacting with the container runtime in the Kubernetes architecture. The main task of kubelet is to send start/stop instructions to the Container Runtime.

The following options are used to configure the Container Runtime: — container-runtime and — container-runtime-endpoint. To find out which Container Runtime is already installed in your Kubernetes infrastructure, use the following command chain:

kubectl describe node <node_name>

containerd
containerd is a high-level container runtime that originates from Docker and implements the CRI specification. сontainerd pulls images from the repository, manages them, and then passes them on to a lower-level runtime that actually creates and runs the container processes.

containerd was separated from the Docker project to make Docker more modular. Thus, Docker also uses containerd for itself. When you install Docker, containerd is also installed automatically. In addition, сontainerd uses its own plugin to support CRI in Kubernetes.

CRI-O
CRI-O is another high-level container runtime that implements the container runtime interface (CRI). CRI-O is an alternative to containerd and has identical functionality.

CRI-O was developed with support from Red Hat, IBM, Intel, and SUSE as a container runtime for Kubernetes. CRI-O provides the ability to start, stop, or restart containers just like containerd.

Open Container Initiative (OCI).
The OCI is a group of technology companies that maintain a specification for container image format and execution.

The idea behind the OCI is that you can choose between different runtimes that conform to the specification. Each of these runtimes has different lower-level implementations.

For example, you have one OCI-compliant runtime for your Linux hosts and one for your Windows hosts. This is the advantage of having a standard that can be implemented by many different projects.

runc
runc is an OCI-compatible container runtime. It implements the OCI specification and executes the container processes.

runc is called a reference implementation of OCI.

What is a reference implementation?
A reference implementation is a software that has implemented all the requirements of a specification or standard. It is usually the first software developed from the specification. In the case of OCI, runc provides all the functionality expected of an OCI-compliant runtime, although anyone can implement their own OCI runtime if they wish.

runc provides all the low-level functionality for the containers and interacts with existing low-level Linux features such as namespaces and control groups. runc uses these features to create and run container processes.

Some alternatives to runc also exist:

crunis a container runtime written in C (in contrast, runc is in Go).
kata-Runtimestimates from theKatacontainers project, which implements the OCI specification as individual lightweight VMs (hardware virtualization)
gVisor comes from Google and can create containers with its own kernel. It implements OCI in its runtime called runsc.

Conclusion
In this article, we have seen that Docker is only a small part of the overall container ecosystem. There are open standards: CRI and OCI, as well as projects like containerd, runc, and CRI-O. We may soon see many new implementations of the container runtime with support for CRI and OCI standards.

Hopefully this article could shed some light on the container world.

--

--

--

Visit me on: Codegrepper or on Github

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Product Development Using Agile (Scrum) Methodology — Restaurant discovery and Food delivery…

Laravel File Permission fpr Server setup

Building Modern Web Dapp with Flutter

Object reference not set to an instance of an object when “Build & Run”

Why does serverless matter?

Corporate O365 but wants/needs Linux? I got your back!

14 Lessons You’ll Learn Through Coding That Can Make You A Better Person (1/2)

7" HD car radio 2 din Autoradio Player MP5 Mirror Link Bluetooth USB SD AUX IN 13 language Touch…

关注店铺有奖 listing.png

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Benjamin

Benjamin

Visit me on: Codegrepper or on Github

More from Medium

Zero-downtime deployment using GitHub and Azure (2 of 3)

Easy Way to Add HTTP Security Headers to CloudFront

Register Gitlab Runners with Ansible

GitLab E2E Pipeline — Logger Application+ELK Stack Deployment Using Terraform+Ansible on AWS