5 minutes to understand Docker.

Although before heard Docker's name, but the talent is dull, to its in the end is a what thing has been puzzled, recently spent a period of time to tidy up a bit, sort out a little clue.

The official website introduction is such:

Docker is a open platform for developers and SysAdmins to builds, ship, and run distributed applications ....

In fact, after reading this sentence still do not understand what is, the following slowly explained. But to make a long story short, think of him as a super lightweight virtual machine that works in a novel way, and it's probably the right thing to do. Of course, in the implementation of the principle and application or the VM has a huge difference, and the professional name is the application container (creator Container).

Why use a container?

So what does the application container look like, a good application container that looks like a virtual machine that has a set of specific applications installed? For example, I now want to use MySQL then I will find a installed MySQL container, run up, then I can use MySQL.

Then I just install a MySQL not good, why need this container so weird concept? That's what I'm saying, but if you're going to install MySQL, you might want to install a bunch of dependent libraries, set up according to your operating system platform and version, and sometimes compile a bunch of inexplicable bugs from the source code, It's not such a good outfit. And if your machine hangs up, everything will come back, and the configuration may have to be done again. But with the container, you have the equivalent of a virtual machine that can run, as long as you can run the container, the Mysql configuration is all over the province. And once you want to switch machines, just put the container up and put it on another machine. Hardware, operating system, running environment, whatever you need to consider.

A big use in the company is to ensure that offline development environment, test environment and online production environment consistent. That year in Baidu often encountered such things, the development of things done to test, generally will give a piece of code and an introduction to the online step of the online single. The results of the code in the test machine can not run, development ran to see the problem, for a while AH this configuration file forgot to submit, for a while AH this online command to write wrong. Found a bug to put up, develop a look, ah how I forgot to write this command on the online list. Something like that happens when it's online, and it turns out that your version of the software is different from my machine. At Amazon, it was a little less problematic because a developer was directly in the top three positions and had a mechanism for automating deployment.

If the use of containers, then development directly in the container development, testing the entire container to test, measured the changes in the container and then online. Through the container, the entire development, testing and production environment can maintain a high degree of consistency.

In addition, the container and the VM have a certain degree of isolation, the data and memory space between each container isolation, can guarantee a certain degree of security.

Why not use a VM?

So since containers and VMS are so similar, why not just use a VM to complete a container? Docker containers have several advantages over VMS:

The startup speed is fast, the container usually starts in a second, and the VM usually takes longer

High utilization of resources, a common PC can run thousands of containers, you run thousands of VMs to try

Low performance overhead, the VM typically requires additional CPU and memory to complete the OS functionality, which takes up additional resources

Why similar functions can have such a huge gap in performance, in fact, it is related to the concept of their design. The design diagram for the VM is as follows:

The VM's Hypervisor requires virtualization of the hardware and the ability to carry its own operating system, which naturally has a higher cost of start-up speed and resource utilization and performance. And Docker's design is like this:

Docker almost no virtualization of things, and directly reuse host host of the OS, at the Docker Engine level to achieve the scheduling and isolation of the weight of a sudden reduction of several grades. Docker containers utilize LXC, management utilizes namespaces to control and isolate permissions, cgroups to configure resources, and further improves file system resource utilization through AUFS.

The AUFS is a very interesting thing, is a UnionFS. His ideas are similar to Git's, and they can be used as a commit-layer overlay on file system changes. In this way, multiple containers can share their file system hierarchy, each container below is a shared file system level, above all the changes to the file system level, which greatly saves the storage requirements, and can accelerate the launch of the container.