WSL containers are now generally available
7 points by abareplace
7 points by abareplace
At first I thought this might be a stunning return to the WSL 1 architecture where Linux syscalls were translated into Windows syscalls at the container boundary, but reading the architecture blog post makes clear the containers are all running in the WSL 2-style heavily-paravirtualized Linux VM on Hyper-V, just with container control machinery located outside the VM in Windows itself instead of inside the VM like before.
Seems like a convenient alternative to the normal route of installing a linux distro in WSL, then installing docker engine.
The 'normal' flow on Windows is to use Docker Desktop, which does this for you. The same is true on macOS, where Docker Desktop uses Virtualization.framework to manage a Linux VM. This is now problematic because Docker Desktop has a license that requires paying per seat for companies above a certain size (including Microsoft, which actually pays the license). I suspect that developing this cost less than Microsoft's annual license fee to Docker.
It looks as if this uses the same one-VM-for-all-containers model as Docker Desktop. Apple's Container tool instead uses one VM per container, which is a better security model. I haven't looked in detail at how Docker Desktop works on macOS, but Podman's podman machine command defaults to mounting the user's home directory and a bunch of other things in the VM so that bind mount into individual containers. This means that a container escape in the Linux VM can give you complete read-write access to the entire home directory. In contrast, Apple's container tool attaches host filesystems on demand and isolates them to each VM, so a container escape in the VM can access only files exposed to the container (a VM escape can still damage a lot more things, but that's harder).