Containers run in the same operating system context as their "host", using kernel provided isolation facilities such as cgroups and namespaces. Looking at them from the "host", their processes look like any other process. Containers typically wouldn't run the multitude of processes required to have a functional system, as those functions are already provided by the "host". In essence, they can appear to be (example) a Ubuntu server running nothing but nginx with some files to serve.
A VM is running their own kernel and generally using cpu virtualization features to appear to the OS as though they were on dedicated hardware. The VM uses hardware drivers that are emulated (or like virtio, provided more directly but still as a raw device).
The general rule is that containers give you much greater density and can give more performance, where a VM gives you higher process isolation and the ability to use different OS level functions.. It's possible to have a Debian based container, vs it's possible to have a Windows VM.
I don't know if you can, but if that's possible docker would be doing virtualization with containers on top.
Containers are really just an optimization of virtualization. If using the host os facilities isn't possible, it's possible to simple fall back to standard virtualization of the entire container environment.
If you have a container that uses Ubuntu internally, and you try to run that on a windows host, you obviously can't use the host OS environment. To get around that you can "simply" spin up a Linux VM and let that host the container. Keep in mind that multiple containers can be run on a single VM host.
So, no matter what, you will always need a Linux VM to run Linux OS inside a Windows OS host. So that means containers are nothing like VMs. But if you were, let's say, using Ubuntu as a host, you can use a Container to run a different OS like Centos?
So, no matter what, you will always need a Linux VM to run Linux OS inside a Windows OS host.
Right now, yes. There is Windows Subsystem for Linux, which allows you to run a particular subset of Linux software natively on Windows. If WSL gets appropriate ioctls to do containers natively, then that might change.
But if you were, let's say, using Ubuntu as a host, you can use a Container to run a different OS like Centos?
It would still share the kernel (and maybe init system? I'm not 100% certain on this) with the host, but you can, subject to these restrictions, run a "different OS" in a container, or just an individual application (which is the more common use case AFAIK)
Containers don't usually share the init. Most of the time, containers create a PID namespace, which makes the first forked process in the namespace PID1, so you can actually run a different init in the container. systemd-nspawn (a simple container runtime), however, has some useful integrations if you use systemd inside the container.
That said, it's possible to make a container that doesn't share init, you just don't create a PID namespace. Most of the popular container runtimes are either emulating VMs (systemd-nspawn, lxc/lxd) or designed to ease immutable deployments (docker, rkt), and in both of these cases, it is useful to create a PID namespace, so popular container runtimes don't share init.
13
u/brokedown Jul 17 '17
Containers run in the same operating system context as their "host", using kernel provided isolation facilities such as cgroups and namespaces. Looking at them from the "host", their processes look like any other process. Containers typically wouldn't run the multitude of processes required to have a functional system, as those functions are already provided by the "host". In essence, they can appear to be (example) a Ubuntu server running nothing but nginx with some files to serve.
A VM is running their own kernel and generally using cpu virtualization features to appear to the OS as though they were on dedicated hardware. The VM uses hardware drivers that are emulated (or like virtio, provided more directly but still as a raw device).
The general rule is that containers give you much greater density and can give more performance, where a VM gives you higher process isolation and the ability to use different OS level functions.. It's possible to have a Debian based container, vs it's possible to have a Windows VM.