Deconstructing JSON: Storage Wars

The last place I left off with my deconstruction of JSON, I had deployed a basic network as the basis for my future home for some virtual machines.  The next key dependency for Virtual Machine is storage.  In this case, I’ll need a storage group in the same regional location (and ideally in the same resource group) as my network.

For the sake experimentation, this template example creates two different storage accounts and takes advantage of both parameters and variables to determine the location and the storage account name.

The default parameters set the storage account as “wrongnamestor” and the location in the East US. These settings will apply to the first instance of the storage account resource.  In the variable section, the storage account name is set as “labweststor2” with a location in the West US region.

 {
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   
   "parameters": {
    "newStorageAccountName": {
      "type": "string",
      "defaultValue": "wrongnamestor",
      "metadata": {
        "description": "Unique DNS Name for the Storage Account where the Virtual Machine's disks will be placed."
      }
    },
   
    "location": {
      "type": "string",
      "defaultValue": "East US",
      "allowedValues": [
        "West US",
        "East US"
      ],
      "metadata": {
        "description": "Restricts choices to where premium storage is located in the US."
      }
    }
   },
      
   "variables": {
       "location": "West US",
       "newStorageAccountName": "labweststor2"
           
    },
   
   "resources": [ 
     {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "[parameters('newStorageAccountName')]",
      "apiVersion": "2015-06-15",
      "location": "[parameters('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
     },
  
      {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "[variables('newStorageAccountName')]",
      "apiVersion": "2015-06-15",
      "location": "[variables('location')]",
      "properties": {
        "accountType": "Standard_LRS"
      }
     }   
   
    ]
}

Because I would probably like both my storage accounts to be in the same region with similar naming, I’ve also created the additional parameters file named “azuredeploy.parameters.json”.  This short file will override the default parameters in the deployment template and set the desired storage account name of “labweststor1” in the West US.

 {
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "newStorageAccountName": {
      "value": "labweststor1"
     },
    "location": {
      "value": "West US"
    }

  }
}

I’ll deploy this template using the following PowerShell:

 New-AzureRmResourceGroupDeployment -ResourceGroupName 'BigLab' -TemplateURI <templateFileURI> -TemplateParameterURI <parameterFileURI> -Verbose 

This line of PowerShell is exactly the same as the line I used to deploy the networking template. The only thing that would need be changed is the actual details of the file location.

As a bonus, the default behavior of Azure Resource Manager deployments is incremental. Since I’m deploying to the same Resource Group that was created with my networking template, the result will be the addition of the two storage accounts to the resource group that contains the network.

If I wanted the template to remove anything not specified, I would have to add the “-mode complete” switch.  Template deployments in the portal only run in incremental mode.

Now that I know my storage template is working as expected, I’ll integrate those resources and parameters into one template as I build out the complete deployment.