Whereas when I install Docker in WSL it runs inside of my WSL VM.
You have piqued my curiosity. What does Docker Desktop do that the CLI cannot?
But again, they're talking about Windows, not Linux-in-Windows or virtualized Linux on Windows. Just because you can do something in WSL2 doesn't mean you "can do it on Windows", as much as you "can run systemd and Wayland on Windows" because you could run it inside a Linux VM...
WSL1 yes, but not WSL2, which the parent explicitly mentioned. WSL2 is just virtualization with a fancier name, might as well use VirtualBox and similar at that point.
The reason we launched Docker Desktop (initially known as "Docker for Mac") was to make the user experience better: easier to install, better integrated with the system (virtualization APIs, keychain, VPNs, etc), and better support for host volumes.
I do think it makes sense to add more GUI features over time, to make Docker more approachable - not everyone is a CLI wizard. But, it shouldn't make the app slower or annoying to use for those who don't need it.
- Install Ubuntu distro in WSL2.
- Create an ssh key pair on the Windows side using ssh-keygen.
In Ubuntu:
- Install Docker engine using Docker's apt-get instructions for Ubuntu.
- Add the ssh public key to ~/.ssh/authorized_keys.
In Windows:
- Run "wsl hostname -I" to get your WSL2 hostname.
- Test "ssh user@wsl-host", using the WSL2 hostname. It should work without prompting for a password.
- Unzip docker.exe somewhere.
- In your user environment variables, set PATH to include the directory with docker.exe, and set DOCKER_HOST to "ssh://user@wsl-host", using the WSL2 hostname.
That should be it; you should now be able to run docker normally from your Windows user, using file context from the Windows side.
Or are there any lightweight hypervisor on top of firecracker alternative? At this point with the way systemd is going, we should just switch back to VM? Everything is just more mature on native OS install. Docker to Linux, just feels kinda like SPA reinventing the html parsing on top of a rendering engine.
On Apple Silicon machines however, latest podman version uses VM images which Rosetta doesn't work with, and hence it will use qemu for running amd64 containers. You can fix this by either installing podman 5.5 or create the VM from and older image [1]. My only complaint here is that the stock machine images are pretty large (~1G )
If you use containers to run tools that create files in your host (i.e. build tools), then you can use your host username as the default in the VM (machine init --username $(id -un)), and then run containers with --userns=keep-id. That way the the container command starts with the same username and uid as you host user - this is pretty tricky to get working with docker, from my experience.
We use Bazel as our build tool and we create a lot of images based on shared layers. Bazel produces oci layout directories that contain descriptors and symlinks to the actual layer tars. Podman can start a container "directly" from these directories[2], which speeds up image testing considerably, since it can detect known layers immediately. With docker you have to stream a tarball with all the layers and descriptors to the docker daemon, only for it to discover that it already knows most of the layers.
[1] https://docs.podman.io/en/latest/markdown/podman-machine-ini... - machine images https://quay.io/repository/podman/machine-os
[2] podman run oci://<path to oci-layout-dir>
Zero problems with Podman Desktop.
Cool for Podman Desktop though.