[Preview] Run containers in WSL with VS Container Tools #417
Comments
|
Hi, I've tried this, and it's not working as expected; the container tools now start and warm up using the correct WSL volume paths. However, when I run the project, the container start command still uses the Windows paths -
Do you have any ideas about what is causing this? |
|
@jamesmcintyrenice sorry we forgot to mention that existing projects will need to update to Microsoft.VisualStudio.Azure.Containers.Tools.Targets@1.20.0-Preview.1 to take advantage of this support. |
|
@NCarlsonMSFT, Thanks for replying, updating that package has resolved it! |
|
I'm trying to follow along but get the following error in the Container Tools output window: The Shared Drives panel doesn't appear in Docker Desktop's settings as I'm using the WSL2 backend. I've checked the I've also tried rebooting, running VS as admin and have made sure to update |
|
@MDendura can you run docker inspect on your container to check the volume mount for '/remote_debugger' and ensure that it is using the correct WSL path? Can you also verify that the path works on the WSL side? |
|
@NCarlsonMSFT Sorry for the incredibly slow reply. I've managed to move beyond the above error, I think by ensuring my main VS installation is fully up-to-date and doing the same with Docker Desktop. The issue I'm now facing seems the same as #401, or at least is similar. With the preview of the Container Tools package installed and the Visual Studio pops up the following error:
I've done a bit of investigating and the volume mapped to I've also tried starting up the image directly from within my WSL terminal adding each of the mounts. If I set the container's entrypoint to My hunch at the moment is that something is wrong with the entrypoint supplied by Container Tools, or the labels applied. I can see from inspecting the failing container that these are as follows: "Entrypoint": [
"dotnet",
"--roll-forward",
"Major",
"/VSTools/DistrolessHelper/DistrolessHelper.dll",
"--wait"
],
"Labels": {
"com.docker.compose.config-hash": "a92407032221508b77f262cd52bb005d02845f08a6590f1c67a0a8c41e8e2b64",
"com.docker.compose.container-number": "1",
"com.docker.compose.depends_on": "",
"com.docker.compose.image": "sha256:adb6d32f34b11f484fdafc0949b5150e5701b180ac97a75226569ef27036f1e7",
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "dockercompose10580867562825455768",
"com.docker.compose.project.config_files": "C:\\Users\\mattdend\\source\\repos\\projectName\\docker-compose.yml,C:\\Users\\mattdend\\source\\repos\\projectName\\docker-compose.override.yml,C:\\Users\\mattdend\\source\\repos\\projectName\\obj\\Docker\\docker-compose.vs.debug.g.yml",
"com.docker.compose.project.working_dir": "C:\\Users\\mattdend\\source\\repos\\projectName",
"com.docker.compose.service": "project.Name",
"com.docker.compose.version": "2.24.6",
"com.microsoft.created-by": "visual-studio",
"com.microsoft.visual-studio.project-name": "project.Name",
"com.microsoft.visualstudio.debuggee.arguments": " --additionalProbingPath /.nuget/packages --additionalProbingPath /.nuget/fallbackpackages \"/app/bin/Debug/net8.0/projectName.dll\"",
"com.microsoft.visualstudio.debuggee.killprogram": "dotnet --roll-forward Major /VSTools/DistrolessHelper/DistrolessHelper.dll --stop dotnet",
"com.microsoft.visualstudio.debuggee.program": "dotnet",
"com.microsoft.visualstudio.debuggee.workingdirectory": "/app"
} |
|
@MDendura I've been trying to reproduce this but it's working for me on my machines. A few clarifying questions:
|
|
Is support of docker compose v2 also in plans? I have did next
2>docker-compose -f "P:\Test\WebApplication1\docker-compose.yml" -f "P:\Test\WebApplication1\docker-compose.override.yml" -p dockercompose15655799168555982834 --ansi never --profile "*" config Please note:
In docker compose chocolatey page said next To use Compose V2 through Docker type docker compose .... From July 2023 Docker Inc.'s support for Compose V1 and its Syntax (docker-compose ...) has ended (link). If run
as
everithing works as expected Maybe you have workaround for this issue? |
|
@mnikonov the only "work-around" I can suggest is using the download steps from https://docs.docker.com/compose/install/standalone/ |
|
@NCarlsonMSFT I've finally had some time to do some further digging and have found that the behaviour is different when running from the command-line depending on whether I start from a Windows PowerShell terminal or a WSL one. To test I copied the command from the VS Container Tools logs and modified it to get a bash prompt inside the running container for my .NET service: docker-compose -f "C:\Users\mattdend\source\repos\ProjectName\docker-compose.yml" -f "C:\Users\mattdend\source\repos\ProjectName\docker-compose.override.yml" -f "C:\Users\mattdend\source\repos\ProjectName\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose7905683544932631273 --ansi never run --entrypoint="bash" -it servicenameWhen I browse the container's filesystem, the However, if I start a WSL terminal and run the same command with the paths converted it seems to work properly: docker-compose -f "/mnt/c/Users/mattdend/source/repos/ProjectName/docker-compose.yml" -f "/mnt/c/Users/mattdend/source/repos/ProjectName/docker-compose.override.yml" -f "/mnt/c/Users/mattdend/source/repos/ProjectName/obj/Docker/docker-compose.vs.debug.g.yml" -p dockercompose7905683544932631273 --ansi never run --entrypoint="bash" -it servicenameBrowsing the container's filesystem from bash shows the It feels to me as though VS is doing something similar to the first example and that on my machine the bind mounts only work correctly when starting Docker Compose from inside the WSL environment. To answer your earlier questions:
|
|
Could you run: docker inspect -f "|source|dest|{{println}}|---|---|{{println}}{{range .Mounts}}|{{.Source}}|{{.Destination}}|{{println}}{{end}}" <containerId>to generate a markdown table of your mounts for when you start from windows and WSL to compare if the mounts differ? When you run from windows and the volume appears empty, could you run ps in your wsl instance to ensure the files are showing up in WSL? As an aside, if you're using the compose tools there is a work-around: services:
consoleapp30:
entrypoint: tail -f /dev/null |
|
Thanks @NCarlsonMSFT. MountsHere are the tables for both Windows and WSL starts Windows
WSL
The values are the same, just outputted in a different order. FilesWSL TerminalHere's the output from the path mounted to Container Bash, Started from Windows TerminalNow here's what should be the same location from Bash running in the container when started from Windows: Container Bash, Started from WSL TerminalAnd finally the same location from Bash when the container is started from WSL: As for the workaround, thank you, I'll read the docs you've linked to and see if I can put them to use. |
|
@MDendura I'm afraid outside the work-around above I'm running low on ideas. As this repros outside of VS, you may need to raise an issue directly with Docker (https://github.com/moby/moby for the engine or https://github.com/docker/cli if you think it's the CLI) The last Idea I have is to compare the result of docker inspect -f "{{json .Mounts}}" <containerId>To see if there is some difference in the meta-data |
|
Also trying this and struggling to get this working with our projects. I did resolve one of the issues after following the troubleshooting steps mentioned above I found that all of my mounted volumes were empty because my wsl instance was mounting my c drive to However, now the logs under %tmp%\Microsoft.VisualStudio.DockerCompose.Tools look clean, but the ContainerTools is still immediately killing the project after it starts. Is there a sample project that is recommended to sanity check how this should work so we can have the same frame of reference when troubleshooting or possibly another log location that would help me troubleshoot why visual studio is killing the process even though I can see all the mounts configured and populated in the container? I'm also using the latest version of the WSL Kernel, Docker Engine, Visual Studio, etc. I'm currently trying to get this working with https://github.com/NCarlsonMSFT/ComposeConfigurationExample I dropped a .env file in the root and added the following contents:
Build output window: Container tools window: Then I get the popup with the EDIT: I am on a corporate laptop with oodles of security things going on it, but I checked the firewall logs and I don't see anything that would interfere. Also, I regularly run docker compose from the commandline without issue and can remotely attach to running containers one at a time. I just miss the integrated capability and being able to use managed ids from inside the containers is what I'm looking for here,. |
|
@MAOliver Also, COMPOSE_CONVERT_WINDOWS_PATHS shouldn't be needed. It didn't seem to cause harm when I used it though. Things to check:
|
|
My mistake. I thought I had installed 17.10. Instead, I had updated to the latest version of 17.9.x. I updated to 17.10 today and everything worked seamlessly, even with my existing projects. This is huuge for us! Thank you so much. |
|
I've added the environment variable VSCT_WslDaemon=1 and upgraded to Visual Studio 17.10.0. But I'm still getting: |
|
@MDendura Were you able to resolve the issue? I seem to be having the same problem. |
|
@danielcrabtree Sadly not. I've had to put this to one side to continue with my project work, but I have been retesting periodically as new VS Preview versions become available. I did wonder if it could have something to do with the setup of the development machines (Server 2022 VMs with WSL) in my corporate environment as a colleague of mine had exactly the same behaviour. Hopefully at some point I'll be able to make time to test and make a small repro project on a personal PC that I can fully control, but I can't say when that will be. |
|
@MDendura That's basically where I'm at as well. It's happening to me on Windows 10. In my case, it only requires a brand new .NET 8 ASP.NET Core MVC project with container orchestration added to repro. |
|
I note that you don't even need to add container orchestration. Simply using the default project with a container is enough. I was able to test the same situation on Windows 11 and it worked fine without any issue in that case. So problem appears to be limited to Windows 10 for me. |
|
Just FYI for anyone running into this issue. I had an issue with one of the devs I work with that was getting the error about the /remote_debugger directory being empty. I had him look at his vsdbg directory and it was empty as well. It was actually caused by the firewall blocking powershell web connections. Soooo, if you're on a corporate VPN and you have policies in place that block remote connections from powershell, you're going to have to put in a request to get yourself unblocked. I discovered this on a hunch, but not from any error log that I could find (the container logs just indicated that the directory was empty, but not why). |
This functionality is now unblocked by an environment variable which will allow VS Container Tools to work with a connection to a remote docker daemon in WSL.
Important note: you will need to configure a container runtime daemon in WSL (e.g., Docker CE) and Docker CLI in your Windows environment. Setting the environment variable only ensures VS Container Tools will handle the mount points correctly.
Requirements
VSCT_WslDaemon=1Respond here with any questions or if you run into issues.
Happy coding ❤️
The text was updated successfully, but these errors were encountered: