Shulou(Shulou.com)06/02 Report--

Www.docker.com 's web page has an interesting animation:

From this gif picture, we can easily see that the Docker website is trying to convey such a message that the use of Docker speeds up the process of build,ship and run.

Docker was first introduced in 2013 and is well known as an open source project.

Docker was founded by dotcloud, a technology company that develops the PaaS platform.

Unfortunately, the company closed down in 2016 after opening up Docker because its main business, PaaS, was unable to compete with PaaS giants such as Microsoft and Amazon.

Docker is actually one of the specific technical implementations of containerization technology, which is developed in go language. When many friends first come into contact with Docker, they think that it is a more lightweight virtual machine, which is actually wrong. There is an essential difference between Docker and virtual machines. The container is essentially a process running on the operating system, but with the isolation and restriction of resources. Docker is based on the design idea of container and the core management engine based on Linux Container technology.

Why is resource isolation and restriction more important in the cloud era? By default, all running processes in an operating system share CPU and memory resources. If the program is not designed properly, in the most extreme case, a process with a dead loop may exhaust CPU resources, or most of the system resources may be consumed by memory leaks, which is unacceptable in enterprise-level product scenarios, so process resource isolation technology is very necessary.

When I first came into contact with Docker, I thought it was a new technological invention, and then I learned that the Linux operating system itself supports virtualization technology at the operating system level, called Linux container, which is the full name of LXC that you can see everywhere.

Three major features of LXC: cgroup,namespace and unionFS.

Cgroup:

The full name of CGroups is control group, which is used to limit the resource use of a process and is supported by the Linux kernel. It can limit and isolate the physical resources used by the Linux process group (process groups), such as cpu, memory, disk and network IO. It is the physical basis of Linux container technology.

Namespace:

Another dimension of resource isolation technology, you can compare this concept with the namespace in C++ and Java that we are familiar with.

If CGroup is designed to isolate the physical resources described above, namespace is used to isolate system resources such as PID (process ID), IPC,Network, and so on.

We can now assign them to specific Namespace, and the resources in each Namespace are transparent to other Namespace.

Processes in different container belong to different Namespace, transparent to each other and do not interfere with each other.

Let's use an example to understand the need for namespace.

Suppose multiple users have purchased the Nginx service of a Linux server, and each user is assigned an account of the Linux system on that server. We want each user to access only the folders assigned to him, which, of course, can be achieved through the permission control of the Linux file system itself, that is, a user can only access those folders that belong to him.

But some operations still require system-level permissions, such as root, but it is certainly not possible to assign root permissions to every user. So we can use namespace technology:

We can virtualize a namespace for a user with UID = n. In this namespace, the user has root permission, but on the host, the user with UID = n is still an ordinary user and is not aware that he is not a real root user.

In the same way, the process tree can be virtualized through namespace.

Within each namespace, each user has his own init process, pid = 1, as if he owns a physical Linux server.

For each namespace, it should look like a separate Linux computer with its own init process (PID is 1), and the PID of other processes increases sequentially. There are init processes with PID 1 in both An and B spaces, and the processes of the child container are mapped to the processes of the parent container. The parent container can know the running status of each child container, while the child container is isolated from the child container. As we can see from the figure, process 3 has a PID of 3 in the parent namespace, but in the child namespace, it is 1. In other words, the user looks at process 3 from child namespace A just like the init process and thinks that this process is their own initialization process, but from the perspective of the whole host, it is actually just a space virtualized by process 3.

Look at the picture below to deepen your understanding.

The parent container has two child containers, and there are two processes in the parent container's namespace, id is 3 and 4 respectively. After mapping to the two child namespaces, they become their init processes respectively, so that users of namespaces An and B think they own the whole server.

Six namespace supported by the Linux operating system so far:

UnionFS:

As the name implies, unionFS can jointly mount the contents of multiple directories (also known as branches) on the file system to the same directory, and the physical locations of the directories are separate.

To understand unionFS, we first need to know bootfs and rootfs.

1. Boot file system (bootfs): contains operating systems boot loader and kernel. The user will not modify this file system.

Once the boot is complete, the entire Linux kernel is loaded into memory, and then the bootfs is unloaded, freeing up memory.

The bootfs of different Linux distributions of the same kernel version is the same.

2. Root file system (rootfs): contains typical directory structures, including / dev, / proc, / bin, / etc, / lib, / usr, and / tmp

These are the folders in my picture below:

Plus all the configuration files, binaries, and library files needed to run the user's application. This file system is different in different Linux distributions. And the user can modify this file.

When the Linux system starts, the roofs is first mounted in read-only mode, then modified to read-write mode after startup, and then they can be modified.

The technology for implementing unionFS may vary with different versions of Linux. Use the command docker info to view it. For example, the implementation technology on my machine is overlay2:

Look at a practical example.

Create two new folders, abap and java, and create two empty files with the name of touch:

Create a new mnt folder, use the mount command to merge the abap and java folders to the mnt folder, and-t execute the file system type as aufs:

Sudo mount-t aufs-o dirs=./abap:./java none. / mnt

After mount is completed, check under the mnt folder and find a total of 4 files from the abap and java folders:

Now I go to the java folder to modify the spring, such as adding a line of spring is awesome, and then go to the mnt folder to check, and find that the contents of the files under the mnt are also automatically updated.

So what happens the other way around? For example, I modify the aop file under the mnt folder:

The original files under the java folder are not affected:

In fact, this is the technical basis for the layered implementation of Docker container images. If we browse Docker hub, we can see that most images are not made from scratch, but based on some base images, such as debian basic images.

The new image is made up of layers of new logic superimposed on the basic image. One of the advantages of this hierarchical design is resource sharing.

Imagine a scenario where 100 containers based on debian base images are running on a host. Is there a duplicate copy of debian in each container? This is obviously unreasonable; with Linux's unionFS, the host only needs to keep one base image on disk and only one copy needs to be loaded in memory to be shared by all containers based on this image.

When a container modifies the contents of the underlying image, such as files under the / bin folder, will the / bin folder of other containers change?

According to the write-time copy technology of the container image, the modification of the basic image by a container will be limited to a single container.

This is the container Copy-on-Write feature that we will learn next.

The container image consists of multiple mirror layers, all of which are joined together to form a unified file system. If there is a file with the same path in different layers, such as / text, the upper / text will overwrite the lower / text, that is, the user can only access the file / text in the upper layer.

Suppose I have the following dockerfile:

FROM debian

RUN apt-get install emacs

RUN apt-get install apache2

CMD ["/ bin/bash"]

Execute docker build. Look what happened.

The generated container image is as follows:

When you start the container with docker run, a new writable layer is actually added to the top of the image. This writable layer is also called the container layer.

After the container is started, all the changes to the container and the addition, deletion and modification of files will only occur in the container layer and have no effect on all read-only mirror layers below the container layer.

For more original Jerry articles, please follow the official account "Wang Zixi":

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.