PowerShell DSC Extension in Azure Resource Manager - PowerShell Method

Here are the steps I took to get the PowerShell DSC Extension for Azure Virtual Machines working using the PowerShell publishing method. In another post, I'll go through the JSON template method.

First, create an Azure VM using whichever method you prefer. I used the portal for simplicity. Most of my settings won't affect this, but for completeness, the settings I used for my VM are as follows:

Image: Windows Server 2016 Datacenter
Deployment Model: Resource Manager
Name: MyCoolVM
Disk Type: HDD
User name: Dave
Password: hunter2
Resource Group (New): DSC-Test-Resources
Location: North Europe
Size: A1 Basic
Settings Tab: All defaults except monitoring disabled.
Storage Account Name: dsctestresourcesdisks871

After creation, I opened the VM's network security group and added an inbound rule to allow port 80. I also added a DNS alias to the machine's public IP.

Once the VM is set up, open a text editor and create the following example DSC file:

In the same folder, make a deployment script as follows: 



The first command will publish the DSC configuration into a Zip file in your Azure storage account and return a predictable URL. The resulting blob will not be public.

Mine ended up here, but you can see the format which appears to use the normal blob URI and the powershell-dsc container:
https://dsctestresourcesdisks871.blob.core.windows.net/windows-powershell-dsc/dsc-webserver.ps1.zip

A few seconds after the second command executes, you can see the new extension in your VM in the portal.

The status will move from (unavailable), to Transitioning, to Provisioning succeeded (or failed.)

If you click the extension you can get more details on the process, you can view the entire log from this blade.

And here is the finished web server:

Start to finish, including manual creation of the VM, this process took about 20 minutes.

If you use additional non-standard DSC resources, the PowerShell publish command will include the modules in the uploaded Zip file which is super handy.

References:
Introduction to the Azure Desired State Configuration extension handler

Azure Resource Manager (ARM) Templates Getting Started Guide

Preface
I've been doing some research and development work on ARM templates recently and thought I would put together a getting started guide while I was at it.

There are some great online references for ARM template creation:

• Official Microsoft Documentation
• Azure QuickStart Template Gallery
• QuickStart Templates on GitHub
• Microsoft Resource Manager Template Walkthrough

Getting Started

The basics

ARM templates are JSON formatted files that describe Azure Resources. You can send the file off to Azure in a number of ways and the resources described will be implemented by the Service. ARM resources are deployed in parallel, so even complicated templates can be deployed quickly.

The ARM template is broken down into four sections: Parameters, Variables, Resources and Outputs. Only one section is actually required to have content - resources - the others help to make the templates more dynamic and flexible.

I use Visual Studio Code for creating and editing ARM templates as it has some excellent plugins which provide intellisense when creating resources. Using this means that you can just hit Ctrl+Space to get a hint at the possible resource properties on the fly. To set up VS Code for intellisense, the official guide is here.

You can also download templates from the Azure Portal to edit later. You can download templates from created resources, from the last page of the resource creation process, or even from entire resource groups.

Here is a really basic, valid ARM template to create a Storage Account. It's pretty rigid in that the storage account name is hard-coded, to fix that, parameters can be used to take user input.



Execution

ARM templates can be deployed in a number of ways: PowerShell, X-plat CLI and the Azure Portal are some common ways.

The following PowerShell code will create a Resource Group and deploy the template into it.

Taking input

The parameters section allows the template to take input. This input can be from the user at deployment time, from a parameters answer file or from another template. A basic parameter looks like this:

Storing Variables and Transforming input

The variables section is useful for holding regularly used values or for transforming input. For example in some of my templates, I use a resources prefix which is concatenated with resource names so that related resources can be seen at a glance.

The example includes a variable to apply a tag to a resource. In this example there is only a single resource, but in more complicated templates, the variable can be reused in all of the resources.

Producing Output

It can be useful to produce outputs from a template to get information on the resources that were created. In this example the DNS name assigned to the public IP is returned after deployment. Outputs can also be used in chained templates.

Creating multiple copies of a resource

A really powerful feature of ARM templates is the copy loop. This means you can create multiple, identical copies of specific resources in your template. For example you can create 3 copies of a VM using one code block. When you use a copy loop, you can reference the copyIndex() function in order to generate unique names for resources. In the following example, there is a simple copy loop to generate 3 public IPs. 

Using arrays in loops

Arrays can be combined with the copy loop in order to name resources with a list of predefined or runtime input names. In the example, the array is generated as a parameter and then indexed using the copyIndex() function. The count of the copy property can be set to the length of the array so that all array elements are indexed dynamically.

Running scripts in VMs using the extension resource

A nice part of Azure Resource Manager is the ability to add virtual machine extensions. One such extension is the script extension which allows the Resource Manager service to run scripts inside a virtual machine. No external access is required to the virtual machine since Azure executes the script for you. Scripts need to be hosted on an accessible web server or storage account. If there is any sensitive information in the script you should use storage keys and a key vault to access the script privately from the template. The following example just runs a publicly accessible script in the virtual machine 'myVirtualMachine'.

Linking to other templates for complex solutions

Chaining templates is super useful for creating complex solutions. For instance you can create a template to build an availability group of VMs, then call that template from another template with the copy loop and parameters to build multi-tier applications. 

I have a full implementation of this on my GitHub, the implementation will loop through several templates and create multiple availability groups and VMs. Be careful if you run this as it will spawn a lot of resources.

Here is the 'master' template which calls the other templates in the solution:

And here are all the resources it creates!

Azure Resource Manager Load Balancer setup with Terraform

In previous posts, I showed how to configure the basics for using Terraform on Azure Resource Manager and also how to set up WinRM over HTTPS for configuring the servers once built,

In this post I take the configuration a step further and create a Load Balancer with an Availability Set. I use the load balancer public IP to NAT into the VMs using WinRM to execute a Powershell DSC script to install the IIS feature.

Here is a sample of the NAT rule used:


The VM and it's components use the 'count' property in Terraform in order to build multiple VMs of the same configuration. Whenever the VM's individual properties are required ${count.index} can be used to reference the specific object within the configuration. In the above gist, I use "${count.index + 10000}" to assign a unique WinRM port on the load balancer for each VM.

The configuration of the load balancer requires a field in the NIC for each VM which adds it into the load balancer's back end network.


Within the load balancer file there are configurations for it's public IP, front and back-end of the load balancer, a couple of rules for web traffic and a probe to check which machines are functional. Here is a the load balancer configuration:


The full source for this can be downloaded from GitHub here.