Docker’s popularity has been driven in large part by its promise of letting admins build an application once and then deploy it anywhere. But this promise can be misleading when you are trying to use Docker on Linux and Windows hosts at the same time.
That’s because there are important differences between Docker on Linux and Docker on Windows. Although Docker runs natively on both operating systems, the approach you to take to using Docker in both platforms isn’t the same. What’s more, the rationales for using containers don’t apply equally to both Linux and Windows.
Let’s take a look at the key differences between Linux and Windows when it comes to containers.
On Windows, Not All Versions Are Supported
In most cases, Docker runs on any Linux system with a Linux kernel of 3.10 or later. That kernel version appeared in 2011, so most Linux distributions released since then work with Docker. And indeed, for Linux system admins, the fact that you can take a container running on one type of Linux system and move it to a different Linux server with minimal effort is a big part of Docker’s appeal.
The same can’t be said of the Windows world. Docker works only with Windows 10 desktop systems and Windows Server 2016 and 2019. There are other versions of Windows that Microsoft continues to support—and therefore may still be used in production—but don’t work with Docker.
For this reason, Docker loses some of its appeal in a Windows ecosystem, because it doesn’t let you deploy the same containerized application on any modern version of Windows.
Docker was designed for containerizing applications that have a command-line interface. On both Windows and Linux, it lacks a native way of connecting to a graphical interface inside an application.
There are certainly ways of connecting to graphical interfaces using a protocol such as RDP or VNC. But they require extra effort to set up, and they could create additional security risks.
This problem applies to both Windows and Linux. However, given that it’s more common for Windows apps than Linux ones to have a graphical interface, this limitation is more significant in Windows environments. If you are running a Linux server, you probably know your way around a Bash terminal, and might not have a graphical front end installed on it at all; Windows admins, on contrast, are more accustomed to being able to administer their systems and applications graphically.
On Windows, you have two ways of running containers. One is to run containers directly on the host, using what Microsoft calls Windows Server Containers. The other is to use specialized Hyper-V instances to host your containers.
On Linux, there is no official equivalent of Hyper-V mode for containers. You could set up a virtual server instance yourself to host your containers, which would more or less give you the same type of architecture as Hyper-V mode on Windows. But this approach is not built into Docker for Linux in the same way that it is for Windows containers.
Docker on Linux is ‘Pure-Play’
In the Linux world, Docker is a (mostly) open source platform that works with any Linux distribution from any vendor. Docker didn’t work closely with any particular company in the Linux space to develop containers or make them work with Linux.
The same is not true of Windows. Docker and Microsoft worked closely to bring containers to Windows.
This difference might matter to you if you are thinking about the longevity or flexibility of containers on Windows. If Microsoft decides in the future to stop supporting containers, that will probably be the end of containers on Windows. Users are also beholden to Microsoft to decide which versions of Windows they can containers on (see above).
On Linux, these risks don’t exist. Even if Docker decided to cease development, the container ecosystem is now so dynamic and large that other open source projects would likely pick the slack and ensure that Linux containers remain viable.
To put it another way: Whether you will be able to use containers on Windows 10 years from now depends largely on what Microsoft decides to do. On Linux, it’s a much safer bet that containers will still work in a decade, regardless of which choices any particular vendor makes.