21. February 2017
Create a NAV Windows/Docker container image with one command
I previously wrote about NAV 2017 in a Windows Container where I just managed to get NAV 2017 up and running. Some days ago Jakub Vaňák contacted me with a detail question about that post and told me that he managed to create a Dockerfile for NAV Server instances. What that means (and really kudos to Jakub as he did about 99% of the work) is that you don’t need to jump through all the hoops and type all the stuff that I did but really can create your container image with a single command!
Ok, there are some preparations: First, you need to get the code from Jakub’s GitHub repobut as probably all of you know, who even remotely followed the exciting news about the new NAV dev environment aka Visual Studio Code, that is rather easy: Open VS Code and just clone the repository through the friendly new welcome screen. If you open the file called “Dockerfile” VS Code actually recommends to download the corresponding extension. This takes about ten seconds and a restart of VS Code and you have full language support including IntelliSense and all the other goodies for Docker! I know I mentioned this before, but I really like VS Code and the NAV team’s decision to use it as the future dev environment for NAV.
As a second preparation you need to download a NAV installation DVD like NAV 2017 CU3 (I used the DE version), extract it and put the files in the “content” folder inside the directory structure you got from GitHub. Of course you also need to setup Docker (check the post mentioned above for info about that) and a SQL Server with a database you’ll use. I just fired up a SQL Server container and restored the Cronus DB from CU3 (also described in the post above).
Ready to go
Now we are ready: Just open the terminal of your choice (in my case I used the one integrated in VS Code) and start _rebuild.bat. This will take some minutes and show you progress information, but in the end you will have an image for NAV with the build you just downloaded. You can run “docker images” to show you the available images which in my case returns
REPOSITORY TAG IMAGE ID CREATED SIZE
myprivaterepo/navservice 10.0.15140.0 4c57ef77cc5c 29 seconds ago 15.6 GB
As you can see it automatically gets the build information from the DVD and tags the image accordingly. If you use another build, you get the same image but with another tag which is exactly how Docker images usually work. Again, kodus to Jakub! Now I would push this to my repository so that my colleagues or customers can also use the image, but I skip those steps as for testing purposes it also works locally.
We have the image ready, now we can start it. For that we have multiple scripts, but we need to tell it where to look for the database, which user to use etc.. I like to see what is happening in the running container at least for testing, so I use _run.interactive.params.bat but need to add the actual values in there. In my case it looks like this:
docker run -ti --rm --hostname=NAVSERVER -p 7045-7048:7045-7048 -e "sql_server=172.24.42.93" -e "sql_db=Cronus2017CU03" -e "sql_user=sa" -e "sql_pwd=VerySecret*123" -e "nav_user=DefaultUser" -e "nav_user_pwd=VerySecret*" -e "import_cronus_license=false" -e "config_instance=$True" --name %ContainerName% %host%/%ImageName%
As a result you see how the instance gets configured, the user optionally gets created and in the end you have a running NAV Server instance inside a Windows Server 2016 Core. I can now start my Windows Client and connect it to the NAV server instance (with some additional Client tweaking because of the self-signed cert, again see my original post). Just amazing!
Done. And now?
The first question is, why would you do this? I answered some of it in the last post but again, some interesting scenarios:
- You want to run multiple CUs on the same machine. This is true e.g. for datacenters hosting ISV solutions that are dependent on a CU but need updated CUs for later releases. Currently this is a pain if you need to run customers on different releases but with dockerized NAV you just fire up a new container with a new build and are ready to go without worrying about side effects.
- You need to reproduce customer problems with their CU but don’t want to install different machines for that. This is a slight variation of the first topic
- You get a fix from Microsoft with a CU. Now you want to repro the problem with the old CU and then directly with the new one. Just use two containers and it only takes you minutes or even seconds to get the infrastructure reliably up and running
- You need to support multiple CUs on developer machines because you have customers with different CUs. Again, easily solved with Containers
- You need additional components or configurations in the machines running your NAV based solutions at a customer. Just provide them with a pre-configured Container and they can easily start it and be sure that every dependency is there and every configuration is done correctly
I could go on with some variations on the same topic but I guess you can see the benefits (if you have on or more of those problems). The second question is, how to further improve this? The next step now would be to create a Docker Compose file which allows us to create multi-container environments. With that we could e.g. create an environment with 1 SQL Server container, 1 NAV Server container and 1 IIS container to just start a whole NAV environment with 1 command. And then we could take it a step further and use one of the orchestration tools like Docker Swarm or Kubernetes or Mesos to build a scalable cluster (as far as SQL and NAV allow it).
The only issue now is that Microsoft doesn’t officially support it but maybe they will look into this. I really think we would have awesome new possibilities and a lot easier life for NAV admins and hosters.
Last but not least, thanks a lot to Jakub for coming up with almost everything of the code and sharing it!
To be continued…