Scott Hanselman

Docker Desktop for WSL 2 integrates Windows 10 and Linux even closer

July 31, 2019 Comment on this post [13] Posted in Docker | Linux | Open Source
Sponsored By

Being able to seamlessly run Linux on Windows is making a bunch of common development tasks easier. When you're running WSL2 (Windows Subsystem for Linux 2) in a version of Windows 10 greater than build 18945, a BUNCH of useful and interesting scenarios light up and stuff just works.

Docker for Windows (download the Docker Desktop for WSL 2 Tech preview here) is great, but it has historically worked on Windows by creating a Hyper-V virtual machine called Moby that is visible within the Hyper-V client. It's a utility VM, but it's one you're aware of.

Docker for Windows using WSL2

However, if WSL2 runs a real Linux kernel in Windows 10 and it's managing a virtual machine platform underneath (and not visible to) Hyper-V client tools, then why not just let WSL2 handle containers for us?

That's exactly what the Docker Desklop WSL 2 Tech Preview aims to do. And just like WSL 2, it's fast.

...the time required to start a Docker daemon after a cold start is significantly faster. It takes less than 2 seconds to start the Docker daemon when compared to tens of seconds in the current version of Docker Desktop.

Once you've got a Linux (Ubuntu or the like) set up in WSL 2, you can right click on Docker Deskop and click "WSL 2 Tech Preview." This is a goofy and not-super-intuitive UI for now but it's a moment in time.

Click WSL 2 Tech Preview

Then you just hit Start.

NOTE: If you've already installed Docker within WSL 2 at the command line, stop it and let Docker Desktop manage its lifecycle.

Here's the beginnings of their UI.

Docker for WSL2

When I drop out to PowerShell/CMD on Windows I can run "docker context ls."

C:\Users\Scott\Desktop> docker context ls    
default Current DOCKER_HOST based configuration npipe:////./pipe/docker_engine
wsl * Docker daemon hosted in WSL 2 npipe:////./pipe/docker_wsl

You can see there's two contexts, and I've run "docker context use wsl" and that's now my default.

Here is docker images from Ubuntu, and again from Windows (in PowerShell Core). They are the same!

Docker images in Ubuntu
Docker images from Powershell

Sweet. Here I am using PowerShell Core (which is open source and cross-platform, natch) to manage my builds which are themselves cross-platform and I can run both a docker build or a metal build on both Windows or Linux, all seamlessly on the same box.

building docker images

Also note, Simon from Docker points out "We are using a non default dataroot in this mode to avoid corrupting a datastore you use without docker desktop in case something goes wrong. Stopping the docker desktop wsl daemon and restarting the one you installed manually should bring everything back." I noticed this because my "Windows Docker" and my original WSL2 docker had a list of images that I naively expected to be available here, but this is a new context and new dataroot so you may need to fetch images again in this new world if you're have been historically an active docker user.

So far I'm super impressed. Linux on the Windows Desktop feels right. It's Peanut Butter and Chocolate.

Sponsor: Looking for a tool for performance profiling, unit test coverage, and continuous testing that works cross-platform on Windows, macOS, and Linux? Check out the latest JetBrains Rider!

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.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
August 01, 2019 10:33
Since WSL2 does not work under HyperV, does it mean that perhaps we eventually can get Windows /Linux mode images at the same time? Can the Docker engine figure out that?

This would eventually enable scenarios such as CosmosDB image (windows-core) running at the same time as the Linux Redis, .net Core, ELK images?

Or am I completely off?
August 01, 2019 11:44
If, when, how will it run on windows server 2019?
The dream would be to be able to run kubernetes master nodes in WSL2 on windows server 2019 without using Linux nodes.
August 01, 2019 13:56
That's all cool, but I still can't get it to startup local Kubernetes - it seems to fail at downloading the k8s images
August 01, 2019 16:01
This is pretty cool! Still playing around but, after switching to wsl context, it seems docker-compose still uses the default context to build/run images (docker run works as expected).
August 02, 2019 5:24
Great stuff. I also like the subtle usage of Windows Terminal to host pwsh and WSL bash side-by-side. You must have built it from source since the new tab bar isn't in stable yet, so that's doubly impressive.
August 02, 2019 18:52
This is gold, thank you so much for this 🙂
August 02, 2019 21:53
It is hard for me now, to imagine world without Docker. But this technology was introduced so recently!
August 02, 2019 23:59

