The first step of this project was to help the federal client provision their own Azure Government subscription, with some assistance from Microsoft. We then wanted to document the client’s on-premises environment so that it could be accurately replicated within Azure. The next step was to actually build and deploy the Azure services and scripts in the cloud environment. Lastly, we wanted to be able to define and implement automation use cases, such as the provisioning of an entire sandbox, or just specific machines within that sandbox.
After investigating the client’s on-premises environment, we were able to quickly develop a solution and implement it within Azure. The base sandbox consists of a virtual network, with three different subnets; two for AD virtual machines, and one for application workloads. Each sandbox has four pre-configured virtual machines used for an Active Directory forest. There is also a storage account that holds the VHDs used to image the virtual machines.
The backbone of the automation portion of the solution leverages Azure’s Automation service. This service provides hosted PowerShell execution with PowerShell runbooks, and essentially abstracts the underlying VM infrastructure needed to execute these scripts. We wrote several PowerShell runbooks for the client which leveraged the Azure service management cmdlets. The main one automatically builds a sandbox, and another removes all of the Azure objects created for the sandbox, in reverse order. If a client wants to spin up a sandbox, all they have to do is log in to the Azure portal and execute the provisioning runbook with the click of a button.
The steps involved in creating the sandbox are broken up into individual scripts, which are run in succession by the main provisioning script:
1. Initialize Automation Environment
The initialize script is what connects the automation environment to the correct Azure subscription in order to provision the entire sandbox. The Azure subscription information is stored in the automation environment, so there is no need for the user to enter a username or password.
2. Configure Virtual Network
Now we can build out the virtual network that all virtual machines within the sandbox will be connected to. First, we get the custom network configuration template from a shared storage account inside the Azure subscription – an xml snippet that describes the new VNET to be added. Then we edit the existing network configuration XML for the subscription by inserting the new VNET details snippet. If there is no existing configuration for the subscription, we also append the additional required XML. The resultant subscription network configuration file is then reapplied to the subscription, creating the new VNET and associated subnets.
3. Provision Sandbox Storage Account
Now we are able to create a storage account for the sandbox, identified by the unique sandbox number. Then a container is created inside the storage account. This will hold the image VHDs for the sandbox virtual machines.
4. Create Image Disks
Since we now have a storage account, we can take image disks from the base storage account and copy them over to the sandbox storage account into the VHDs container. This includes both the OS Disk as well as any needed data disks.
5. Create VM Images
With the image disks in place, we can create the VM images based on the image disks copied over from the previous script. These images will be used to create the virtual machines within the sandbox.
6. Provision and Image Virtual Machines
The final script provisions the virtual machines based on the images created by the previous script. It creates four machines, two attached to each of the pre-configured subnets.
After a short amount of time to let the scripts run to completion, the client is left with a sandbox that is immediately configured and ready for their developers to use. A diagram of the Azure environment is shown below.