15. August 2017

A self-contained NAV Container

You might have seen here that Microsoft NAV is now officially on it’s way to support Docker / Windows Containers. The scope is not defined yet, but you can see the Dockerfiles here and if you contact Freddy Kristiansen you might get access to a Azure-based repository containing current images. Looking back nine months to my early attempts it once again really is amazing how far we’ve come.

But the topic for the current post is something specific built on top if the current state of the MS images: the idea of a self-contained NAV Container. To explain why I think this is a good idea and what I want to achieve, I might need to add a bit of background: At Axians Infoma we are delivering the exakt same solution to more than 1.000 customers, either in traditional self-hosted OnPrem environments or through data centers hosting our solution based on NAV for them. Because of that scale, repeatability and really good and exact versioning is crucial. That used to include only NAV code through .fobs, but today we also have .dlls and the matching NAV CU because we have a new one every months and a) sometimes they are no longer compatible with previous one and b) our quality assurance is based on one CU and we want our customers to use exactly that.

Because of all of this we need to have „version environments“ which represent all necessary components at the point of time when we delivered them. Again, this used to be kind of easy with only .fobs, but know you need a NAV environment with the right CU and the right custom and official .dlls. To be able to work with that environment, you also need a matching client (if you don’t want to risk „funny“ problems because of mismatched client / server builds) and that is the point where if get’s really difficult as you can’t install multiple CUs on the same machine. Because the world isn’t perfect, some of our customers take a bit longer to go to our latest release and still might need a fix for a critical bug (which obviously never ever occur…), so we need to deliver a special .fob on an older NAV CU.

We’ve built an environment which allows us to handle all that, but it is kind of complicated, a lot of work (automated as far as possible, but still work) to keep it running and current and just plain ugly if you look at it from a Software Engineering standpoint. How do Containers help here? My idea is to have a Container image which includes everything that is needed to work with a release, including dev and test. And it actually is not that difficult: The mentioned images by MS already contain the standard binaries at one point of time, so we don’t need to worry about that. We also need to take all custom .dlls for the release and add them to the image, which is quite easy. With that in place, the server side is taken care of. For the client side, Microsoft offers a technology called ClickOnce, which allows to deliver a solution with a specific build to a client machine with one click. The official images already include the Windows Client as ClickOnce application and with support by Freddy I could add finsql as ClickOnce application as well (see here. With that you get a download page from a Container instance like this:

Now we have everything in place to work, develop and test based on a given release. The database is part of the image as well. Because of the ClickOnce delivery, you don’t need to worry about client-side installations. And if a developer needs to create a patch .fob, you don’t need worry about changed code or forgotten adjustments afterwards. You just throw the Container instance away and create a new one based on the image! If you run something like Portainer (see here), this can be a self-service case for developers and product managers with instant results.

This is just one of the scenarios where Docker Containers really help in the NAV world, but a quite important one with lots of benefits compared to an enviroment without Docker