There are a number of issues making this quite complicated. For starters there is the basic communication between client and daemon:
- by default the Linux docker client communicates with the daemon over unix domain sockets. I haven’t checked yet if they are supported on WSL and if they are accessible outside the WSL environment. You could use DOCKER_HOST and communication over the network. This may work in simple cases but is likely to break in more complex scenarios. Docker for Windows currently only supports the localhost:2375 communication to support compose, but this may go away because:
- by default the Windows docker client talks to the daemon via a named pipe. This is what the docker cli talks to on Windows. Named pipes are windows special and are not avail in WSL, AFAIK.
- In order to make the client integration seemless we proxy docker client connections to the daemon and rewrite some small portions of the requests/responses on the fly. Since the Linux client on WSL would use a different mechanism that would be trickier to do.
This is just the basics and are probably doable at some point, but it becomes a lot trickier if you want to do volume mounts and the like. The WSL filesystem seems to be a transparent union mount with some of the user data living in AppData and other parts of the WSL root filesystem elsewhere. It’s unclear how one would untangle this and present in a comprehensible way to the user to use the -v option. There are also differences in filesystem semantics between the filesystem used by WSL and NTFS (symlinks etc) which will be very confusing to users if they see a symlink in WSL but no symlink in a volume shared with a container.
These are just some issues, and there are likely more, but I agree it would be cool to have docker for Windows work with WSL, but it might just not be possible (or very very hard)