Wednesday, 13 January 2016

What is the difference between a Windows Native Container and a Hyper-V Container?

Docker on Windows

Microsoft do seem to have a (confusing?) variety of container offerings, all still in preview. I've been asked about this several times, so here's my understanding.

We really have 2 ways to run containers on Windows
  • Native
  • Hyper-V
Native Containers

Native containers run straight on the host using the Windows Docker Container Engine (basically Docker compiled for Windows, with a shim that starts and stops and otherwise controls local containers using the WinAPIs). 

You build native container images using DockerFiles and control the resulting containers using the Docker APIs, which is nice. I've played with these on Azure and they basically work as described.

Hyper-V Containers

I understand these are really just a native container (see above) running inside a Hyper-V lightweight VM on your host. Unlike normal VMs though, you should be able to build these "Hyper-V containers" using DockerFiles and use the Docker APIs to control them just like a native container, which is again nice. I haven't been able to try this as they are not yet supported on Azure but I have no reason to believe anyone's lying ;-)


The Why is quite interesting. MS are pitching native containers for environments where all the containers are trusted and Hyper-V containers for mixed setups where you don't know and trust all your containerized neighbours. I.E. the VM-like wrapper provides better security.

This sounds a little like the setup at Google Container Engine where I believe they run containers inside VMs inside containers (for ease of deployment, security and resource mgmt respectively). It looks like MS are targeting ease of deployment and security with Hyper-V Containers.

So if you were running Hyper V containers on Azure you'd have containers on VMs on VMs so not miles from the Google Container Engine architecture ;-) This tech is definitely made for layering.

If you want to know more there's an excellent overview by Mark Russinovich, which appears to match what I've seen ;-)

No comments:

Post a Comment