Honor the Docker context when running in WSL 2

[fiveisprime]

I believe this is related to how dockerode works; however, I'm pretty sure the host/socket can be overridden when instantiating a new Docker instance so it may not actually be a bug with dockerode.

On Windows 10 (18950) running WSL 2 with the Docker Desktop WSL 2 Technical Preview. The TP separates the Windows and WSL contexts to prevent destructive operations and Dockerode only accesses the Windows context. For example, on Windows, with WSL 2 enabled I see this (notice that wsl is active)

Running $ docker ps and $ docker images shows the containers and images running in WSL no matter when shell I access Docker from. With the extension in UI mode, I get the containers running within the default Windows context.

This may appear to be working as expected since UI shows Windows and Workspace shows WSL, but it's a damn confusing experience for existing extension users who enable WSL 2 and install the technical preview expecting to see containers running in WSL (the same as they see from PowerShell). If the context were honored the same way, the workspace/ui separation wouldn't be an issue for Windows WSL 2 users.

[ksawerykarwacki]

Furthermore to run docker-compose from windows on wsl2 you have to set DOCKER_HOST to the endpoint within wsl2 which brakes everything as extension says that DOCKER_HOST is not valid.

[Will-Blackburn]

I've been fighting with this for the last few days, Bash and Windows working with WSL2 but the UI for VSCode is running on Windows for Docker and I've not found a way to make it work with WSL

[bwateratmsft]

Related upstream dockerode issue: apocas/dockerode#526

[mcauto]

I use Docker explorer in WSL2

but, Do not use with vscode-docker. Affect each other.