Wednesday, August 20, 2014

Using Azure for Training Environments

Many clients are starting to look at cloud providers such as Azure to host dev/test/training environments.  The pros for this are easy to see.  Spin up as many resources as you need, for only the duration that you require, and pay for it as OpEx rather than CapEx.

One good candidate for this type of operation is dynamics AX.   Generally, during any sales/deploy cycle you will fire up many AX vms to show off functionality or train users.  While you can do all of this manually via the management portal, it would be nice to develop an automated way to spin up/down environments to suit your needs.

For the purpose of this post, I am trying to build a set of scripts that will provision AX environments as needed.  These AX environments will be self contained units that only have external access enabled, and cannot talk to each other. 

Step 1:  Get an Image

For partners, Microsoft releases a single-box demo that can be used to show off the features of AX.  This is the image that I want to use.  One way would be to download the image from partner source and then upload it to your Azure subscription following the instructions hereOriginally, I started down this path.  I didn't want to use my personal internet connection (it would have been super slow), so I actually fired up a VM inside of Azure and started downloading.  On the plus side, I was getting 14000 KB/s transfer rate.  On the con side, one of my coworkers suggested I use LCS only after I had finished the download. 

Ultimately, I want to be able to spin up/down environments via automation of some kind.  LCS was good for the initial deploy, but I wanted to take it a step further.  I ended up capturing the disk after it was deployed and then using that as my base image.

One important point to note about the AX demo is that it has AD built in.  When you deploy the VM, however, unless you explicitly set the DNS settings to 127.0.0.1, you will get a public DNS that won't know how to route for contoso.com (or it will, but not to you).

Step 2:  Build a Provisioning Script

When building out a training environment, you will need to provision VMs according to your needs.  In my case, I decided to build a script that could scale up and down my environment as I needed.  Basically, I could pass in to the script the number of VMs that I would require.  Say I wanted 20, and already had 10 built.  It would simply provision 10 more VMs.  Say I wanted to deprovision everything.  I could simply state that I wanted 0 VMs and the script would remove all the VMs currently loaded. 

This is probably overkill for what one would need.  You could write a script that simply destroyed all the VMs with a given prefix in a given service and then recreate the exact number you wanted.  Oh well...

Some solution notes:
  • Script relies on VMs being prefixed with a particular string that identifies them as AX training VMs
  • Script assumes that you have already loaded an image file and have the name for that image handy
  • Script attempts to set the DNS for the servers to 127.0.0.1
  • Script is NOT production ready.  There are some bugs (which you will probably notice if you use it) so use it as a conceptual reference only
The script can be found here.  It is called Provision-AxTrainingLab.ps1

Step 3:  Manage the state of the provisioned VMs

As shown in a  previous post, you can build scripts inside of Azure Automation to start up and shut down your lab as needed.  You can schedule this, or run it manually via command line for an on-demand type experience.

Of course this idea can scale to any type of training environment.  That is the beauty of code!