Docker Desktop for WSL 2 integrates Windows 10 and Linux even closer
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.
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.
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.
When I drop out to PowerShell/CMD on Windows I can run "docker context ls."
C:\Users\Scott\Desktop> docker context ls
NAME DESCRIPTION DOCKER ENDPOINT
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!
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.
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.
About Newsletter
The dream would be to be able to run kubernetes master nodes in WSL2 on windows server 2019 without using Linux nodes.
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 https://github.com/jstedfast/MailKit and https://github.com/jstedfast/MimeKit instead")]
From:
https://docs.microsoft.com/en-us/dotnet/api/system.net.mail.smtpclient?view=netframework-4.8
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?
Shame.
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.
Scott,
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.
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?
Thanks!!
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.
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?