Docker Desktop Has Been Hiding Things From You

Now that Docker has decided to begin charging a license fee for the use of Docker Desktop in large companies and/or commercial use, many people are scrambling to find open source alternatives.

This article isn’t about the available alternatives or my opinions on them (although I’ll do that as well). It's about clearing up some docker misconceptions that I’ve run into lately.

The qualifier “many people” refers to those who use Docker Desktop regularly. Anyone that falls into that category will also fall into one of two other categories; Windows users or Mac users. This is because Linux doesn’t have a Docker Desktop application. This fact brings us to what Docker Desktop has been hiding from you. Docker requires a Linux kernel to run. That means that to run a docker container in Windows or macOS you need a VM running a Linux kernel, which in turn runs docker.

The primary reason Docker Desktop (referred to from here on as DD) was created was to make your life easy by removing the need for you to care about managing a VM. If the default VM configuration is good enough for your needs it’s entirely possible that you may not even know that you’ve been running a VM this entire time. Given the original release date was about 8 years ago, it predates many developers' careers and they’ve never known life without it.

Now that people are reaching for alternatives the above situation has led to some confusion and a lot of taking reevaluation of how docker works. I am not going into detail on WSL+Windows and if you know enough to have opinions on that, you probably don’t need this article. So let's get the basics cleared up.

1. Docker requires a Linux kernel to run, version 3.1 or higher, specifically
2. Windows and macOS require a VM running Linux to run docker
3. DD manages the VM and the mapping of host machine resources to the container for you so that the VM to docker mapping is invisible to the user.

It’s a lack of awareness of this VM intermediary that has caused the most confusion that I’ve seen. After uninstalling DD then becomes a rabbit hole of finding an alternative. Once we’ve decided on one, we go down the rabbit hole of installing said alternative as well as a VM to run the alternative in. And while it may come as a surprise that you need to install a VM, at least with Windows this is made fairly clear in the installation instructions that I’ve seen. With macOS, most people are going to turn to a tool called homebrew to install their chosen alternative. Homebrew installs typically install all of their dependencies as well, so you still may not realize that it installed a VM when you installed colima, for example.

Once you’ve got everything installed and set up you are now going to have to set up the VM as appropriate for your particular needs. This also includes understanding that if I need to mount a volume in a docker container to the host filesystem, I will first need to configure file sharing between the host machine and the VM, and then configure sharing between the VM and the docker container.

My rambling point is simply this; be aware that DD is no longer hiding how docker works from you and understand that you’ll need to take a few extra steps to use docker without DD. Because of all of this, my advice is to continue to use DD unless there is a compelling reason not to (or you just want to play with things under the hood), but if you feel a need to ditch DD then be aware of the extra effort you’ll need to put in.

I use colima on my MacBook because it provides me the closest to a drop-in replacement for the magic that DD performs. I can quickly and easily change my VM configuration directly from the CLI when needed, while not forcing me to install kubernetes if I don’t need it (I’m looking at you minikube), it provides decent performance, and makes dealing with port mapping and volume mounting easy.