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

This article mainly introduces "how to understand the Linux container". In the daily operation, I believe many people have doubts about how to understand the Linux container. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "how to understand the Linux container". Next, please follow the editor to study!

Linux container

This article focuses on Linux containers, why Linux containers are emphasized instead of Docker, because Docker is implemented based on virtualization technology, but this article deals with the core implementation aspects of Linux containers, which are different, so emphasize it.

Container is actually a kind of sandboxie technology. As the name implies, sandboxie can pack your application like a container. In this way, there is a boundary between the application and the application without interfering with each other; at the same time, the application installed in sandboxie can also be easily moved around, which is the ideal state that PaaS wants. But it is easy to say, and when it is really realized, it will be difficult. Because the container runs on the host, when it runs, it needs to be loaded into memory, CPU is required to complete the addition operation, and so on. In other words, if you want to achieve a real container, it is necessary to solve the problem of real isolation between the container and the host, but in reality there is no way to solve this problem.

Since the problem has not been solved, what are we talking about by containers? What is the core function of the container?

Container core function

As mentioned above, container is actually a kind of sandboxie technology, and there is a "boundary" between application and application. So the core function of the container is to create a "boundary" by constraining and modifying the dynamic performance of the process.

This official language may be a little difficult to understand, let's put it another way. Container is Container in English, and Container also means container. When it comes to containers, the first thought in your mind is whether the ship is docked on the shore, and then a lot of neat boxes can be transported back and forth. Why can these containers be easily transported back and forth? Because they're the same size, and they're boxes, right? So when we use Container to describe a container, we want the container to be packable and compliant.

Based on the above, I think we can reach a consensus, that is, if we want the container to help us achieve a state that can be packaged and meet the standards, what is the first problem to be solved? Is to isolate the container from the container, so that I can do a unified operation on the container, whether it is right or not. For most Linux containers such as Docker, there are mainly two techniques for isolating containers and containers: one is the seemingly isolated technology: Namespace, which is the main method used to modify the process view, that is, each namespace application sees a different IP address, user space, and so on. One is the isolated technology: Cgroups technology, which is the main means to create constraints, that is, my server has a total of 8 gigabytes of memory, how can other applications run if they are given to this one application? So Cgroups technology is to impose a restriction on containers.

Namespace

Namespace means namespace, and if you are programming in an object-oriented programming language, you should be familiar with this word. When a team writes code together, it is inevitable that there will be the same class, and the compilation will conflict. If each function has its own namespace, there will be no conflict even if the class name is the same in different spaces. This is true for writing programs, and so is running programs on Linux. When we run multiple processes on a Linux, the process has a global process ID, and the network also has a global routing table. If multiple processes use different routing strategies, it may lead to conflicts among these processes, and the solution is very simple, just put these processes in a separate namespace.

That's true, but there's one thing I want you to know clearly: a process is a program in a static state, and it's just a binary file on disk. It becomes a process only when it is running. Therefore, when we start running the program, the operating system assigns a process number to the process, which is the unique identity of the process. Suppose we start running a program, its PID=100. In other words, this program is the 100th process, and there are 99 processes in front of it. Now, if we run the program in a container through Docker, then Docker will give it a "blind trick" when the 100th process is created, so that it will never see the other 99 processes, so that the program will mistakenly think that it is the first process. This mechanism is actually tampering with the process space of the isolated application, so that these processes can only see the recalculated process number. For example, the 100th process above, after the "blindfold" of Docker, mistakenly thought that it was the first process, but in fact, in the host operating system, it was still the 100th process.

Container limits (Cgroups)

The full name of Linux Cgroups is Linux Control Group. Its main function is to limit the upper limit of resources that a process group can use, including CPU, memory, disk, network bandwidth and so on. A very simple sentence is, your computer has only 8 gigabytes of memory, will you allow a process to occupy 7 gigabytes of your memory? Under normal circumstances, it should not, in that case, do other things will be stuck to death, whether it is right or not. So in Linux, a technique is provided to control the resources that a process group can use. Cgroups has many subsystems, each of which has its own unique resource limitation capabilities, such as:

Blkio: set the Istroke O limit for block devices, which is generally used for devices such as disks

Cpuset: assign a separate CPU core and corresponding memory node to the process

Memory: set memory usage limits for processes

Cpu: use the caller to control CPU access for the process; Linux Cgroups is designed to be relatively easy to use, which is a combination of a subsystem directory and a set of resource restriction files. For Linux container projects such as Docker, they only need to create a control group (that is, a new directory) for each container under each subsystem, and then fill in the PID of the process into the tasks file of the corresponding control group after starting the container process. As for what values to fill in the resource files under these control groups, it is up to the user to specify the parameters when performing docker run.

Through the above analysis, we can see that the concept of container, which sounds mysterious and mysterious, is actually a special process on the operating system. Therefore, the container itself has no value, what is valuable is the "container layout". When we are talking about containers, we are actually talking about how to better arrange containers. That's why K8s is so popular right now.

Similarities and differences between container and virtual machine

Seeing this, do you have any questions about the difference between a container and a virtual machine? You may have seen the following picture:

On the left side of this picture, the working principle of the virtual machine is drawn, in which the software of Hypervisor is the main part of the virtual machine. Through the hardware virtualization function, it virtualizes the host's cpu, memory, and IUnip O devices, and installs a new operating system, that is, GuestOS in the figure, on these virtual hardware. At this point, the user's application process can run on the virtual machine, and all it can see is the files and directories of GuestOS, using the virtual devices in the machine. This is why virtual machines can isolate different application processes from each other, because they are not on the same system.

On the right side of this picture is the container, which consists only of the application itself and its environmental dependencies (libraries and other applications), and runs directly on the host. When you want to start the container, you don't need to boot the entire operating system at all, because it's already on that operating system. Moreover, because the container is directly on the host, all containers share this underlying operating system, and there is no new operating system, which makes the container faster and less expensive in terms of size and startup speed. and easier to migrate.

Remember when talking about containers, the Namespace technology introduced, a virtual machine is real, you can create one directly on your computer, but the container is different, it does not have a real "container" to run in the host, the Docker project helps users start the original application process, only when creating these processes, add the Namespace parameter, but for the host In essence, it's just a process.

At this point, the study on "how to understand the Linux container" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.