At the end of 2021, a new version of Rancher Desktop came out that provides the Docker CLI and a dockerd socket as an alternative to nerdctl and containerd. In this post I’ll cover some details on why and how we did it.

Why Docker/Moby

nerdctl has been a great CLI for many things. You can build images and run containers with it. But, you can’t do everything you can with the Docker CLI. Not yet, anyway. I personally ran into issues when I needed to have a nerdctl equivalent to docker export which isn’t implemented, yet. The gap is continuously closing with each new release of nerdctl.

In addition to the CLI, many tools communicate directly with dockerd over a socket connection. I first noticed this with some Visual Studio Code extensions. No matter what level of parity the CLIs become it won’t solve the socket communications issue.

So, there was a gap and we were getting requests to close the gap. One way, and possibly the fastest way, to close the gap is to use the source tools.

How It Works

The first thing to know is that nothing is changing about nerdctl and containerd. If someone wants to use that they still can. It’s a first class citizen in Rancher Desktop with no plans to change. Everything being covered in net new functionality and not a replacement.

Two of the major pieces we needed were the Docker CLI and Docker engine. Both of these are open source projects under Apache 2 licenses. Docker engine is built on the Moby project which its website describes as:

Moby is an open framework created by Docker to assemble specialized container systems without reinventing the wheel. It provides a “lego set” of dozens of standard components and a framework for assembling them into custom platforms.

While Moby may be a framework, it’s also how Docker and varying Linux distributions are able provide Docker engine (e.g., see the docker.io Debian package)

Under the hood, Rancher Desktop is running Linux in order to run the containers. It’s using Linux distributions to do that. That made is fairly straight forward to include the open source Docker engine (i.e., dockerd).

The Docker CLI was a little more work. We, like so many others, appreciate the open source nature of it. But, the project on GitHub doesn’t provide binaries and building them needed to be cross platform and architecture. Linux distributions don’t have to deal with the different operating systems (i.e., Mac, Windows, and Linux). So, we had to build these.

Once we had the underlying tools we had to wire up the ability to select between containerd and dockerd as the runtime as well as expose the dockerd socket from the virtual machine to the host.

Hairy Decision

Not everything is straight forward. For example, what happens if you start a container running in containerd and then switch to dockerd? Should you still see the container running? Is that even practical or possible?

dockerd uses containerd under the hood. It’s possible to tell nerdctl where the socket for containerd, that dockerd is managing, is at. We don’t recommend this.

To keep things simple, the first release that has both dockerd and containerd supports keeping the environments separate. If you switch from one to the other you’ll end up with a separate setup. If you switch back and forth between environments you’ll see what was there before. You need to reset the container environment to remove what’s there.

dockerd and containerd

Both dockerd and containerd support are planned for the long haul. These are our current container runtime priorities though we now have a system to support more if a need arises for that.