Support for podman inside of WSL2

[bmayfi3ld]

Due to the new licensing from Docker, Docker Desktop may not be a desired solution for many businesses.

Since podman is already able to run inside WSL2 and it is supported on Linux Machines. I wonder if it could be adapted to be used on Windows.

Easiest setup would to be able to handle the call to the podman executable inside of WSL2 from Windows, which is done with the command

wsl podman
wsl podman --version

So in the config you could update the path to be "wsl podman"

I of course don't know if there would be other issues with attaching and mounting to the container.

Similar to issue #5538 which references the new licensing as a problem for MacOS as well.

[bmayfi3ld]

Further looking into it, it looks like when the folder your trying to open is on the WSL2 filesystem the dev container is already routed through WSL2 directly and podman already works. So this is an easy existing solution for people.

But it seems when the folder is on the Windows filesystem remote containers always tries to use windows commands to launch and does not work. Maybe there would be a way to configure how the remote container is launched? That may have connotations on ssh agent forwarding and env vars though I suppose.

I just have some users that aren't as comfortable with running linux and I'm seeing if I can give them a solution that works as closely with Windows as I can.

[chrmarti]

I don't think Podman can mount a Windows folder (please check, I'm not sure), so your users will probably have to use the WSL filesystem.

[chrmarti]

Btw., I'm not sure if Docker CLI packages for Linux/WSL are affected by the Docker Desktop change.

[Trass3r]

But it seems when the folder is on the Windows filesystem remote containers always tries to use windows commands to launch and does not work.

Note that doing this is discouraged by MS anyway because the file system performance will be really bad.

[Trass3r]

I found it quite hard getting podman to work actually. You need to follow these:
https://code.visualstudio.com/docs/remote/containers#_can-i-use-podman-instead-of-docker (outdated though)
https://dev.to/bowmanjd/using-podman-on-windows-subsystem-for-linux-wsl-58ji

The big problem is that performance is really bad by default cause of fuse-overlayfs:
https://news.ycombinator.com/item?id=25169423
It's basically unusable without https://www.redhat.com/sysadmin/podman-rootless-overlay which only seemed to work for me after upgrading to pre-release Ubuntu 21.10 and thus podman 3.2.1 (kernel was 5.14 before already).

And the weird default user id mapping was another big problem:
containers/podman#2898
containers/podman#3196
Had to use this:

    "remoteUser": "vscode",
    "runArgs": [
        "--userns=keep-id"
    ],

And in the end it'll still use cgroups v1 it seems cause of microsoft/WSL#6662 (comment)

[bmayfi3ld]

I don't think Podman can mount a Windows folder (please check, I'm not sure), so your users will probably have to use the WSL filesystem.

I was able to mount it through the wsl c mount.
[bmayfield ~]$ podman run -it -v /mnt/c/Users/bmayfield/Downloads:/extratmp --entrypoint sh busybox

Btw., I'm not sure if Docker CLI packages for Linux/WSL are affected by the Docker Desktop change.

That is how I understand it. May be a better route to just install Docker CLI on windows. When I was researching that some sites suggested trying out podman instead.

Note that doing this is discouraged by MS anyway because the file system performance will be really bad.

Agreed, but I'm going for ease of use, not performance.

I found it quite hard getting podman to work actually. You need to follow these:

Those are good resources and the main ones I was looking at. So far is has performed well for the use cases I have.

[Chuxel]

Let's also separate this request a bit from Docker Desktop since Docker CE/EE (or Moby if you build it) can run in WSL as well w/o Docker Desktop (among other solutions that have been discussed in the containers community like nerdctl, just using a Minikube cluster plus the Docker CLI, etc). Organizations need to decide what they are comfortable with doing beyond what they do now. What #5538 is talking about the install prompt that appears and whether we should reconsider that, but as stated there, there is not a drop-in alternative for Docker Desktop itself which targets broad support and is more than just the Docker CLI and Engine.

That said, this is a 100% fair request - Podman was a great available alternative to the Docker/Moby CLI/Engine before and still is for those wanting to use containers on Linux (including WSL). I think Podman advocates wanted WSL support before, and still do after this announcement - which is great. But as you point out, the filesystem is effectively the one in WSL, not in Windows. The mounts are the way to access the Windows filesystem.

Unfortunately, installing the Docker CLI on Windows itself doesn't help since the thing that is missing is the clean filesystem translation that exists in Docker Desktop. The Podman project would need to provide some translation here to make this native or their own Docker Desktop-like solution, or first class WSL support to handle some of this (e.g. the systemd point).

Right now you can use the Remote - WSL extension, open a /mnt folder there, and then "Reopen in Container". This should work with either Podman to the extent its supported in WSL by the project or Docker installed in WSL (and the daemon is started using dockerd). It's just not seamless which is what Docker Desktop focuses on doing. That said, we'd generally recommend storing your source code in WSL instead using /mnt because of perf - even if you're not using containers there.

[PavelSosin-320]

Not hard! Podman uses FUSE to mount volumes, i.e. the abstraction level that allows mounting and see any type of filesystem as a single FS in the userspace. The recent Docker version does the same. It simply works.
podman run -it -v /mnt/c/users/pavel:/home/pavel localhost/ubuntuvolume ls /home/pavel/
Another issue is that instead of mounting workspace as volume to container Podman can mount Container to a workspace or do nothing and create a workspace as anonymous volume declared in the image using "image config".

[Trass3r]

Podman was a great available alternative to the Docker/Moby CLI/Engine before and still is for those wanting to use containers on Linux (including WSL).

I don't know, it was a PITA from beginning to end on WSL. Even after finally getting it to run (see above) the performance was really bad (even simple commands and auto-complete take a long time to run, esp. after startup) and it started making other problems like suddenly failing on container exit with ERRO[0000] Cannot get exit code: invalid character '\x00' looking for beginning of value or not being able to delete images anymore ERRO[0000] error joining network namespace for container ...: error retrieving network namespace...: unknown FS magic...: ef53.

Docker is a better alternative.
Only networking was a bit of a problem, requiring "iptables": false and --network=host.

[PavelSosin-320]

Stack Podman 3.3 + Fedora34 WSL distro + systemd-genie 1.40 (avoiding root privs usage) + buildah 1,2 ( for image configuration w/o rebuild) + certain set of systemd units to hands-free dev env starting (Theia) + Network configuration necessary for working in the double stack Internet infra with local forwarder + published Docker REST API (usable for self-update) works OK.
Podman stack based on the recent Fedora 34 WS works OK too.

[chrmarti]

@bmayfi3ld I'm adding 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.

[trallnag]

@Trass3r, setting up Podman on WSL becomes really easy if Systemd is setup 😉. Then sudo apt install podman is enough. I'm currently switching to systemd-genie as means of getting Systemd to work and I hope that over the longterm WSL will have Systemd out of the box. Or at least not break systemd-genie.

[rzhao271]

@chrmarti are there specific verification steps for this issue, or is it covered by the TPI?

[chrmarti]

The steps are slightly different:

• Set the Remote > Containers: Docker Path setting to the full path of where docker is installed in your default WSL distro (/usr/bin/docker?). (This ensures the command would fail on Windows.)
• Enable the new setting Remote > Containers: Execute in WSL.
• Open a folder on the Windows filesystem and run Remote-Containers: Reopen Folder in Container.
  • Pick a dev container config if the folder doesn't have one already.
• Verify the folder successfully opens in the container.

Reset the Remote > Containers: Docker Path setting when done.