Creating a Dynamics 365 Business Central Docker container with artifacts on Azure Container Instances

Azure Container Instances (ACI) is a great service offered by Azure that permits you to run serverless Docker containers in Azure with simplicity and speed, without having to provision or manage any underlying infrastructure.

I think that this service can be extremely useful when working with Dynamics 365 Business Central too, because you can spin up a container in few minutes with all the power you need, use it as needed and then delete it, all with some simple scripts and without provisioning any Virtual Machines in the cloud or installing software.

More than 2 years ago I wrote a post for explaining how to use ACI for creating a Dynamics 365 Business Central container. Now Microsoft has recently changed the way on how to create Docker containers for Dynamics 365 Business Central and the reference for this topic is obviously the Freddy’s blog. Basically, to have a more manageable solution, Microsoft will stop producing docker images and instead they will publish builds as artifacts, which can be used together with the generic docker image to run the image you want.

To create a Docker container with Dynamics 365 Business Central we now need to have two things:

  • the base image to use (accordingly to the host’s OS).
  • the artifacts to download

If you use NavContainerHelper module all is simple and well explained on the Freddy’s site. For the base image name, NavContainerHelper has a function called Get-BestGenericImageName that gives you the best generic image to use for your OS.

But how to do that on Azure Container Instances?

The first step that to do we have is to find the base image name to use. On ACI, supported OS versions are Windows Server 2016 or Windows Server 2019. You can have a list of all the available generic images with the following NavContainerHelper command:

$imagetags = Get-NavContainerImageTags -imageName "mcr.microsoft.com/dynamicsnav"

For example, Windows Server 2019, Version 1809 is version 10.0.17763 and from the above list you can use the generic image called mcr.microsoft.com/dynamicsnav:10.0.17763.973-generic.

The second step is to find the artifact url for the container that we want to create. Here I want to create a Docker container on ACI with Dynamics 365 Business Central 16.2 IT, so I execute the following command:

$artifactUrl = Get-BCArtifactUrl -version 16.2 -country it -select Latest

and this gives me the following artifact url:

https://bcartifacts.azureedge.net/sandbox/16.2.13509.14256/it

We’re now ready to create our container on ACI. The command to use (after installing Azure CLI) is the following:

$imageName = "mcr.microsoft.com/dynamicsnav:10.0.17763.973-generic";
$resourceGroup = "d365bcacirg";
$location = "westeurope"
$containerName = "d365bcaci"
$dnsName = "d365bcaci.westeurope.azurecontainer.io"
$artifactUrl = Get-BCArtifactUrl -version 16.2 -country it -select Latest
az group create --name $resourceGroup --location $location
az container create -g $resourceGroup -n $containerName --image $imageName --os-type Windows --cpu 2 --memory 16 --ip-address public -e artifactUrl=$artifactUrl ACCEPT_EULA=Y USESSL=N ClickOnce=Y
publicDnsName=$dnsName --dns-name-label $containerName `
--ports 80 7046 7047 7048 7049 8080

where the artifactUrl parameter is passed as an environment variable.

Wait some minutes (at least 15/20 minutes usually) and your container is created on Azure Container Instances:

Please remember that when the ACI instance is provisioned, the Dynamics 365 Business Central instance is not immediately available:

If you inspect the container’s log with the following command:

az container logs --resource-group $resourceGroup --name $containerName

you will see that the instance creation requires a bit of extra time (downloading and unpacking application and platform artifacts, copying installation files, installing components and so on).

When the instance is available, the container’s log shows you the credentials and the public URL of your container and you can start using it:

When using ACI, remember that Azure Container Instances compute, memory, and storage resources availability differs per Azure region. Please always check the following link to see the limitations and to avoid errors on creation:

https://docs.microsoft.com/en-us/azure/container-instances/container-instances-region-availability

As an example, if you want to create a Dynamics 365 Business Central container on ACI with 64 GB of RAM and Windows Server 2019, this is not supported and you can receive an error like:

The requested resource with ‘x’ CPU and ‘y.z’ GB memory is not available in the location ‘example region’ at this moment. Please retry with a different resource request or in another location.

When using ACI instead of a classic Docker installation (local on on Azure VM)? When you quicky need to deploy a container available everywhere and without provisioning things and this container has a short life (few hours/days). I don’t recommend ACI for long running containers because it could cost you a lot.

Last thing: I think you will never have this “problem”, but in my real scenario here I had an Azure Function that returned the artifact url to use for spinning up containers on ACI automatically when needed. There was a moment where this function returned a BLANK artifact url. In this case, the container was created correctly on ACI, but if inspecting the log the result was this:

You must share a DVD folder to C:\NAVDVD or a file system to C:\NAVFS in order to run the generic image

If you have this error, please check your artifact url (thanks Freddy).

Enjoy Dynamics 365 Business Central on ACI 😉

6 Comments

  1. Great article! Thanks for sharing. I’m new to ACI. I noticed after stopping the container (to save on cost) and then restarting the container, it created a new instance of BC, not keeping the previous instance like it does in Docker Desktop on my local machine. Is there a way to make it persist the environment?

    Like

    1. Yes, I was attempting to follow your guidance above. Here’s my script:
      az login
      az account set –subscription “MySub”
      $imageName = “mcr.microsoft.com/businesscentral:10.0.14393.2906”
      $resourceGroup = “demo”
      $location = “EastUS”
      $containerName = “d365bcdemo02”
      $dnsName = “d365bcdemo02.eastus.azurecontainer.io”
      $artifactUrl = Get-BCArtifactUrl -type sandbox -country us -select Latest

      az container create -g $resourceGroup -n $containerName –image $imageName –os-type Windows –cpu 2 –memory 8 –ip-address public -e artifactUrl=$artifactUrl ACCEPT_EULA=Y USESSL=Y ClickOnce=Y publicDnsName=$dnsName –dns-name-label $containerName –ports 80 7046 7047 7048 7049 8080

      Maybe I have the wrong expectation. Should I be able to stop/start my container instance and have it persist the data in the environment?

      Like

  2. @B Man @LT if you want the data to persist you can always connect to an external database instead of the one inside the container (-e databaseServer=xxx -e databaseName=xxx …)

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.