Docker images, by design, are self-contained packages that include everything needed to run the application they are designed to execute. One of the great strengths of Docker is that Docker images can be run on almost any operating system. That being said, there are some differences in the experience of running Docker images on different OSes. Docker was created on Linux and is deeply integrated with some key Linux constructs. So, as you would expect, when you run Docker on Linux, everything integrates directly and seamlessly with the OS. Docker leverages the Linux kernel and filesystem natively.
Unfortunately, when you run Docker for Windows or Docker for Mac, Docker cannot leverage the same constructs that it does natively on Linux because they just do not exist on these other OSes. Docker handles this by creating a small, efficient Linux VM in a hypervisor for the non-Linux OS. With Docker for Windows, this Linux VM is created in Hyper-V. On macOS, the VM is created in a custom hypervisor, called hyperkit.
As you might expect, there is a performance overhead associated with the helper VMs. However, if you do use Windows or OS X for your development workstation, you will be pleased to know that Docker has made a lot of positive strides on both platforms, reducing the overhead and improving performance significantly with each new major version released. There are a lot of reports of high CPU utilization for the hyperkit hypervisor on OS X, but I have not personally experienced the issue. With the current stable versions of Docker CE, I believe that both Windows and OS X can be successfully used for Docker development.
Still, there are other differences, besides processing performance, to consider. There are two that you should be aware of: file mounts and endpoints.
Docker CE on a Linux OS is able to directly use the filesystem for its file mounts in the running containers—this provides native-disk-performance levels. You also can change the filesystem drivers used to achieve different levels of performance. This is not available for Docker on Windows or Docker on Mac. For both Windows and OS X, there is an additional filesystem tool that handles the file mounts. On Windows, you will be using Windows shared files, and on OS X it is osxfs. Unfortunately for the Windows and OS X users, the performance hit on the file mounts is significant. Even though Docker has made leaps and bounds in improving the file mount story for Windows and for OS X with version 17 and later, both are still measurably slower compared to running natively on a Linux OS. For Windows specifically, the file mount options are very restrictive. If you are developing an application that is disk-utilization heavy, this difference might be enough to have you immediately consider switching to a Linux development workstation.
One other area that differs between Docker on Linux and Docker for Windows or Docker for Mac is the utilization of endpoint ports. One example is with Docker for Windows; you are not able to access a container's endpoint from its the host using localhost. This is a known bug, but the only workaround is to access your container's endpoints from a different host than you are running them on. With Docker for Mac, there are other endpoint limitations, such as not being able to ping a container (because Docker for Mac cannot route the ping traffic to and from the container) and you cannot have per-container IP addressing (because the Docker bridge network is not reachable from macOS).
Any of these limitations might be enough for you to consider switching your development workstation to an Ubuntu or CentOS operating system. It was for me, and you will find that most of the examples found in this book will be executed on my Ubuntu workstation. I will try to point out any areas that may be significantly different if you are using Windows or OS X.