This is my first blog, hopefully not the last, so apologies in advance. In this post I will share a few key issues that I encountered while trying to run a .NET application which is traditionally run on a Windows server OS to containers. Due to the requirement of the application I was porting, I selected windowsservercore container, which needed full .NET Framework.
Running Windows Services
Ideally if possible you would want to run the service from the command line, if it allows. This gives you two things:
In containers you need to have a command which is running, when that command finishes, the container will exit. By running from the command line, you ensure that if your service crashes, this results in the container exiting which docker can detect. Also you do not need to have an artificial process running so that the container does not exit, like it is done with microsoft/iis image.
Docker has support for redirecting logs from console to the daemon, if you are running the service from the console and your application can output the logging information to console, then you can leverage dockers mechanism for aggregating the logs in a central location.
docker run -it <container_name>
docker run -dit <container_name>
Multi container application
RUN set-itemproperty -path 'HKLM:SYSTEMCurrentControlSetServicesDnscacheParameters' -Name ServerPriorityTimeLimit -Value 0 -Type DWord
Missing VB runtime
While trying to install the application using msi in dockerfile, I kept seeing that the installer failed somewhere halfway. Later, I found that the windows core container is missing VB runtime, which was not a pre-requisite of the software, hence not being installed on the images. While trying to debug the installer issue, I learned two tricks:
Try mounting a volume while running the container and log the installer log to the volume, and use a text editor tool from the host to look into the log.
However, just looking at the logs, I was still not able to pinpoint that it was missing the VB runtime, so, I first tried running the installer on a Windows Server 2016 Standard installation, where it ran fine, then I ran the installer on a Windows Server 2016 Core (without GUI) where it failed with the same issue. Then using procmon I was able to see that it was trying to load the VB runtime. So, I think it is very wise to try to install the application on a Windows Core (without GUI) server, which can help you to find any issues in an environment where you have more control.
Windows Containers cannot join a domain, hence if you have application which relies on pure Windows Authentication you are out of luck. For the services that I was migrating there was a hard requirement that, the UI running on IIS talking to a WCF service need to establish a trust relationship, which was based on the windows authentication of the IIS application pool. This trust was needed as that application was allowed to impersonate any user in the system. There are two solutions that can be taken:
Create local user with the same username and password on all the containers and use that.
I decided to rely on SAML and certificate based trust
Try installing and running the application in Windows Server Core (Without GUI) to ensure that they work and all dependencies are figured out.
Mounting a volume to copy resource and config files back and forth in the container and host, so that you can rely on the hosts text editor capability. Also this allows some adhoc files being copied and or deployed if you find missing, rather that trying to rebuild the entire container image.
Visual Basic runtime is missing, which some legacy application might rely on.
Cannot be added to domain, so either use a token based authentication or local users with same username and password across all containers or other form of trust relationship.
Preferably have a process that you can run in the daemon, otherwise you can use the powershell snippet provided below to keep the container running
Start-Sleep -s 60
} while ($true)
Some services when running from the command line uses “Press any key to exit” for those containers you need to run them in interactive mode.
Preferably your application when running from a command outputs all logs in console.