Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Linux containers support #8

Closed
slonopotamus opened this issue Oct 3, 2021 · 11 comments
Closed

Add Linux containers support #8

slonopotamus opened this issue Oct 3, 2021 · 11 comments
Labels
enhancement New feature or request linux Issues related to Linux Containers

Comments

@slonopotamus
Copy link
Owner

No description provided.

@slonopotamus slonopotamus added the enhancement New feature or request label Oct 3, 2021
@slonopotamus
Copy link
Owner Author

@slonopotamus
Copy link
Owner Author

slonopotamus commented Oct 24, 2021

For the reference, here's how Docker Desktop works:

  1. Actual Docker demon is started as a service for Windows containers and/or inside WSL2 for Linux containers.
  2. docker CLI doesn't talk to them directly
  3. docker CLI always operates in default context that points at npipe:////./pipe/docker_engine
  4. There's a com.docker.proxy.exe process that actually listens on npipe:////./pipe/docker_engine
  5. Docker proxy routes all traffic to whatever backend is currently declared as "active"
  6. There are desktop-linux and desktop-windows contexts, also pointing to proxy.

Some logs.

This is how proxy is launched for Windows containers:

"C:\Program Files\Docker\Docker\resources\com.docker.proxy.exe" -windowsPipe=\\.\pipe\docker_engine_windows  -dockerExe "C:\Program Files\Docker\Docker\resources\bin\docker.exe"  -inject-hosts=true -native-api=true --windows-containers

This is how proxy is launched for Linux containers:

"C:\Program Files\Docker\Docker\resources\com.docker.proxy.exe" -windowsPipe=\\.\pipe\docker_engine_windows -wsl-distro docker-desktop  -dockerExe "C:\Program Files\Docker\Docker\resources\bin\docker.exe

Neither proxy nor backend is running:

>docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.3)
  compose: Docker Compose (Docker Inc., v2.0.0)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
ERROR: error during connect: This error may indicate that the docker daemon is not running.: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/info": open //./pipe/docker_engine: The system cannot find the file specified.
errors pretty printing info

Proxy is running but backend is not (Linux containers):

>docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Build with BuildKit (Docker Inc., v0.6.3)
  compose: Docker Compose (Docker Inc., v2.0.0)
  scan: Docker Scan (Docker Inc., v0.8.0)

Server:
ERROR: Error response from daemon: open \\.\pipe\docker_engine_linux: The system cannot find the file specified.
errors pretty printing info

Note that Linux dockerd is only listening "hosts":["unix:///var/run/docker.sock","unix:///run/guest-services/docker.sock"] inside WSL2. It isn't yet clear who is listening on \\.\pipe\docker_engine_linux and routing traffic into WSL2.

@slonopotamus
Copy link
Owner Author

@slonopotamus
Copy link
Owner Author

slonopotamus commented Jan 23, 2022

It isn't yet clear who is listening on \.\pipe\docker_engine_linux routing traffic into WSL2.

vpnkit-bridge.exe does this. See "C:\Users\<user>\AppData\Roaming\Docker\log\host\vpnkit-bridge.exe.log". It is paired with vpnkit-bridge running inside WSL.

@slonopotamus
Copy link
Owner Author

slonopotamus commented Jan 23, 2022

It might be possible to open docker.sock in AF_UNIX mode directly from Windows. See net.DialUnix and moby/moby#36442

Unfortunately, there's no way to pass custom transport to docker client: https://github.com/moby/moby/blob/v20.10.12/client/client.go#L120

See https://devblogs.microsoft.com/commandline/windowswsl-interop-with-af_unix/
It is very tempting to use AF_UNIX socket.

UPD: forget about AF_UNIX. It doesn't work in WSL2: microsoft/WSL#5961

@slonopotamus slonopotamus pinned this issue Jan 23, 2022
@slonopotamus
Copy link
Owner Author

slonopotamus commented Jan 23, 2022

I'm currently working on docker-wsl-proxy

It is supposed to become the missing puzzle piece that converts Windows <-> WSL2 paths and routes docker requests into WSL2.

When docker-wsl-proxy is ready, the work will continue in linux-containers branch of current repo.

@slonopotamus
Copy link
Owner Author

After several days of messing with docker-wsl-proxy, I start to think that using moby routes is a dead-end for several reasons:

  1. I cannot passthrough client API version
  2. I cannot provide a proper ContainerDecoder. Proxy runs on Windows, so doesn't have access to Linux implementation living in sysinfo_linux.go
  3. Moby routes are not very well adopted for third-party usage: Make fields of container.StateStatus public moby/moby#43180
  4. There are issues with systemrouter. Several route implementations simply do not expect that server could fail.
  5. Client.NewClientWithOpts is very restrictive and doesn't allow me to pass AF_UNIX transport. This could be implemented on Moby side (see Implement AF_UNIX sockets on Windows docker/go-connections#98), but that repo is nearly-dead, so god knows how many years it will take.

New plan: we go one level lower and instead implement a HTTP proxy. Currently, it looks like the only place that requires paths conversions is container creation. We could intercept that API call in the proxy and rewrite JSON.


I suddenly understood that paths is not the only thing we need to do. We also need to support container port bindings to Windows host ports. This possibly can wait though.

@slonopotamus
Copy link
Owner Author

HTTP proxy ended up being so much simpler: slonopotamus/docker-wsl-proxy@7c75d2d

Missing bits are:

  1. Make it talk to docker-inside-wsl
  2. Do bind path rewriting

@slonopotamus
Copy link
Owner Author

image

First proof-of-concept that works across WSL boundary (docker server is inside, docker client is outside).

@slonopotamus
Copy link
Owner Author

That's what was committed to main branch:

Desktop_220214_1355.mp4

@slonopotamus slonopotamus added the linux Issues related to Linux Containers label Feb 14, 2022
@slonopotamus
Copy link
Owner Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request linux Issues related to Linux Containers
Projects
None yet
Development

No branches or pull requests

1 participant