With all the hype and rapid development around containerization and Docker in the general community of late, you’d be forgiven for experiencing confusion when it comes to understanding some of the differences and separation between platforms / container types etc.
You can run Linux containers on Linux
You can run Linux containers on Windows (Using two different methods)
You can run Windows containers on Windows (Using two different methods)
You can run Windows applications on .NET Core which runs on Linux.
Linux containers on Linux… Easy. We already knew that one.
Linux containers on Windows
In this scenario traditional isolation is not an option because sharing the underlying kernel between Linux & Windows would be incompatible.
There are two options:
Linux containers run in a full Linux VM. (Moby VM)
Linux containers run with Hyper-V isolation, this is referred to as (LCOW)
Moby VM
This model hosts a Linux distribution (https://github.com/linuxkit/linuxkit) as a Hyper-V based VM which runs the Docker Daemon and all its dependencies, while the Windows host runs the Docker Client. All Linux containers share the Moby VM’s kernel.
LCOW
This method is similar but provides some advantages over the Moby VM because each container gets its own VM sandbox and kernel. The VM in this scenario is lighter-weight – running the minimal set of dependencies to run a container, also uses linuxkit. (https://github.com/linuxkit/lcow)
The Docker Daemon and container management stays on the Windows host (achieved with gRPC and containerd)
This method is currently in active development, however it promises some exciting functionality, such as increased security through complete kernel separation, and the most exciting feature imo – the ability to run Windows and Linux containers at the same time on the same host, allowing them communicate over the same network subsystem.
Run “Get-VM” in PowerShell to find out what you’re running.
(ref: https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers#other-options-we-considered)
Windows containers on Windows
There are two runtime options for Windows containers. The method by which images are built has no bearing on how they are chosen to be run.
Windows Server Containers
Provide isolation through process and namespace isolation. A Windows Server Container shares its kernel with the host. These containers do not provide a hostile security boundary and should not be used to isolate untrusted code. These containers require the same kernel version and configuration.
Hyper-V Isolation
Expands on the isolation provided by Windows Server Containers by running each container in an optimized virtual machine. In this configuration, the kernel of the container host is not shared with other containers on the same host. These containers are designed for hostile multi-tenant hosting with the same security assurances of a virtual machine. Since these containers do not share the kernel with the host or other containers on the host, they can run kernels with different versions and configurations (with in supported versions) – for example all Windows containers on Windows 10 use Hyper-V isolation to utilize the Windows Server kernel version and configuration.
(ref: https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/index#windows-container-types)
By default Windows Server Containers isolation will be used when running a container.
To use hyperv isolation:
docker run -it --isolation=hyperv microsoft/nanoserver cmd
.NET Applications on Linux
Finally, .NET Core is a .NET CLR runtime for Linux.
This means you can conceivably run a previously Windows only application on Linux – made even easier using the Microsoft supplied .NET Core Docker image:
docker pull microsoft/dotnet This is not really running a Windows container on Linux – but it’s running a Windows application on Linux inside a container.