Docker in Wsl2 Alpine Without Docker Desktop

Docker in WSL2 Alpine without Docker Desktop

You could just run the Docker daemon as noted in the blog post you linked to:

sudo dockerd

Then switch to another WSL Alpine instance and run the Docker client commands.

But to use the OpenRC Docker service, you have two options.

First, you can start OpenRC and then start the Docker service manually:

openrc default
rc-service docker start # or service docker start

Or you can add the Docker service to the default runlevel (one-time), and then it will run whenever OpenRC is started in that runlevel:

One-time:

rc-update add docker default

Then, to start OpenRC with the default runlevel, which will also run Docker:

openrc default

Really, it seems the only thing you were missing is that OpenRC wasn't initialized first. Normally, that would be done during Alpine init, but WSL's own /init is running instead.

Docker under WSL without Docker Desktop

WSL1 - The little engine that could (link included since that reference may only be understood by a limited audience).

Unfortunately, in the case of Docker, the WSL1 engine seems to have run out of steam. In reading that blog post that you reference, and the corresponding Github thread, I'm pretty amazed at just how far along folks did get with running Docker. I had never seen that before.

However, if you read the full comments on the Github thread, it appears that the results were fairly limited. Placing these excerpts in order:

[2018-04-23] I'm glad to say Docker daemon finally runs on WSL. I'm testing on build 17134. ... The last docker-ce version that works right now on build 17134 is 17.09.0. Anything after that fails on extracting the docker images.

Note that it had to (and still has to) be run in a WSL1 instance running as a Windows admin.

[2018-0612] Unfortunately, docker-compose still doesn't work.... There is a problem with iptables which is not fully supported via WSL yet.

(Which you've run into, although I didn't see that. Perhaps the "admin" thing?)

[2018-07-09] Yeah, I recently mentioned it on Twitter and got a major "we aren't supporting this, we highly advise against it" message from our former WSL PM.

[2018-11-13] WSL PM here. As mentioned in the above comment, we have improved Docker support in recent builds of WSL. Most (if not all) versions of docker-ce work with WSL. We're working on a large set of changes for WSL currently. As part of those changes, we are looking at adding native Docker support in WSL. I will add to this thread and other issues on Docker support when I have additional updates to share

It doesn't seem like this ever progressed, since the PM never posted again in the thread, at least.

[2019-04-18] Like others have pointed out, running docker 17.09 works. Anything later fails with different errors. It might be that newer docker versions are using other syscalls not yet implemented by WSL.

There are some other messages scattered in here about running with --network host (for the client) or --iptables=false (for the daemon).

[2019-08-04] Windows Insider Fast Ring build (>=18917) via WSL2, latest docker/docker-compose is running native in WSL Linux.

And in late 2020, the thread died off.

In a test WSL1 Ubuntu 20.04 instance, I was able to get hello-world running, but nothing more. Running a busybox or ubuntu image (with or without an interactive terminal) failed with:

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: waiting for init preliminary setup: EOF: unknown.

Once the focused shifted to WSL2 and the real kernel, it doesn't appear to me that the WSL team has made any more progress advancing WSL1's pseudo-kernel syscall translation layer.

Missing WSL distros in Docker images

Docker images and WSL distributions are two completely different things from the usage standpoint.

In the context of over-simplifying to compare and explain the two:

WSL Distributions contain the tools that you use to interact with and develop applications using Linux. This includes your shell (bash by default in Ubuntu) and the docker client (provided by Docker Desktop).
Docker images are what you use as a starting point for your Docker containers.

The third screenshot you provided is Settings dialog that allows you to choose which WSL images should be integrated with Docker. Try the following:

Turn off Ubuntu in that setting
Apply and Restart Docker Desktop
Start your Ubuntu WSL distribution by running it from the Start Menu (or preferably Windows Terminal, if you have it installed).
Try running the docker command

You should find it isn't there.

Turn Ubuntu back on in Docker Desktop's settings
Apply and Restart Docker Desktop
You don't need to restart Ubuntu, but the docker command should now be there.

Docker desktop actually injects a link for the docker command:

From the docker-desktop distribution
Into the "user" distributions you select in that Settings option.

In general, it's fine just to leave it on for all distributions.

Now I know your next question:

So how do I run a Docker container based on Alpine or Ubuntu docker images?

You need to actually pull the Docker images onto your computer first:

Make sure you've enabled all WSL2 distributions again (not necessarily required, but you don't want to leave any off by mistake).
Start your Ubuntu distribution
Run:
```
docker run --rm -it alpine
```

Docker will detect that you don't have the Docker Alpine image installed, pull it, and run it. This is a bit of Docker shorthand for two steps, actually:

docker pull alpine
docker run --rm -it alpine

The -it options are for "interactive" and "terminal".

At this point, you'll be at the BusyBox shell prompt (Alpine's default) that is running inside your Ubuntu WSL distribution.

Before exiting, go back to Docker Desktop and examine the list of containers and images. You'll see:

An "alpine" image
A randomly-named container that is running based on the alpine image

If you start another terminal with Ubuntu open, you can run:

docker ps to show you the container information
docker images to show you the image information

This is essentially the same info that you see in Docker Desktop.

Go back to the first Ubuntu WSL2 terminal, which is running the Alpine container with the BusyBox prompt. Try running docker there -- It won't work, because this is a container based on the Docker Alpine image, not your WSL Alpine distribution.

Type exit or Ctrl+D to exit that prompt, and you'll now be back at the bash prompt for Ubuntu.

At this point, you'll notice that your Docker container is now gone, since we specified the --rm option that removes it when the process ends. If we hadn't done that, it would still show as a "Stopped" container in Docker.

You'll find that the Alpine Docker image, however, is still there. Once pulled onto your machine, Docker images stay until you remove them.

Docker images and containers can take a little bit to understand, and I can understand the added confusion in WSL distributions. Play around with them a bit, read some Docker tutorials, and the information above will start to make sense shortly.

Side note: Come back and read this after the above makes sense.

Docker containers and WSL2 distributions shared one big similarity in their architecture, at least -- they are both container technologies, just different.

WSL2 distributions are actually containers running in their own namespace inside the (hidden) WSL2 Hyper-V virtual machine. They share the same kernel and network, but each WSL2 distribution/instance has its own, separate, isolated PID and user namespaces.

This is, at the core, the same concept that Docker containers use. So with WSL2 and Docker, we are really running:

A WSL2 distribution "container" inside the WSL2 VM
A Docker container inside the WSL2 distribution container

Docker in Wsl2 Alpine Without Docker Desktop