Docker and Linux Containers on Windows, with or without Hyper-V Virtual Machines
Containers are lovely, in case you haven't heard. They are a nice and clean way to get a reliable and guaranteed deployment, no matter the host system.
If I want to run my my ASP.NET Core application, I can just type "docker run -p 5000:80 shanselman/demos" at the command line, and it'll start up! I don't have any concerns that it won't run. It'll run, and run well.
Some containers naysayers say , sure, we could do the same thing with Virtual Machines, but even today, a VHD (virtual hard drive) is rather an unruly thing and includes a ton of overhead that a container doesn't have. Containers are happening and you should be looking hard at them for your deployments.
Historically on Windows, however, Linux Containers run inside a Hyper-V virtual machine. This can be a good thing or a bad thing, depending on what your goals are. Running Containers inside a VM gives you significant isolation with some overhead. This is nice for Servers but less so for my laptop. Docker for Windows hides the VM for the most part, but it's there. Your Container runs inside a Linux VM that runs within Hyper-V on Windows proper.
With the latest version of Windows 10 (or 10 Server) and the beta of Docker for Windows, there's native Linux Container support on Windows. That means there's no Virtual Machine or Hyper-V involved (unless you want), so Linux Containers run on Windows itself using Windows 10's built in container support.
For now you have to switch "modes" between Hyper V and native Containers, and you can't (yet) run Linux and Windows Containers side by side. The word on the street is that this is just a point in time thing, and that Docker will at some point support running Linux and Windows Containers in parallel. That's pretty sweet because it opens up all kinds of cool hybrid scenarios. I could run a Windows Server container with an .NET Framework ASP.NET app that talks to a Linux Container running Redis or Postgres. I could then put them all up into Kubernetes in Azure, for example.
Once I've turned Linux Containers on Windows on within Docker, everything just works and has one less moving part.
I can easily and quickly run busybox or real Ubuntu (although Windows 10 already supports Ubuntu natively with WSL):
More useful even is to run the Azure Command Line with no install! Just "docker run -it microsoft/azure-cli" and it's running in a Linux Container.
I can even run nyancat! (Thanks Thomas!)
docker run -it supertest2014/nyan
Speculating - I look forward to the day I can run "minikube start --vm-driver="windows" (or something) and easily set up a Kubernetes development system locally using Windows native Linux Container support rather than using Hyper-V Virtual Machines, if I choose to.
Sponsor: Why miss out on version controlling your database? It’s easier than you think because SQL Source Control connects your database to the same version control tools you use for applications. Find out how.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Dave
Also, by definition, a container is an isolated group of processes, running on top of the host kernel. So when you say "native Linux Container support on Windows", are these processes running on the Windows kernel, perhaps using the WSL subsystem layer?
I was under the impression that Linux Containers on Windows are run on a very thin Linux Kernel hosted in a Hyper-V VM.
Is this possible?
Serious point, I could switch to HyperV for everything if Microsoft would update the HyperV Linux video driver so that it supports resolutions higher than 1080p. I sometimes need a Linux desktop and both VMWare and VirtualBox handle screen resizing transparently. With HyperV (unless it's changed in the last 12 months) I need to edit a config file and then only gain support for relatively low resolutions. I think both those two also support screen scaling, i.e. have 1080p resolution scaled up to fit a 4k monitor so that teeny tiny icons are a bit bigger. That would also be an acceptable compromise and actually more useful in some cases.
Great blog as usual :)
(Up-to some performance and scalability issues which are on my TODO list anyway.)
I have honestly not collected enough reasons to start working in docker yet.
But do you see my wording? "...yet".
Is something wrong with me? I feel like docker might be response to some of my deep concernes, and I feel like it is a future for me and our team, but I am not able to advocate the added complexity for me now.
And I blame myself for "not getting that". Thanks to you "dark matter guys" I feel less guilty.
So far we all just compile locally, use localdb, connect to some developer instances of queues/tables in azure and we hope all works the same in production and it most of the time does.
Nevertheless, I am eagerly (async) awaiting Scott's blog posts to see how far from the "ready-for-lazy-Richard" status is the technology around VS2017 and .NET.
And I am patiently waiting. Dear "Microsoft with all the great Scotts", please keep up the great and hard work. You have my trust even though I plan to stay behind a bit.
This is very unfortunate, MS should simply switch the hypervisor on Hyper-V to the same type VirtualBox uses and let them co-exist. I really don't care for this type of optimization on a dev box, I just need them to run.
Until MS removes this limitation, docker for windows is a no-go.
It's much easier to use webjobs and webapps, they can be scaled, and because you can have multiple web sites per app service they can contain highly focused "services".
@Scott - I'd like a "why should you bother" with containers post as I really feel I'm missing something here
Personally, I am a long time user of VMware Workstation and so have no want or need for Hyper-V.
I guess I will have to see if I can get it to work in a VM instead.
I too would also be interested in a "why should you bother" post about containers.
Mike
When I try to run a container from a linux-based image, it's complaining that, "container <guid> encountered an error during CreateContainer: failure in a Windows system call: No hypervisor is present on this system."
I also discovered this:
Install Docker EE - Windows Server 1709https://docs.docker.com/engine/installation/windows/docker-ee/
Docker Universal Control Plane is not currently supported on Windows Server 1709 due to image incompatibility issues. To use UCP, for now please use the current LTSB Windows release and not 1709.
And I've been using EE preview. So, I wonder if this is still yet possible with Server 1709?
"docker-machine create --driver hyperv --hyperv-virtual-switch lan default"
Use Hyper-V Manager to create a switch that can reach the Internet - otherwise it defaults to "nat".
I love it when I see Windows and Linux are coming together.
You can run a Cluster of Linux containers on a Windows machine!
Can't wait for more support in Kubernetes, so we can have Windows machines as Kubernetes Control Planes.
Comments are closed.