Why the Nano Server Operating System Should not be Used As a Containerization Solution.
In this article, we analyze why the Nano Server Operating System should not be used as a containerization solution.
While the topic may look a little too negative, the article aims at presenting facts about the problems involved with Nano Server and containerization.
Let us check some info about Nano Server and Containerization.
Nano Server
Nano Server is a “new generation”, “Tiny” headless Operating System developed by Microsoft Corporation using Windows 2016 as the base O.S
Nano Server can be seen as a minimal windows 2016 server It has no Graphical Interface whatsoever and no way to add it, unlike the Linux distribution where X-systems (kdm, gnome,..) can be added. Besides, Nano Server has no console login ability.
Nano Server is not to be confused with Windows Server 2016 Core which is GUI-less but which has console ability,
The server itself is conceived to be very secure because among others it has a very small attack surface with the minimal amount of services needed. The connection to Nano Server is typically done via remote Powershell. It is possible to install an SSH server but this is not a recommended use because most of the interaction with Nano Server is to be done via Powershell scripts.
The development of Nano Server comes after the arrival on the market of several tiny “minimalist” operating systems such as :
- Rancher O.S;
- Core O.S;
- Photon O.S;
- Tiny Core Linux.
Such Operating Systems have a very small footprint (500 MB ROM as opposed to 10 GB for the GUI version) and are primarily targeting containerization via docker.
Containerization
The concept of containerization could be defined as packaging applications into “containers” that will be run into container platforms.
The concept is close to the packaging of applications into bytecode which is interpreted and run by virtual machines such as the Java or .NET virtual machines for instance.
But with the containerization concept, it is possible to containerize a wide range of applications.
Containers are standardized units for development, shipment, and deployment so they allow a developer to create, from his code, within a single process a runnable container.
The actual containerization technology is primarily handled by the docker engine, developed by Docker Inc. nevertheless other containerization technologies are available:
- CoreOS RKT;
- Mesos Containerizer;
- LXC Linux Containers;
- OpenVZ;
- Snappy;
- Containerd.
Here we represent the typical layers of a docker containerized solution. The applications APP#1…APP#N are packaged into N Containers running inside the Container engine, which is on the top of the operating system itself.
Nano Server and Docker
Nano Server has been described by Microsoft as a primarily “container-only” operating system.
The “physical” features such as Hyper-V, SOFS or Failover Clustering have therefore been removed from Nano Server in the mid-2017 ( starting with version 1709 ) so that the O.S could become a container platform.
Many customers and experts have expressed their dissatisfaction and doubts regarding that decision because Nano Server was, after all, a convenient and secure solution for deploying, for instance, Hyper-V machines.
This approach, however, should motivate the choice of Nano Server for a Containerization solution. Unfortunately, it appears that Nano Server can be … the worst choice for running containers.
Here we aim at presenting facts regarding the use of Nano Server for containerization.
A Guide to Install and Use Nano Server
The right way to use Nano Server is to create a VHD image and as we shall see, it is not at all an easy process.
How to Create the Nano Server VHD: A Painful Task
Convert-WindowsImage.ps1+ Windows 2016 ISO image
There are many guides on the internet how to install Nano Server.
It is necessary to download an ISO image of windows 2016 server then to generate a VHD from the ISO filesystem.
Here we use a Powershell script named Convert-WindowsImage.ps1 to do this.
Note that in itself, the process to install Nano Server is very painful because the image must be built as a VHD disk image from the windows 2016 server ISO image. In fact from the image at wim format of the Nano Server. In comparison, it takes only a few minutes to install most of the minimal O.S of the market while generating the Nano Server VHD can take a few hours ( and a lot of trial and errors) because many components and tools must be downloaded.
The Powershell script will work most likely only on a windows 2016 machine (while it could work on a Windows 8 or Windows 10 machine) and it may fail to generate the VHD without any error message…even on a fully patched windows 2016 machine!
Nano Server Image Builder + ADK+Windows server 2016 source + windows 2016 machine
Another way is to use the Nano Server Image Builder which will create the VHD after installation of a few additional runtimes and other software components (more than 6GB).
But it may take up to 30 minutes (with a high-speed internet connection) for the Nano Server Image Builder to download and install everything which is needed. Namely the Windows Assessment and Deployment Kit (ADK).
Once installed, the tool still needs to download a windows server 2016 ISO source, which will take around 6GB again… So more than 12 GB to generate the 500 MB of the Nano Server VHD.
But once all is installed, the creation of the Nano Server virtual machine image is a straightforward process from the GUI.
Any driver needs to be incorporated into the image. The virtual box drivers should be loaded automatically but apparently, they aren’t. For example, the image won’t work with Virtual Box because none of the Vbox network adapters can be found.
The Building of the VHD may take some time.
In fact, the Tool does not install the virtual Box drivers and does not provide any optional way to do so.
The solution is to pass the -OEMDrivers flag to the Powershell commandlet called by the tool.
These scripts are located into the Nano Server folder of the windows 2016 server ISO CD-ROM.
Run:
Import-Module .\NanoServerImageGenerator\NanoServerImageGenerator.psd1
Then:
New-NanoServerImage -MediaPath ‘D:\’ -Edition ‘Datacenter’ -DeploymentType ‘Host’ -OEMDrivers -TargetPath ‘C:\Users\Administrator\Documents\nano2.vhd’ -MaxSize 8589934592 -EnableRemoteManagementPort -SetupUI (‘NanoServer.Containers’, ‘NanoServer.Compute’) -SetupCompleteCommand (‘tzutil.exe /s “Pacific Standard Time”‘) -LogPath ‘C:\Users\Administrator\AppData\Local\Temp\2\NanoServerImageBuilder\Logs\2019–08–04 20–59’
This is so far the only solution that worked for a deployment to Virtual Box.
Only 100MB needed but difficult: using NanoServer.wim
In fact, among the 12 GB of files (ADK+windows server 2016 ISO), the only file which is of interest to the Nano Server Image Builder is the NanoServer.wim (around 100 MB) which is located in the Nano Server folder. If that file can be accessed, then the process needed to generate the VHD is relatively straightforward.
That file could be converted to a VHD thanks to a tool named WIMTOVHD but unfortunately, it had been withdrawn from MSDN and cannot be found anywhere, even with the help of the way back machine.
In fact, Convert-WindowsImage.ps1 does the same thing than WIMTOVHD because it doesn’t need the whole of the 6GB of the Windows server 2016 sources but just that wim file. The problem is that on many occasions, as we mentioned it earlier, Convert-WindowsImage.ps1 simply won’t work.
A solution is to mount the WIM file to the file system then to create a VHD from that file system
DISM /Mount-Wim /WimFile:”nanoserver.wim” /index:1 /MountDir:”c:\temp”
We create a VHD using windows disk management tools. We then copy the WIM extracted file to the VHD and make the VHD bootable. The partition needs to be active ( you can use DISKPART for this ) and the BOOTMGR and WINLOAD components must be manually added to the root of the partition. Additionally, there are a few tools available on the web to convert a non-bootable VHD disk into a bootable VHD disk.
The drivers for the target (network card) may also have to be added manually in the VHD.
Why Nano Server Should Not be Used for Containerization
If you could have made it so far and you managed to reach the point of creating the VHD, you can now start to run Nano Server either in the cloud (azure for instance), as a VM or on a physical server.
As we mentioned, Nano Server must be reached at the start by remote Powershell, that is to say via WinRM which is slightly more complicated to use than SSH or remote desktop.
A local access just allows to interface the console recovery, a basic program allowing to configure the network without any shell. Drivers must be incorporated during the creation of the VHD because they usually cannot be loaded by the console recovery.
That is not necessarily a bad thing because it creates more security, but combined with the hassle of generating the VHD, it may discourage several network engineers to proceed any further.
Depending on the Nano Server versions, the docker daemon may not be present and in such a situation, it will have to be installed, officially via the Powershell gallery.
Reaching that point, the hardness to create and deploy the Nano Server Virtual Machine should — in itself — justify the leitmotiv of the present article. But we are now in fact only reaching the core of the problem: Nano Server is just not good at containerization!
Enabling Windows RM
To enable communication with Nano Server, you need to proceed with the following steps. These steps can be easily found over the internet but we still will list them here.
In our scenario, we connected the Nano Server to a Virtualbox Host-Only adapter with DHCP so that the Nano Server receives the IP 192.168.215.3.
- Enable Windows Remote management by typing in an elevated prompt:
Enable-PSRemoting -Force
- Enable the connection to the target by allowing it as a remote host (here we authorize any machine for the sake of simplicity):
winrm set winrm/config/client `@`{TrustedHosts=`”`*`”`}
If you encounter an access denied error, make sure that the administrator account is password protected. As stupid as it looks if the local administrator account isn’t password-protected, all access to winRM will be denied whatever you may do.
Next, enter the remote session with:
Enter-PSSession -ComputerName 192.168.215.3 -Credential administrator
Again, if you use an IP address, do not forget the -Credential flag or you will be denied access.
Once connected we test for docker… which is not present.
While we choose the Containerization option when building the VHD, docker isn’t there at all.
Installing Docker on Nano Server
The procedure to install what should already be there — the docker system — is the following:
We run the Powershell command:
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
This may not work on some versions of Nano Server. Here we assume that the command completes well.
This installs the required package providers.
Next, we install the docker package itself:
Install-Package -Name docker -ProviderName DockerMsftProvider
We receive a message telling us that :
- Invoke-WebRequest does not exist;
- No package “docker” was found.
While the two errors seem unrelated, one is in fact the cause of the other.
The problem is Invoke-WebRequest which isn’t there. This causes the fetching for docker to fail. In fact, that command has been removed from PowerShell 5, shipped in that Nano Server, but nobody seems to have noticed it.
One solution is to use a replacement for the Invoke-WebRequest missing script.
In fact what we need are just two files: the docker client: docker.exe and the docker daemon dockerd.exe.
Instead of trying to repair the broken Powershell scripts, we will fetch that zip file and extract it to the system32 folder for instance.
At that stage, it seems clear that there are no ‘official’ ways to obtain the docker system on Nano Server.
There are plenty of ways to load files to the Nano Server. The simplest method is to create a network share:
Creating the share folder:
New-Item C:\Share -type directory
Opening the firewall for the share:
netsh advfirewall firewall set rule group=”File and Printer Sharing” new enable=yes
Sharing:
net share MyShare=C:\Share /GRANT:EVERYONE`,FULL
The Share folder is simply reached by typing the command
\\192.168.215.3
In a browser.
Once we have copied the files, we have a docker system running on Nano Server!
Deploying .NET Images to Docker on Nano Server
The choice of Nano Server should be considered logical if one wants to deploy .NET components and especially .NET framework components.
Indeed there are two types of .NET binaries:
- The dotNET core binaries;
- The dotNET Framework binaries.
DotNET core is a “minimal” open-source, cross-platform and self-contained version of dotNET while the .NET framework is the full version of dotNET. The two versions have of course a common intersection but remain quite different.
While the non-Windows based Containers, and in particular docker for Linux, can run dotNET core images, they cannot usually deploy dotNET Framework images.
In that context, Nano Server seems a very logical and natural choice for a company which will seek to deploy and scale dotNET framework images (ASP.NET for instance).
We try a test docker command, aka running the hello-world sample:
docker pull hello-world
This triggers immediately an error.
This is a common problem encountered by many Windows users of docker.
If we pursue with docker development, there will be constantly such errors, making the development of a docker solution on Nano Server very hard.
Alternatively, all the steps needed for running the “Hello World” docker image on a RancherOS System ( from the beginning ) should take no more than 15 minutes to any average experienced software engineer… against what could be several days for Nano Server.
If one wants or needs to develop docker for Windows, then a full Windows 2016 GUI edition may be the right choice.
Nano Server is a very exciting “concept” Operating System but so far it seems it has no real interest and can be a real problem in terms of development, making a container project to eat days and days and weeks and eventually ending in a miserable failure, in such a way that the development team has to perform an emergency fallback to a Linux Operating System or to a Windows GUI Operating System!
In that article, we aimed at presenting real facts about the problems involved with Nano Server, Docker, and Containerization.
This article first appeared on the Acodez
