Automate, automate and automate!
Working with Azure can initially be daunting, and the best way to become familiar is to jump in and start deploying resources using the Azure Portal (https://portal.azure.com). You can do most tasks via the Portal including deploying and configuring resources, configuring monitoring for your applications to configuration of auto-scale and backups.
One of the key benefits of Azure is the ability to automate almost every task, with automation often exposing configuration settings not available when working in the Portal.
Automate with ARM templates
The key automation method, and the one used at Strategic Cloud Solutions for all of our customer deployments, are Azure Resource Manager (ARM) templates. These are JSON files that describe a resource that you would like to deploy to Azure, without needing to worry about the how – Azure takes care of this for you. A simple example would be the creation of a Virtual Machine (VM) – in the template you would specify configuration settings such as VM size, number of disks, and Operating System but you wouldn’t specify details relating to the deployment of these, or the ‘how’.
One of the main benefits that ARM templates bring is the ability to deploy any resources defined within multiple times, but with distinct parameter values in order to create unique resources within Azure (VM1, VM2, VM3 as examples). This allows reusability and removes the need to maintain multiple ARM templates for the same type of resource. – this is achieved through the use of Parameters and Parameter files.
Within the ARM template, parameters can be defined (along with a default value if no value is provided at deployment time) and used within the resource definition to designate where a particular value should be set at deployment time. Parameter files can accompany ARM templates and provide the values that are to be used to deploy the resource defined within the ARM template.
Example ARM template containing a Storage Account resource
Automate with PowerShell
PowerShell is a versatile scripting language that allows you to perform many deployment and management tasks in Azure (the PowerShell Az modules must be installed), and with the introduction of PowerShell Core 6 you can now use PowerShell on many platforms including Windows, macOS and Linux.
PowerShell helps to fill the gaps in scenarios where ARM templates are not best suited or unable to fulfil the requirements. An example is when deploying storage accounts – a Microsoft recommendation is to prefix the storage account name with a random 3 digit prefix (we’ll go into the why in a subsequent post – a link will be provided here when its live). ARM templates are not suited for creating this random 3 digit prefix, however this is simple with PowerShell. Generate the prefix, and then call New-AzResourceGroupDeployment, passing in the template path and parameters.
Important Considerations
ARM templates are idempotent, meaning that each and every time you perform a deployment using a template, along with the same parameters, it will result in the same resource deployed in Azure. This also means that if the resource already exists in Azure, an incremental deployment (by default) will occur and deploy ‘over’ the existing resource – this can be problematic, lets look at an example of why and how you can avoid issues using best practices:
You deploy a Virtual Machine to Azure. After testing you identify that you need to increase the size of the Virtual Machine from a DS2_v3 to DS4_v3 to handle your applications workload. You perform this change via the Azure Portal.
A month later you redeploy the Virtual Machine, as part of a larger infrastructure deployment, using the ARM template and parameters you used previously. This subsequently and unexpectedly resizes the Virtual Machine back to DS2_v3, causing issues with your applications performance and causing an outage for your customers.
This change in VM size occurred due to the fact that any change in configuration made using the Portal or PowerShell will be reverted to match those that are defined within the ARM template.
A best practice when working with ARM templates is to ensure you only ever deploy your resources using them, and where configuration changes have to be made in the Portal or via PowerShell (you’ve got a production outage that must be fixed) ensure you bring these configuration changes into your ARM templates or modify any parameter values as required.