Why?
Resource templates are a great concept, but are fraught with danger. Badly named resources and naming inconsistency across resources in different subscriptions can make it difficult to determine purpose.
If a resource such as a Virtual Network or a Storage Account is badly named in a resource template file, you may find that you have to rely on the icon pictures in the Azure portal to indicate what type of resources you are looking at.
What if you need to see at a glance:
- What region the resource belongs to i.e. Australia East or Australia Southeast?
- What environment the resource belongs to i.e. Production or Testing?
- What type of resource it is?
The problem comes from trying to keep the names meaningful and consistent. How do you ensure that your naming standards are adhered to?
Scenario
In my case I would like to name resources as follows:
<Resource Prefix>_<Environment>_<Location> For instance:
"Vnet_Prod_auSoutheast" Solution
Create new parameters (under the parameters section) in the main JSON (AzureDeploy.json) file for:
- Current location (i.e. “Australia East”)
- Short form of the location (i.e. “auEast”)
- Environment (i.e. “Prod” or “Testing”)
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | “location” : { “type” : “string”, “allowedValues” : [“Australia East”, “Australia Southeast”], “metadata” : { “description” : “Deployment location” } }, “shortlocation” : { “type” : “string”, “defaultValue” : “[replace(resourceGroup().location,’australia’,’au’)]”, “metadata” : { “description” : “Short Deployment location” } }, “Environment” : { “type” : “string”, “allowedValues” : [“Prod”, “Testing”], “metadata” : { “description” : “Production or Testing” } |
Create additional parameters (under the parameters section) in the main JSON file to define the naming convention prefixes (In this case for Virtual Networks and Subnets):
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | “VNETNamingStandard” : { “type” : “string”, “defaultValue” : “VNet_”, “metadata” : { “description” : “VNet Naming Standard” } }, “SubnetNamingStandard” : { “type” : “string”, “defaultValue” : “Subnet_”, “metadata” : { “description” : “Subnet Naming Standard” } } |
Use the ‘Concat’ command in the main JSON file (under the parameters section) to create new standardized names by concatenating the prefix, environment and short location :
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | “vnetName” : { “type” : “string”, “defaultValue” : “[concat(parameters(‘VNetNamingStandard’),parameters(‘Environment’),’_’, parameters(‘shortlocation’))]”, “metadata” : { “description” : “VNet name” } }, “SubnetName” : { “type” : “string”, “defaultValue” : “[concat(parameters(‘SubnetNamingStandard’),parameters(‘Environment’),’_’, parameters(‘shortlocation’))]”, “metadata” : { “description” : “Subnet name” } } |
For Storage accounts it’s a little trickier. They have to be lowercase.
| 1 2 3 4 5 6 7 | “StorageName” : { “type” : “string”, “defaultValue” : “[concat(tolower(parameters(‘StorageNamingStandard’)),tolower(parameters(‘Environment’)),tolower(parameters(‘shortlocation’)))]”, “metadata” : { “description” : “Storage Name” } } |
Note: There maybe a better way to make the whole string lower case, I haven’t found it yet!
Parameters JSON file vs Main Deployment JSON file
I advise that the above is placed into the primary azuredeploy.json file. This frees up the Azuredeploy.parameters.json file for items that differ in each deployment i.e. the Address Space for the Virtual Network, different environment etc.
End Note
It is easy to write a basic JSON template for Resource deployments. But it is a task fraught with danger if resources are not systematically named and deployed. Large scale deployments require careful planning.
