25. Februar 2018

NAV Container self-service

One of the main scenarios in my mind for using NAV on Docker is the possibility to have a „self-service“ portal for my colleagues to easily create clean environments to try new cumulative updates, validate fixes and reproduce problems. This was possible for quite some time now but it took me a while to finally put it all together. Here is how it works for us.

The TL;DR¹

Creating a new environment for us takes four steps:

Create group Managed Service Accounts (necessary for Windows SSO to work in containerized NAV)
If it is an environment with our product Infoma newsystem: Download a reference bak and dlls
Start the container and make it use the bak and the dll as well as adjusting all necessary configs
Enable all users who need access

This process is started from a NAV page that offers all available environments. If a user starts a request, a ASP.NET core webapi on a Docker host is called and it triggers the mentioned process. The user can follow progress by accessing the container logs and in the end will see the URLs where the environment is available. Here is how it looks like²

The created NAV environment is not running locally on the user machine, but on a central Docker host to make administration and maintenance easier³.

How does it work

Let me add a bit more detail how it works: First of all, the current intention – and that might be subject to change – is to use the standard NAV image and not create a custom image. The reason for that is that Microsoft, especially Freddy Kristiansen, is working very actively on the standard images including new features and minor fixes on an almost weekly basis. If we had our own image, that would mean updating those images quite often. Of course that could also be automated, but at least currently I prefer to just configure and tweak the standard images at runtime although that leads to a startup of 7 to 10 minutes for newsystem environments. If that becomes a problem when working with those environments on a day to day basis we will very likely start creating our own images and would get way faster

A word about group Managed Service Accounts as this was the main reason why setting all this up took me so long: You will only need those for either authenticating your NAV server to an external SQL Server using a Windows account or for enabling Windows SSO in the clients. The last part is important for us as we have a lot of users who are using a lot of different databases during the course of a day. That becomes cumbersome if you have to enter user and password all the time. As we have a non-trivial Active Directory environment with multiple domains, this was a pain to set up, mainly because of a bug that was fixed only fairly recently. But with that fix it now works very well. We use a somewhat adjusted version of Jakub Vanak’s script to create those gMSAs⁴ and also delete them when an environment gets removed.

Downloading the bak is done from a Windows share that we already had in place for storing our reference databases. The DLLs are stored in our Team Foundation Server and can be downloaded as a zip. When everything is in place on the filesystem, we use simple volumes (bind mounts) to make it available to the running container. We also download a script that allows us to enable all users from an Active Directory group in the database as described by my colleague Markus Lippert here. Configuration changes only set a longer SQL warning threshold to not have too many warnings in the container log and use a different product name to show up in the WebClient. We also add a couple of labels to identify the containers generated through this mechanism and to know which release is made available in that particular container. The final run command looks like this:

docker run 
--security-opt "credentialspec=file://nsys17112-tfe.json" --name nsys17112-tfe --hostname nsys17112-tfe -e auth=Windows 
-e accept_eula=y -e accept_outdated=y -e username=admin -e password=xxx -e clickonce=y -e exitonerror=N 
-e folders="c:\run\my=http://tools.global.fum/grant-user-access.zip\nav-docker-samples-grant-user-access" -e DevDomain=FUM-GLOBAL -e DevGroup=GRP_INFOMA_DEV_ALL 
-v c:\nsys-freeze:c:\bkp -e bakfile=c:\bkp\newsystem_170110200_CU05.bak 
-v "c:\temp\nsys17112-tfe.170110200\kumulativ:C:\Program Files\Microsoft Dynamics NAV\100\Service\Add-ins\Infoma" 
-e customWebSettings="Productname=Infoma newsystem" -e customNavSettings="SqlLongRunningThreshold=10000"
--network MyTransparentNetwork -d 
--label Owner=TFENSTER --label NsysRelease=170110200 --label NavRelease=100 --label InfomaApiGenerated=true 
microsoft/dynamics-nav:2017-cu5-de

I won’t share the full code as this is quite specific to our environment and also because I coded this in probably 20 15-minute-stints between meetings or in breaks and the code very much looks like it… I might share it if and when I find the time to somewhat clean it up. Still I hope if you have the same problem this might help you get started to a solution and as always, I am very happy to discuss this on Twitter (@TobiasFenster) or in the comment section here.

if you don’t know what TL;DR means: This is short for „too long; didn’t read“. This section will provide you with a brief overview in case you don’t really want to read the details
I’ve cheated a bit by removing some parts where the user just waits and nothing is happening
and because Docker on Win 10 is the Community Edition with some flaws here and there
Actually we are also using a gMSA to create the other gMSAs which is a good way to make sure you are not creating a security problem here