A frequently asked question about rolling out Azure VNet with different subnets in a infrastructure as code environment is where and how to define the subnets in your Azure ARM template. In the most examples online the number of subnets is configured in the template and the name and addressPrefix is configured in the parameter file. The big disadvantage with this scenario is that when you deploy a VNet with for example two subnets and later you decide to add more subnets you have two choices both of which are uncomfortable for an Infrastructure as code release pipeline.
Below the choices you have with the accompanying disadvantages:

1. First you can change the template file and include the new subnets in the template and redeploy your template. The disadvantage of this solution is that in an enterprise environment with multiple VNet’s with different subnet configuration you need to create and maintenance multiple template that serve the same purpose.
2. Second option is to add the new subnets with a separate template file to your existing VNet, however the disadvantage of this solution is that when you redeploy the first template all the other subnets that are not configured within will be deleted because they are not configured in the template (that’s how arm works right :p)

Azure ARM

So, before we jump in code let’s see how Azure ARM works and why this situation happens. We know that an VNet is defined as a resource whiten Azure ARM and Each resource provider offers a set of resources and operations for working with an Azure service and that Subnet is a child resource of Azure VNet. To get a list of the resource types of Azure VNet you can run the following PowerShell command:

(Get-AzureRmResourceProvider -ProviderNamespace Microsoft.network).ResourceTypes.ResourceTypeName

Which will return all the resource types with in Microsoft.Network resource provider, this list includes some of the resources listed below:

• virtualNetworks
• publicIPAddresses
• networkInterfaces
• loadBalancers
• networkSecurityGroups
• applicationSecurityGroups

However, subnet is not an independent resource like a Network Interface or an publicIPAddresses it is the property of a VNet and it only exists in a VNet. And with that said we can also understand why Incremental and complete deployments mode doesn’t work for subnets. The primary difference between these two modes is how Resource Manager handles existing resources in the resource group that are not in the template:

• In complete mode, Resource Manager deletes resources that exist in the resource group but are not specified in the template.
• In incremental mode, Resource Manager leaves unchanged resources that exist in the resource group but are not specified in the template.

If the resource already exists in the resource group and its settings are unchanged, the operation results in no change. If you change the settings for a resource, the resource is provisioned with those new settings.

Now that we understand the underlying structure of Azure ARM and Resources its time to take a look at some code and the differences within.

Most common scenario

First lets start with the most common scenario for configuring the subnets within a JSON template as below in which you define each subnet specifically. In this scenario the amount of the subnets is defined in the template and the subnet name and address prefix is defined trough the parameter file. This is an example of an VNet with static amount of subnets, if you want to add subnets to the VNet you have the choice of changing the template or adding the subnets trough a separate template file (see above for more information).

{
  "name": "[parameters('VNetName')]",
  "type": "Microsoft.Network/virtualNetworks",
  "location": "[resourceGroup().location]",
  "apiVersion": "2016-03-30",
  "dependsOn": [],
  "tags": {
    "displayName": "[parameters('VNetName')]"
  },
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "[parameters('VNetPrefix')]"
      ]
    },
    "subnets": [
      {
        "name": "[parameters('Subnet1Name')]",
        "properties": {
          "addressPrefix": "[parameters('Subnet1Prefix')]"
        }
      },
      {
        "name": "[parameters('Subnet2Name')]",
        "properties": {
          "addressPrefix": "[parameters('Subnet2Prefix')]"
        }
      }
    ]
  }
}

Desired scenario

In the example below I have replaced the above with Property iteration.
To create multiple values for a property on a resource, I have added a copy array in the properties element. This array contains objects, and each object has the following properties:

• name – the name of the property to create multiple values for
• count – the number of values to create
• input – an object that contains the values to assign to the property

I am also using the length function on the array to specify the count for iterations, and copyIndex to retrieve the current index in the array.
The following example shows how to apply copy to the subnet property on a VNet:

{
  "name": "[parameters('vNetName')]",
  "type": "Microsoft.Network/virtualNetworks",
  "location": "[resourceGroup().location]",
  "apiVersion": "2017-10-01",
  "tags": {
    "displayName": "[parameters('vNetName')]"
  },
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "[parameters('vNetPrefix')]"
      ]
    },
    "copy": [
      {
        "name": "subnets",
        "count": "[length(parameters('subnets'))]",
        "input": {
          "name": "[parameters('subnets')[copyIndex('subnets')].name]",
          "properties": {
            "addressPrefix": "[parameters('subnets')[copyIndex('subnets')].addressPrefix]"
          }
        }
      }
    ]
  }
}

As you can see I have configured one subnet in this VNet template, but based on the content from the parameter it can deploy one or 10 subnets. The above solution give’s you the possibility to configure in your parameter file the amount of subnets you want to deploy. This way you are always redeploying one template with different parameter files. And when you want to add or remove a subnets you only need to change your parameter file.

Example of the parameter file:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "vNetName": {
      "value": "Vnet01"
    },
    "vNetPrefix": {
      "value": "10.0.0.0/16"
    },
    "subnets": {
      "value": [
        {
          "name": "Subnet-1",
          "addressPrefix": "10.0.1.0/24"
        },
        {
          "name": "Subnet-2",
          "addressPrefix": "10.0.2.0/24"
        },
        {
          "name": "Subnet-3",
          "addressPrefix": "10.0.3.0/24"
        },
        {
          "name": "Subnet-4",
          "addressPrefix": "10.0.4.0/24"
        },
        {
          "name": "Subnet-5",
          "addressPrefix": "10.0.5.0/24"
        }
      ]
    }
  }
}

As you can see this way you can easily create a default VNet template and based on the properties in your parameter  file you will get another result. For an infrastructure as code environment with CI/CD mindset this is a huge requirement because you want to define you Release pipeline once and reuse it for different deployments without editing the template fie or your release pipeline.

In the next post I will explain how you can achieve the same working method for OMS and other Azure Resource.