Shame on Microsoft ending support for sending email from within a .net application using SmtpClient. I use this in several systems and it's quietly being retired by Microsoft.

Recommending my financial trading application use a third party open source library which is less than Microsoft supported and a much larger business maintenance risk is an undesirable action.

This small change removing a few API calls will cost my team thousands of dollars in development time, QA time, and down the road maintenance time (One developer day total cost is near $1,000 total cost).

SmtpClient has this message about being obsolete.

[System.Obsolete("SmtpClient and its network of types are poorly designed, we strongly recommend you use and instead")]


Shame on Microsoft of shifting yet another cost from the vendor, Microsoft, to the customer (developer).

What other APIs are silently going to be removed from .net or just not show up in .net core?

The SQL Server team could not get away with this. Why does the .net dev team think it is an acceptable practice?

August 06, 2019 0:54
Robert -

I apologize for this. There’s some confusion as we have a documentation error that’s merging that attribute from two places.

* It’s in the .net standard and it’s not going anywhere
* it’s ok to use in .NET framework 4.x
* it’s not recommended (but is useable) in .NET core.

The intention was to mark it as Obsolete for cross-platform work because it does have historical issues. If you’re using it on 4.x and on Windows you can continue using it and being supported for many years.

We are going to fix the documentation to make this distinction clearer.
August 06, 2019 1:25
> * it’s not recommended (but is useable) in .NET core.


That's as good as unsupported since the go forward .NET platform is .NET core.

We develop financial systems and code outside of .NET core has to be vetted and approved by IT steering before being used (cybersecurity, business risk).

My company is implementing large new systems in .NET core and our existing systems will be rewritten within the next few years in .NET core. We've had lots of wasted time trying to mix .NET core with standard or .NET framework and do not combine them in current development.

All I am asking is can we have a Microsoft supported Smtp way to send email from within a .NET application and also one for a .NET core application?

Not having it in .NET core will cost my team tens of thousands of dollars, add project risk and a longer term maintenance risk. We were expecting to re-use plumbing code from an existing .NET framework application for sending email on .NET core.

We will not get a project to go back to .NET framework for our large system in development. Reverting to .NET framework would cost weeks for code, build, third party code quality tools, server configuration, etc. at the cost of about $1000 per developer day.

Event a dumbed down Microsoft supported .NET core way of send emails, with attachments, BCC, CC and multiple recipients would work for us.

Lastly, our CIO directed us to use 100% .NET core on this and future projects. The CIO want to have the business risk and large legacy cost of maintaining the entire ecosystem, build tool-chain and environments for mixing .NET core and .NET standard.

What other common .NET APIs are not implemented, depreciated or broken in .NET core?

Our team wants to use .NET core and not fight the inherit problems mixing .NET core with other .NET frameworks.
August 09, 2019 13:30

Nice Really useful information provided keep providing
August 14, 2019 22:02
Very cool. Up to now I've stayed away from Docker (Elastic Beanstalk and ASP.NET Core in Lambda did the trick) but I have a project now where Docker will be used to run ASP.NET Core powered microservices.

I found debugging a Dockerized ASP.NET Core app in Visual Studio 2019 to be a breeze. It just works. The cost of Visual Studio is more than justified by not having to fight with tools.

Visual Studio Code -- pain to get it to debug the same app.

Is there a plan to make WSL 2 jive with Docker and Visual Studio?


August 15, 2019 1:38
.NET Core does not support WCF server code. .NET Core supports only WCF C# client code.

Even a simple way to write WCF server code with a decent security model would help.

What's the go forward path to use .NET Core for our large WCF server code base? One system has hundreds of WCF server side methods used by clients and hundreds of thousands of lines of c#. We have multiple other large WCF server systems.

How to budget for the tens of man-years needed to rewrite, QA, beta test, and cybersecurity test?

Headline: Microsoft Abandons Core Server Technology

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.