CRS.RemoteNAVDockerHostHelper – Updated!

I’m not going to blog about each version of this module, but for this update, I felt obligated to share a few words. Primarily, because all has changed :-). Not one function is the same. I renamed all of the functions to a more convenient name – as they were quite long (not to say: ridiculous ;-)).

For that reason, I have edited my previous blogpost, where I introduced the new module. Still, since I (think I) made it a little bit easier for you to get started with it, let me share a few short paragraphs on the tool again (some is repeated, but you know – Repetitio Mater Studiorum Est ;-)).

Introduction

This tool has been created from my own development experience, where I have:

• Machine 1: My Laptop or Home-PC where I develop. A “local development machine” if you will 😉
• Machine 2: A remote docker host, meaning either:
  • A VM on Azure, created by the wonderful templates for Freddy (like: aka.ms/navdeveloperpreview or aka.ms/getnav), where NAV is being made available through Docker.
  • A local VM on Hyper-V (on the laptop,, or on the PC), that has a Windows Core with Docker on it, where I want to run NAV Containers, same as it would be on the VM on Azure. This way of working is described by Arend-Jan Kauffmann here.
• Machine 3: Docker Container running on that docker host, containing a NAV installation. These are the NAV ServerInstances I want to publish my apps to, and such .. basically the NAV I want to develop against..

So, it might be all on my laptop or partly on Azure – in any case, it’s 3 machines, which needs to be able to be managed likewise – by running PowerShell scripts remotely. And THAT’s the purpose of this module – to make that somewhat easier ;-).

Getting started

To get started with this module, there are two things you need to do first.

Enable Remote PowerShell on the Docker Host

You need to make sure that your docker host is remotely accessible by PowerShell. I’m not the expert in that, but what helped me was AJ’s blog and also this one to be able to set that up.

Install the dependent Modules

The module is dependent on some other modules, depending on the functionality you are going to use. Making these modules available is quite easy. I created a function for that, which is part of the module: Install-RDHDependentModules . Just run it like this, and all is set up:

Install-RDHDependentModules `
-DockerHost $DockerHost `
-DockerHostCredentials $DockerHostCredentials `
-DockerHostUseSSL:$DockerHostUseSSL `
-DockerHostSessionOption $DockerHostSessionOption `
-ContainerName $Containername

In a future version, I will probably include this in some other functions, just to prep the container if not already prepped.. .

You’re good to go!

So, when above is done, you’re good to go. For each remote environment, I tend to make a separate folder, like you see in here. Each folder holds a set of scripts, where one is the settings-file, with usually specific sessions for this docker host. This settings-script is usually ran first in any other script.. . It makes it easy: just figure out the remote execution settings once, and you’re good to go for all your specific scripts. Just take these folders as an example.

Also useful for upgrades?

You see a folder “UpgradesOnWaldoCoreVM” – this is now how I actually perform my upgrades – so yes, definitely useful. But how that works – that’s for a future blogpost – because I still need to clean it up a bit ;-).