Why is a Docker container not a virtual macine?

I'm not clear on the difference between a virtual machine and a container. They both seem to be trying to accomplish the same thing. What makes them different, and why have containers risen in popularity in recent years?

Comments

[Austin S. Hemmelgarn]

For completeness sake, your first listed 'main advantage' isn't something exclusive to containers, they just make it easier.

It's possible to do it with QEMU (done it before, direct boot of Linux in a barebones system (only hardware was VirtIO interfaces, no ISA, no legacy devices, etc) with nothing more than an init process (for proper powerdown support and a process reaper), the service being run, and SSH (for debugging)), Xen (same general concept as QEMU, just using PV domains, or you do nano-kernel OS-es (see for example documentation for running xenstored as a DomU instance)), and pretty much any other hypervisor that can be easily scripted which doesn't require you to emulate a full machine in the first place (which is admittedly not many others). I've even seen some software ported to run on RTEMS (single-process POSIX model, wicked fast boot times) for this type of thing. The difficulty there is setting them up in the first place, which isn't nearly as bad with containers.

[Austin S. Hemmelgarn]

The key difference is where the virtualization is happening. A virtual machine is virtualized at the hardware level (that is, it has virtual hardware), while a container is virutalized at the OS level (that is, the OS itself is virtualized).

This leads to a number of at times subtle, but often significant differences:

• The lack of virtualized hardware means that containers always have to match the host CPU architecture (well, not always, but it's a serious pain to run containers for a different architecture than the host). It also means, however, that you have fewer layers of indirection, and thus generally better performance. This is almost always a favorable trade-off, as the practical uses for cross-architecture VM's are few and far between (pretty much, you only really need them for embedded software development and testing, and mobile app development and testing).
• Similarly, because the OS itself is what's providing the virtualization, you can only run containers for the same OS as the host (though there are very specific exceptions to this). This is generally considered a fair trade-off because it's unusual to run truly heterogeneous infrastructure that would be impacted by this (most places run mostly one OS for their infrastructure).
• From a security perspective, the attack surface is rather different. Containers are theoretically more secure than a type-1 (bare-metal) hypervisor (like Xen, Hyper-V, and VMWare ESXi) because compromising the container software does not get you access at a lower level than the host system, but less secure than a type-2 (hosted) hypervisor (like VirtualBox, Parallels, QEMU, or VMWare Workstation) because compromising the container software often means you have kernel-level access to the host. Regardless, the attack surface is smaller than a VM, because there is less being emulated/virtualized. This is the part where things get complicated (most advocated uses of containers would be using type-1 hypervisors, so they're usually better).
• Because the OS itself is being virtualized, most of the contents of containers can be managed just like other processes on the host. This makes it easier to properly distribute resources when over-provisioning a system with containers than VM's, which is further helped by the (usually) improved performance.

The last point is probably the biggest contributor to the rise of containers over VM's. Most hypervisors make you commit a fixed amount of resources to each VM, so it's hard to reliably over-provision and not unusual to have large percentages of your system not being utilized to the fullest. Containers are more easily flexible in that respect, so it's easy to over-provision, and much easier to ensure that everything that can be used on your system is being used.

[Jesse Phillips]

Like Diane mentioned, VM is hardware emulator, but unlike Wine containers also do not translate system calls.

Containers come as a solidification of functionality which Linux already supports, chroot. / (root) in Linux being the very top level of the file system (and everything is a file) means your entire system can be redefined anywhere. No emulation, just moving the top level of your system.

[Steve Blundy]

Here's a great conference talk on how containers work under the hood and that helped me understand the difference between them and VMs

youtube.com/watch?v=8fi7uSYlOdc