What is the real difference between a container and a virtual machine?
[Editor's note] This article mainly introduces the difference between container and virtual machine. In terms of strategy, performance and security, the author answers the question of the difference between container and virtual machine.
"What is the difference between Docker and the virtual machine?", Which seems to be one of the most common questions I have heard about the container, and the answer I generally gives depends on the different ways in which this problem is raised. But I like to start with this: "containers and virtual machines are just like they are all provided with an isolated environment." Then I set out the difference between them, "the container can do much less and use it quite cheap. The whole virtualization hardware layer can do more things but use the cost significantly. "I think someone will have the biggest reason is that the two technologies seem similar in function, at least the first point of view.
"How does it affect my deployment strategy?"
Some people want to jump directly to the conclusion or the results they want. "How will this affect my deployment strategy? I just go to the cloud, do you really want to change everything and come back? How much does it cost? How much does it cost to learn?
If you explain them from start to finish, they will usually be curious by doubt. Show them the items, such as Docker, how to use the container more easily, and how to integrate the projects that have been implemented with the tools they are using. They will understand, although there are still some work to do, but learning and integration is easy. They will still want to get more details.
"What about its performance?"
"How is its performance?" The problem is even more common than the first. I'm not sure what they want to hear, and why they will ask, but the answer will surprise them: performance is very close to bare metal (direct / non-virtual) performance. They will not believe, but the reason is that isolation is not virtualization.
Docker volumes just bind the mount file (the file is like a pointer to a location on the disk, and it creates a binding mount just to create another file that points to the same place). Reading or writing the file is basically as cheap as bare metal operation. On the other hand, reading or writing a Docker container file system other than
Volume is expensive. So do not do that
Docker networking like a bare metal network. There is a set of virtual (ie logical) Ethernet interfaces created for each container. Any network performance degradation is due to additional internal beating, such as: NAT.
The container is built on a set of functions provided by the Linux kernel on the wall. There is little need for additional processing or redirection for IO (if any). The container is cheap. Because the software that makes them work is built into the operating system, you can stop (or at least reduce) the expense (or cloud instance) of the virtualization software.
"Is it not safer than the virtual machine?"
Of course, smart talk will ask, "is it more than the virtual machine is not safe?" At present it may be …….
This is more complicated because it depends on what you are doing with them. For a comprehensive understanding please refer to PPT-Docker, Linux Containers (LXC) with Safety by Jérôme Petazzoni . I will try my best to summarize.
The container uses the namespace provided by the Linux kernel. Most people consider the namespace as a context or domain authorization decision (process X has access to the resource Y).
If the process inside the container scans the file system to find something to steal, it can only find files that are clearly visible in the container. If the container in the process to try to do some malicious things, such as opening the port 31337 back door service, it will not have much benefit, because the port will not actually be exposed to any place outside the container. The malicious process inside the container can not access any other memory outside the container.
There are several ways to get rid of the shackles of the container, but these usually require root access to the container. Do not run the application as root. Simplify root access with a few simple steps.
The container uses the cgroup to provide the same level of resource usage protection as the virtual machine. Both the container and the virtual machine can get the entire network link.
Some people will point out that not all Linux kernels are namespaces. This means that some resources are not yet isolated. This may be true, but it is changing. The integration of other solid tools like AppArmor or SELinux can help you build some real fortresses. If there is extra work to bring the container to the same level of security as the virtual machine, it is worth it.
- The isolation provided by the container for declining software integration can be declaratively reduced. The virtual machine is rigid.
- The containers are running an incomplete operating system (although they can). The virtual machine must run intact.
- Containers use less idle resources than virtual machines. They do not run a complete operating system.
- Containers can be multiplexed in cloud hardware (or virtual machines), just as virtual machines can be reused on bare metal. The difference is …
- The container needs to be allocated in milliseconds. The virtual machine takes a few minutes. So, you can reprovision, rebalance, release and use containers faster than virtual machines iterations.
Honestly, I feel most silly. The most common reason for my experience is that people provide hardware (virtual or physical) that is provided by the isolation.
If each container is running only one service or database, it is easier to manage. And easier to monitor performance, understand the impact of failure, and predict costs. Like Amazon, the team has their own software and hardware, and isolation is one of the keys. Have you shared an important resource for load balancing with other teams? So, when your service sets their VIPs as a surrogate queue instead of spillover, they will fail or you will be awakened in the middle of the night, and you will be eager to be isolated.
The farther away from the target process, isolation will become more expensive. The virtual machine is great, it is abstract to increase parallelism, serve the use of multiple operating systems and the industry's best security. But for isolation, they are quite expensive.
The isolation provided by the container is cheap. Get it hot.
If you want to read more about Docker and the contents of the container, please check my book "Docker in Action" . You can now browse the electronic version at
Manning Early Access Program .
The original link: Containerization is not Virtualization (translation: Tian Hao Hao )
Translator introduction <br /> TIAN Hao-hao, USYD graduate student, specializing in Docker study study
Email: email@example.com .au