Attach to Podman container in WSL

[chrmarti]

I tried installing podman in my WSL2 Ubuntu image. I have podman running my dev container (my-dev-container) in WSL2 also. I have made the change you stated so that 'podman' is my docker path.

From WSL2 command prompt I run 'code .' and VSCode (Windows) comes up. I select 'Remote-Containers: Attach to running container' and it shows the podman container (my-dev-container). I select it.

It starts another VSCode window and pops up the error 'Cannot attach to the container with the id/name my-dev-container, it no longer exists along with the options 'Chose Container', 'More Actions' and 'Close Remote'. I select the 'Chose Container' and it pops up an error 'Docker version 17.12.0 or later required'. Repeat the process and select 'More Actions' and see 'Chose container' and it gives the same error. I believe the error is because there is no 'podman.exe' even though I am running in a WSL2 window.

How can it connect to the running container and develop code in it?

Originally posted by @DougHaigh in #5504 (comment)

[Clockwork-Muse]

With regards to the specific licensing issue, the docker cli itself appears to be under an apache license, and available in a separate repository. Which means, I think, you can install just the CLI on windows, and then be able to connect to WSL as a "normal" remote machine (note that installing docker on WSL has issues due to the fact that systemd isn't usually started).

[Clockwork-Muse]

... As an additional note, podman itself also has a remote client. The catch is that in order to be able to use it, you're required to enable a systemd service on the linux host. Which would negate a couple of advantages of using podman in the first place, if you tried to connect that way.

[DougHaigh]

I tried starting the podman server service in WSL2 and installing the podman remote client in Windows. I could run commands from a command line to have the server in WSL2 respond (after some special setup). This means the command 'podman' in WSL2 and 'podman' from a Windows command prompt would show the same thing. VSCode started in Windows still could not see the containers running in WSL2. VSCode started in WSL2 sometimes would by if I tried to use the container, it would fail to some up.

VSCode uses some docker commands that do not exist in podman (like docker context) which may prevent it from working.

[Chuxel]

With regards to the specific licensing issue, the docker cli itself appears to be under an apache license.

@Clockwork-Muse Yeah, this was a copy-paste from the original issue as to what drove interest in the topic. Removed that from the body since it's not directly related as you point out. We should consider that bit "off topic." These issues are not a great place to discuss specifics of licensing in general since the committers here do not work for Docker. Places like this topic in Docker's forums are better.

In general though, totally fair request otherwise.

[Clockwork-Muse]

@Chuxel - It was meant as a "here's a possible workaround, if you need it", rather than a discussion about the licensing in general.

[PavelSosin-320]

Hopefully, the "official" WSL distro with the corresponding Podman version inside will be released very, very, very soon.

[chrmarti]

Got it running by following https://www.redhat.com/sysadmin/podman-windows-wsl2 to install Podman on Ubuntu in WSL2 (libpod.conf has been renamed to containers.conf since that article was posted). Currently one has to make sure to have a folder open while being connected with Remote-WSL, otherwise Remote-Containers cannot lookup the WSL distro (tracked as #4913).

[chrmarti]

Fixed a case where using a \\wsl$\<machine> path wasn't fully covered (#5504).

[Clockwork-Muse]

@chrmarti - Also, podman doesn't create the config file by default when podman info is run for rootless installs.

My own case is weirder because I want to move the image location off the os drive for space reasons.

[chrmarti]

Added a user setting to always run commands in WSL, also for Windows paths and when there is no local path when attaching to an existing container (#5539).

[chrmarti]

Also fixing #4913 which affected empty SSH and empty WSL windows.

[chrmarti]

Running with a non-root user inside the container still requires updating the HOME env variable (which is set to /root by default by Podman) and disabling id mapping (since the non-root container user should correspond to the non-root host user). So I have to add the following (for user node) to the devcontainer.json:

"containerEnv": {
	"HOME": "/home/node"
},
"runArgs": [
	"--userns=keep-id"
]

[chrmarti]

Published the mentioned fixes (#4913, #5504, #5539) with Remote-Containers 0.195.0. This currently requires VS Code Insiders.

[chrmarti]

The original issue no longer reproduces in the upcoming 0.196.0 (and maybe before that). Additional fixes are mentioned above. Closing as done.