Containers and Windows. From Hello World to Kubernetes. Part One, Introductory
When I talk to Linux engineers and tell them about the problems of the Kubernetes cluster on Windows, they look at me very suspiciously. Some do not even believe that
Windows Containers
According to this article:
Many .NET or SQL Server developers bit their elbows and envied their fellow Linux workers.
Indeed, containers on Windows were exotic until recently. And the worst part is that the documentation had to be collected in bits and pieces, on each resource, whether it was the official Docker or Microsoft website, everything was presented in an overview form without a description of “how and why,” and after a month or two the existing information became outdated. And there is nothing supernatural in this - containers and technologies associated with them are developing at some unrealistic speed.
At the moment, everything has become better with the documentation and to plunge into the world of containers for Windows, just read the official documentation from Microsoft and monitor its changes. Interestingly, the documentation is written well in Russian, although with a deep study you can’t avoid clicking on links to various resources like https://www.docker.com/ or https://kubernetes.io/ where everything is written in the old good english.
Now the answers to any questions can be found in the official documentation, but there are some nuances that are best known in advance. Perhaps this will be useful to you and save time when immersed in container technology under the Microsoft flag.
You cannot run Windows containers on Linux and on Windows *
Container technology makes it easy to handle the environment thanks to reconfigured application images. It's like an Apple Appstore or Google Play, but only for engineers and developers. As in stores for mobile applications, you can’t put the application from Google Play on iOS. So on the Docker host with the Linux operating system, you cannot start the container with the Windows operating system. The converse is also true, though with some “buts”, since the Docker host with Windows can still provide Linux with an environment for running containers.
Also, you cannot start the Windows container in the Windows environment without making sure that the operating system versions are compatible. When working with containers from Microsoft, you will have to look back at the Windows Container Version Compatibility and periodically open this document.
Speaking of versioning - Microsoft with the advent of containers decided to release new semi-annual versions of Windows semi-annual. These are versions such as windows server 1703, 1709, 1803, 1809, 1903. The numbers indicate the year and month of release, and they are supported for 18 months. The first two are already resting in peace and are in the end of service. In addition, there are LTS versions such as Windows Server 2016 and Windows Server 2019. Version list.
So, if you assembled the container on a host with a version of Windows 1803, then you can only run this container on hosts with Windows 1803. Accordingly, in order not to rebuild the container itself each time, you will have to use the LTS version of Windows, which with modern technology development speeds not always justified. Or, nevertheless, think about versioning and still constantly reassemble containers following the step-by-step program for semi-annual.
The latest tag in Dokerfile for Windows containers is not always present and generally deprecated . In a good way, you always need to know what your version of Windows is and make the appropriate changes to the Dockerfile.
Containers are part of the Infrastructure as Code approach. Containers need to be reassembled constantly, it’s not only simple and fun, but this is the main magic that allows applications to always work on fresh, improved software. But in our case, we are faced with a limitation: it will not work to keep a universal Dockerfile for all Windows systems. This must be taken into account.
All of the above is true for containers running in process isolation mode. In Hyper-V isolation mode, backward compatibility is in effect - you can run all containers that are built on the current and previous versions. In general, using Hyper-V isolation, you can also run Linux containers on a Windows host. But this mode so far supports fewer goodies, which is just the lack of Kubernetes.
The difference between process isolation and Hyper-V isolation is the topic of a separate article. For now, I’ll just say that the scenarios with Hyper-V isolation are not entirely obvious to me, and by default, Windows uses process isolation.
Another headache is finding the correct version of the images on the Docker Hub. Some images are generally missing for Windows. For example, you will not find the official build of Nginx, MySQL, Nodejs, as well as hundreds of other applications for Windows and you will have to collect containers yourself or use containers collected and provided by community members.
Windows costs money.
Do not forget that Windows is still a paid thing. For example, Semi-annual versions are available through Visual Studio subscription or with Software Assurance in a valid Microsoft license agreement. Link.
But Microsoft has a large number of ways to get paid for free. This is the BizSpark program and all sorts of trial versions of Windows Server 2019 for 180 days and so on and so forth.
Windows containers are not lightweight.
It is generally accepted that containers are lightweight, but that the truth for Linux is not always true for Windows. The vast majority of Windows containers, at first glance, weigh prohibitively much. And at the second glance the impression does not change. For example, the basic aspnet: 4.8 image weighs about 7.5 GB.
Even if you host the base images in a local repository, the initial upload of the image to the host will take quite a while, let alone remote repositories such as the Docker Hub.
Yes, you can use the lightweight Windows Nano Server in some scenarios, but alas, it has a bunch of limitations. And even more so, you are not on the way with Windows Nano Server if you are developing for the .Net Framework.
To manage, you need to know CMD and Powershell well.
Most likely you will have to work with the core version of Windows Server on Docker hosts. Windows Server has a wealth of remote management capabilities. The general approach is that having a Windows Server with a graphical interface, you can connect all the graphic snap-ins to any core server.
This approach does not work in container scenarios, although the container contains the full version of Windows Server. Inside the Windows container, it is theoretically possible to connect via WMI, but this is not so simple, if only because the tail OS will intercept this traffic for itself. There can be several tens and hundreds of containers on a host, and in this case, directing traffic to the desired container is a whole thing.
CMD and Powershell will be needed both for the administration of containers and for the host on which Docker is installed. Also, knowledge of these shells is necessary for writing a Dockerfile, since all RUN instructions will be executed in the aforementioned shells.
Remembering all the long Powershell cmdlets is pretty tricky. These are not concise bash commands for you. Although now most of the cmdlets have aliases clear to any Linux engineer. In powershell, you can use:
rm Remove-Item pwd Get-Location. cat Get-Content touch New-Item etc. # Linux . rm –rf . # Powershell man Get-Help <>
Of the extremely useful things, it is that using Powershell you can run a simple web server in a container for testing purposes. In Powershell, everything appears as objects. If you are a proponent of OOP, then you will quickly appreciate the benefits of this shell.
As a conclusion to the introductory article, I want to say that I deliberately did not address the issue of orchestration and cluster management. Docker on Windows is catching up and orchestration applications such as Swarm and Kubernetes on Windows do not fully realize their functionality.
Also at the moment, if you want to raise the Docker cluster, then it will most likely be multi-platform. That is, you will have to have one or more Linux hosts in the cluster. For example, for Kubernetes, master nodes must be on Linux. And in Swarm, Linux containers are needed, for example, to implement a balancer on Nginx or run other popular cluster applications that are available only for Linux.
PS Using Windows in containers has a very limited set of scripts to use. However, these scenarios can be extremely productive. Of course, the first thing that comes to mind is web applications on IIS, but my experience shows that self-contained Windows services and some services such as MSMQ are well isolated in containers.
UPD. There is a slight inaccuracy in the article; you can build a Docker cluster on only Windows hosts. Moreover, this is not only Swarm, but also a product developed by Micrisoft for orchestrating a Service Fabric cluster
UPD2. Docker containers for Windows 10 are only available in Hyper-V isolation mode and use basic images other than Windows Server.
All Articles