Shulou(Shulou.com)11/24 Report--

This article comes from the official account of Wechat: programming Technology Universe (ID:xuanyuancoding), author: Xuanyuan Wind O

Programmers suffer for a long time one night many years ago, in a storm, a young man named Docker came to the Linux Empire to meet the elders of the Empire.

"Elder Linux, programmers all over the world have been struggling with application deployment for a long time. I want to change this situation. I hope you can help me."

The elder replied, "Oh, at a young age, you have a good tone. Please take a seat first. If you have anything you want, I'd like to hear more about it."

Docker sat down and began to talk eloquently: "in today's world, the dependencies of application development, testing, deployment, and various libraries, coupled with differences between versions, often occur when the development environment is running normally, but there are problems in the test environment and online environment. Programmers suffer a lot, and it's time to change this situation."

Docker looked back at the elder and then said, "I want to make a virtual container for applications to run and package the dependent environment they need, so that after porting on different machines, it can still provide a consistent running environment and completely liberate programmers!"

When the elder Linux heard this, he nodded slightly: "Young people have a good idea, but according to your description, it seems that a virtual machine can solve this problem. Why not deploy the application and the dependent environment to the virtual machine, and then take a snapshot and deploy the virtual machine directly?"

Docker shook his head again and again and said, "the elder knows that the virtual machine is bulky and bulky, and it is always the size of G, because it has to run a complete operating system, so it takes extra effort to run, not to mention slow, and it takes up a lot of resources. It drags down the performance if you can't run a few virtual machines on one machine!" And I want to make a lightweight virtual container, which only provides a running environment and does not have to run an operating system, and the system kernels in all containers are shared with external hosts, so that many containers can be copied in batches, light and fast. "

Elder Linux stood up and paced back and forth for a few times. After thinking for a moment, he suddenly patted the table and said loudly, "that's a good idea. I voted for this project!"

Docker saw the light in his eyes and beamed with delight. "this is really inseparable from the help of the elders. In order to achieve the goals I have mentioned, it is very important for the management and isolation of the process, and I hope the elders can help me!"

"just a moment," Elder Linux turned and returned to the inner room. It wasn't long before he came out with something in his hand.

"Young man, when you get back, feel free to do it. I'll give you three tips. If you encounter a problem, you can take it apart in turn. It will be of great use."

Docker happily accepted three brocade bags, bid farewell to the elders of Linux, and went home in the rain.

1:chroot & pivot_root was encouraged by the elders, and Docker was full of energy and was ready to start his project soon.

As a container, the first task is to limit the scope of activity of the processes in the container-the file system directories that can be accessed. Processes in the container must not be allowed to wantonly access the real system directory. Their activity scope must be delimited to a designated area and must not be overstepped by half a step!

How on earth should we limit the active areas of these processes? Docker encountered the first problem.

Thinking hard for a long time, Docker finally could not help opening the first brocade bag given to him by Elder Linux, and saw the names of two functions written on it: chroot & pivot_root.

Docker never used these two functions, so he asked around the Linux empire about their role. It was later learned that through these two functions, the root directory of the process and system can be modified to a new location. Docker is delighted, the elder is really honest with me!

With these two functions, Docker began to figure out how to "fake" a file system to deceive processes in the container.

In order not to reveal flaws, Docker is smart enough to mount the operating system image file to the root directory of the container process and become the container's rootfs, which is exactly the same as the real system directory.

The problem of the $ls / bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var 2:namespace file system was finally solved, but Docker dared not slack off, because in his mind, there was a big problem that had been bothering him, that is, how to hide the world of the real system so that the processes in the container could not see it.

Such as process lists, network devices, user lists, these must not be let the process in the container know, let them see the world is as clean as a new system.

Docker knows that although he is called a container, this is only a superficial phenomenon. In fact, the processes in the container are all processes running on the host operating system, just like themselves. It is really not easy to cover the eyes of these processes.

Docker thought about using HOOK to cheat the process, but the implementation is too complex, poor compatibility, stability can not be guaranteed, thought about it and did not come up with any good ideas.

At a time of helplessness, Docker thought of the brocade bag given to him by Elder Linux. He hurriedly took it out and opened the second brocade bag. He saw that it was written: namespace.

Docker still doesn't understand what it means, so he asks all over the Linux empire what namespace is.

After a while of deliberation, Docker finally understood that the namespace was a mechanism provided by the empire through which namespaces could be delineated and processes divided into these namespaces.

Each namespace exists independently, and processes in the namespace cannot see processes, users, networks, and other information outside the space.

Isn't that what Docker wants? There is no place to look for iron shoes, and it takes no effort to get them!

Docker hurriedly worked overtime and used this namespace to lock the "field of vision" of the process within the limits specified by the container, so that the process in the container seemed to be blinded and could no longer see the outside world.

The problems of 3:CGroup file system and process isolation have been solved, and the stone in Docker's heart has finally been put down. I was anxious to test my container, but I was curious about what the last kit was about, so I opened the third bag and saw that it read: CGroup.

What is this? Docker still doesn't understand, but it doesn't matter so much this time. Let's get it up and running.

After trying to run it for a period of time, everything was in Docker's plan, and the processes in the container were running normally, deceived by the virtual file system he built and the isolated system environment. Docker was overjoyed!

Soon, Docker began to promote its container technology in the Linux empire. As a result, it became so popular that it gained countless fans, including nginx, redis and so on.

However, behind the flowers and applause, Docker did not know that disaster was imminent.

On that day, when someone from the memory management department of the Linux Empire withheld Docker to "execute" him, Docker asked in surprise, "what happened and why did you do it to me?"

The manager snapped: "the memory managed by the Empire is almost used up by a guy named Redis. Now we have to pick some processes to kill. I'm sorry, you won the lottery."

Redis? Isn't this guy a process in my container? Docker was surprised!

"Gentlemen, I know the elders of the Empire. Please be accommodating. Find someone else, that guy Redis. I have a way to deal with him."

Unexpectedly, he still knew the elders of the Empire, and the management hesitated and let Docker go somewhere else.

Frightened Docker, thinking about it, if you do not control the process in the container, it is simply too dangerous! In addition to memory, there are CPU, hard disk, network and other resources. If a container process occupies CPU and does not let go, or a container process writes hard disk crazily, it will involve itself sooner or later. It seems that these processes must be controlled to prevent them from doing anything out of line.

At this time, he thought of the third bag of the elder Linux: CGroup! Maybe we can solve this urgent need.

After some research, Docker is a treasure. It turns out that this CGroup, similar to namespace, is also a set of mechanisms of the Linux empire, through which you can delineate packets one by one, and then limit the resources that each group can use, such as the upper limit of memory, the utilization of CPU, the total amount of hard disk space, and so on. The system kernel automatically checks and limits the amount of process resources used in these groups.

Linux elder these three tips are so sweet, each more useful than the other, Docker is full of gratitude.

Subsequently, Docker breathed a sigh of relief by adding CGroup technology to strengthen the control of processes in the container.

With the blessing of the three tricks of the Linux elders, Docker became a great celebrity in the Linux empire.

However, the greater the ability, the greater the responsibility, and what Docker did not expect is that new challenges lie ahead.

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.