This is fundamentally different to the imperative form of PowerShell or Bash scripts, that tell the ARM layer exactly what to do. With the declarative form the ARM layer will interpret the template and the current configuration of resources within the resource group and will then make the required additions or modifications.
Objective: To show an illustration of the core content/sections of an ARM template
Notes:
This simply shows the bare-bones key sections that each ARM template contains
The key sections are :
Schema – location of the schema file that describes the template language
ContentVersion – Version of the template instance.
Parameters – these are values that provided when deployment is executed in order to customize the deployment
Variables – these are computed elements (often composed from Parameters) that can be reused by name throughout the template
Resources – the definitions of the actual resources being deployed (or updated)
Outputs – Values returned after deployment
Parameter Best Practices:
If possible, try to always provide Default Values
Provide metadata to clearly indicate what the parameter is used for
Provide complete descriptive names, no matter how long
Use Pascal Casing to name your parameters (i.e. the First letter should be a small letter). Then every new word will have the first letter as a capital. Also, do not include spaces between words (i.e. windowsOSVersion)
Use properties like minLength and allowedValues to impose restrictions, as this will help to reduce human error
Variable Best Practices:
Provide complete descriptive names, no matter how long.
Use Pascal Casing to name your parameters (i.e. the First letter should be a small letter). Then every new word will have the first letter as a capital. Also, do not include spaces between words (i.e. storageAccountName)
Use constructs to dynamically generate variables, as this will reduce human error
If you have a field or property that is used more than once, and does not require input from the end-user, create a variable for it. This will minimize the number of places you need to update/change the value throughout your template as you iterate
Points to Note:
The dependencies between resources are evaluated and resources are deployed in their dependent order. When resources are not dependent on each other, they are attempted to be deployed in parallel.
When developing an ARM template for a Production-ready environment, strive to have more tag options available at creation time.
Always test your ARM templates prior to deploying.
There is a cmdlet that you can use to do this: Test-AzureRmResourceGroupDeployment -ResourceGroupName TestResourceGroup01 -TemplateFile <PathToJsonTemplate>
As a best practice, do not store sensitive information in the parameters file (i.e. the Local Admin password). Either provide it dynamically via inline parameters, or use and reference Azure Key Vault
This is useful when using Nested Templates, to pass Resource IDs/Names back to a Master template.
Demo #1 (Simple Template):
Show the Simple - Azure Storage Account.json file
Demo #2 (Gallery):
URL: https://azure.microsoft.com/en-us/resources/templates/
Search for: 2 VMs in VNET - Internal Load Balancer and LB rules
Demo #3 (Template Extraction):
Navigate to the Azure Portal > Resource Groups > AdinErmieWebsiteRG > Settings: Automation Script (may take a minute to load)
I’m calling out tagging because I see this missing in a lot of environments, and it’s a lot of work to go back and apply tagging after deployment
It’s a huge help with trying to breakdown billing information