Solutions
Markets
References
Services
Company
Quickly spin up a fully integrated version environment for NAV on Docker

Quickly spin up a fully integrated version environment for NAV on Docker

18. August 2017

Quickly spin up a fully integrated version environment for NAV on Docker

This is a follow-up to the last post by Tobias about the self-contained NAV containers. The idea is to have docker images with NAV server, database and the matching NAV clients to quickly deploy an older version of our software for reproducing of fixing bugs. This way we want to overcome the need of having multiple CU versions of the clients installed locally and make it possible to use different, cleanly separated CU versions on one server. Tobias also wrote about the idea of using Portainer, which he introduced here, to enable developers the option for self-service deployment. This is exactly what I want to describe here.

As a base I used the nav-docker repository of Microsoft. I fixed two little bugs with ClickOnce (see 1 and 2) and created own scripts for adding a Windows user to access NAV. I used this “workaround” as gMSAs are currently not working in our company network. If you just add the windows user to the container with the same username and password the windows authentication will work fine anyway (not exactly a nice solution, but it works… If anyone has an idea why this isn’t working, please contact Tobias, it would be greatly appreciated). Don’t forget to add hlink.dll (always needed) and mage.exe (only if you want to use ClickOnce) to the Run\Install folder to successfully generate the container as well as the ClickOnce manifest.

We can then build the generic image:

docker build -t infoma-ver-env .

After that we want to generate our specific “version environment” image with the right NAV CU and our custom Add-Ins which can be specific to one or multiple Infoma newsystem (our product family) releases. Typically we try to support the CU binaries as long as possible (no breaking bugs are fixed) and update custom dlls also as seldom as possible but because we deliver new features more often than MS does on-prem we typically need to deploy custom dlls more often than CUs. Therefore we usually wouldn’t be able to use the standard CU images with our Add-Ins on top but need to have multiple images for each CU. Adding your custom Add-Ins is as easy as putting them into a folder with that name in the Run directory. Now we do:

docker run --name tmp -e ACCEPT_EULA=Y -e auth=Windows -e ClickOnce=Y -v 'C:\dvd\:C:\NAVDVD' infoma-ver-env powershell 'C:\Run\buildimage.ps1' 

When this build is successful, we tag our specific image with the registry prepended (to allow deployment via Portainer), remove our temporary building container and push the image to the registry:

docker commit tmp s00-nsys-reg.axians-infoma.de/infoma-ver-env:2017-cu5 
docker rm tmp 
docker push s00-nsys-reg.axians-infoma.de/infoma-ver-env:2017-cu5 

We could then run the image interactively via the CLI:

docker run --rm -it -e licensefile=http://navfiles/dev.flf -e bakfile=http://navfiles/newsystem_170100000.bak --network=MyTransparentNetwork infoma-ver-env:2017-cu5 powershell 'C:\Run\start.ps1' 

I specified the license and backup via URL to a fileserver (obviously, also Container-based) to have more flexibility. Alternatively you could mount the files into the container like this:

docker run --rm -it -e licensefile=C:\data\dev.flf -e bakfile=C:\data\newsystem_170100000.bak –v C:\nav:C:\data --network=MyTransparentNetwork infoma-ver-env:2017-cu5 powershell 'C:\Run\start.ps1' 

With the interactive approach, the docker run command prompts for the username/password and will look like this:

Initializing... 
Running Specific Image 
Starting Local SQL Server 
Using Windows Authentication 
Downloading database backup file 'http://navfiles/newsystem_170100000.bak' 
Modify NAV Service Tier Config File for Docker 
Hostname is 8ba78eeeaa1b 
Modify NAV Service Tier Config File with Instance Specific Settings 
Restart NAV Service Tier 
Downloading license file 'http://navfiles/dev.flf' 
Import NAV License 
Create Web Site 
Create NAV Web Server Instance 
Create http download site 
Create ClickOnce Manifest 
Running additional setup.. 
----------------------------------------------------------------- 
Username (without Domain): mlippert 
Password: ********* 
----------------------------------------------------------------- 
- Setting up Windows User.. 
- Setting up NAV User and Permissions.. 
- Creating SQL user.. 
Container IP Address: 10.111.90.90 
Container Hostname  : 8ba78eeeaa1b 
Web Client          : http://8ba78eeeaa1b/NAV/WebClient/ 
ClickOnce Manifest  : http://8ba78eeeaa1b:8080/NAV 
 
Files: 

Ready for connections! 

A more convenient method though is to use Portainer. We created our own app templates file and added a template for each database to allow starting a container without setting any options manually. A template could look like this (this one would be for Infoma newsystem 17.1.0.0 based on NAV 2017 CU 5):

{ 
    "title": "NAV VersionEnvironment", 
    "description": "2017 CU5 - NSYS 17.1", 
    "logo": "https://meine.infoma.de/webinfoma/iupdate.nsf/files/logo.gif/$file/logo.gif", 
    "image": "infoma-ver-env:2017-cu5", 
    "command": "powershell C:\\Run\\start.ps1", 
    "registry": "s00-nsys-reg.axians-infoma.de", 
    "platform": "windows", 
    "categories": ["nav", "infoma"], 
    "env": [ 
      { 
          "name": "NonInteractive", 
          "set": "Y" 
      }, 
      { 
          "name": "licensefile", 
          "set": "http://navfiles/dev.flf" 
      }, 
      { 
          "name": "bakfile", 
          "set": "http://navfiles/newsystem_170100000.bak" 
      } 
    ], 
    "network": "MyTransparentNetwork" 
} 

The NonInteractive environment variable prevents the execution of the custom script to create a user as Portainer doesn’t support interaction at container start. After specifying the URL to the custom templates.json in the Portainer settings under “App Templates” the version environments are just a few clicks away:

There are a few things to note:

The next step to start the container even faster would be to commit this ‘complete’ image also. This reduces the startup time from around 3 minutes to 10 seconds but currently brings some weird problems with it on which we’re working right now.

When everything runs smoothly in the future the healthcheck script could be extended to continuously check for NAV sessions and stop the container if there aren’t any left. All stopped ‘version environment’ containers could be deleted after maybe 3 work days to avoid involuntarily losing test data. We have a custom built tool in place for managing the dev, test, qa and customer databases in house which could be extended to handle the container instances through Docker API calls.

To conclude, Microsoft is making some great steps into the right direction with the use of Docker in conjunction with NAV. The use of this technology helps a lot with quickly deploying the complex NAV environment and will speed up the development process itself.


Leave a Reply