# Docker Desktop alternatives

## Overview

There are several aspects to what Docker is and what it is used for on Windows and MacOS. One big aspect is that there is a Virtual Machine (basically linux) on both platforms inside which the containers run. There is a UI that users can use to manage the lifecycle of this virtual machine. There is a socket that is made available outside of the VM that offers a REST API. The docker CLI makes use of this socket as well to start/stop/manage containers using the REST API.

## What do we really need

- Needless to say, we would want to run existing container images
- we should be able to build new images from existing source files
- for our purposes, we should be able to build k8s (really complex build system)
- support for developer oriented tools like tilt and skaffold would be good
- Ability to run k8s using kind is definitely required

## Alternatives

- [podman](https://github.com/containers/podman)
- [Nerdctl](https://github.com/containerd/nerdctl)
- [Lima](https://github.com/lima-vm/lima)
- [Rancher Desktop](https://github.com/rancher-sandbox/rancher-desktop)
- [colima](https://github.com/abiosoft/colima)
- [Docker Engine](https://github.com/docker/engine)
- [minikube](https://github.com/kubernetes/minikube)

## How do these alternatives work

podman effort from Redhat is closest to providing the same exact experience as docker, well except for a UI. podman provides a CLI, API etc that mimic exactly what docker provides. podman documents their compatability guarantee [Podman REST API and Docker compatibility](https://podman.io/blogs/2020/07/01/rest-versioning.html). podman can be run under WSL2 in Windows and has the capability to start a virtual machine on MacOS (see [Migrating from Docker to Podman](https://marcusnoble.co.uk/2021-09-01-migrating-from-docker-to-podman/)). Also podman uses crio as container runtime.

nerdctl from CNCF's containerd project does provide a CLI that mimics docker CLI, but does not provide a REST API similar to that of docker. this CLI talks directly to containerd's REST API instead. One example of how nerdctl can be used with WSL2 is [here](https://medium.com/geekculture/move-away-from-docker-now-and-utilize-wsl2-systemd-genie-containerd-with-nerdctl-d5f729dcf227)

Lima builds on top of nerdctl and containerd and wraps it around a VM for running on MacOS. No docker REST API as it uses nerdctl

Rancher Desktop uses nerdctl and containerd as well on both Windows (WSL2) and MacOS (using Lima). By design it is only meant for kubernetes use cases and does not support the docker REST API (since nerdctl does not provide one). So Rancher Desktop embeds a Kubernetes engine and the whole effort is about making k8s available on desktops and not as a general purpose docker replacement.

colima adds a MacOS UI around Lima. No Windows.

Minikube is a way to run k8s on both MacOS and Windows with a [variety of drivers](https://minikube.sigs.k8s.io/docs/drivers/) including KVM, Parallels, docker, podman etc. With this driver pattern it is way better than other options for running k8s like kind or microk8s (see [here](https://matt-rickard.com/docker-desktop-alternatives/)).

Last but not the least the docker engine for linux (used by docker desktop) is still opensource and can be [used with WSL2 on Windows](https://jason-umiker.medium.com/replacing-docker-desktop-with-wsl2-and-or-rancher-desktop-on-windows-5e036f9dc3a4) or using a VM on MacOS.

On MacOS, one last permutation is that Lima can be used with docker-ce as well.

## What is so hard about running things in a VM

Docker Engine (on linux) makes it so simple to mount directories, expose ports and so many other things that a developer depends on to iterate on building their container images and for production using some container orcehestrator as well. These things are really hard to do on Windows, WSL helps but is not quite there yet in terms of linux compatibility. MacOS with its FreeBSD roots is in the same boat for example with respect to cgroups and hence needs VMs. So same problem as with windows about making things easily exposed from host to vm and vice versa.

## What do we avoid

- Avoid getting into how best to support Docker REST API. especially without docker engine (podman). There's just too many things (bugs/features) that we don't need as a business that we would end up getting sucked into.
- Avoid things that have k8s built-in like Rancher Desktop, we want to pick our versions of things to run (kind/containerd etc)
- Avoid cri-o based solutions (like podman)

## Recommendations - So where do we spend our time and effort

- Help adopt a driver based pattern either at Tanzu/TCE CLI level or in Kind itself that Tanzu/TCE CLI depends on. This is similar to the pattern used by minikube and will help with integration with proprietary systems like Fusion as well (that runs both on windows and MacOS, has a freemium version too).
- Pitch into the containerd/nerdctl eco system and position that as the best way for say TCE to be used in the community. So we would pick WSL2 on windows and Lima on MacOS for people to try TCE (using the driver based pattern above for sure).

## Longer term

vctl in fusion has some ability to deploy kind based clusters [[1]](https://rguske.github.io/post/vmware-vctl-kind-writing-configuration-failed/)[[2]](https://docs.vmware.com/en/VMware-Fusion/12/com.vmware.fusion.using.doc/GUID-1CA929BB-93A9-4F1C-A3A8-7A3A171FAC35.html)[[3]](https://github.com/VMwareFusion/vctl-docs/blob/master/docs/kind.md). The current situation with docker desktop is a good time to consider other futures for fusion.
- How much of vctl could we open source?
- Could we have a free-as-in-beer version to target use cases listed above?