Azure, Azure Resource Manager, Azure Stack
Leave a comment

Building Azure Resource Manager Templates – Defining Resource Dependencies

We will continue learning about building ARM templates by looking at how we can define dependencies between resources. To recap, here is the scenario we are working on.

demoIn the earlier parts of this series, we created the storage account, virtual network, a public IP, a load balancer, and added all inbound NAT rules required for the virtual machine RDP access. If you notice, we have components that depend on others. For example, the inbound NAT rules depend on the load balancer. Similarly, VMs depend on network interfaces which in turn depend on the virtual network. In the absence of dependencies, ARM will attempt to deploy these resources in parallel which may result in errors. So, within the resource template, we need to define these dependencies so that ARM can make decisions about the deployment sequence. There are multiple ways of doing this.

Using DependsOn

If you have noticed in the earlier parts of this series, we have used DependsOn property within the resource element.

If you look at line number 11, we added DependsOn property to define that the inboundNatRules depend on the load balancer configuration. This is straightforward and very easy to define. You can use template language functions such as ResourceId() or concat() as well within the value of DependsOn and dynamically build these dependencies. You can provide more than one value here as a comma-separated list.

Using References

The second method is to define reference to the dependent resource. Let us create a virtual network interface the AD VM in our scenario. This depends on the virtual network resource that we already created.

Observe line number 9. We used the reference() function to get a reference to the virtual network object we created and get the subnet name from there and use it to construct the IPConfiguration name. When ARM engine finds this reference, it creates an implicit dependency on the virtual network that we referenced. There is no need here to specify DependsOn property.

Note that we cannot use the reference() function as a part of the resource instance name. This is because the ARM engine must know the names of the resource instances before the deployment can start.

Child or Nested Resources

The 3rd way to define dependencies is to use child resources. Let us see an example before we discuss this further.

This example is quite long. It is the virtual machine resource instance that we need for the domain controller. Apart from all the virtual machine properties such as storage profile and OS profile, we have something interesting at line number 61. We have another resources element within the VM resource definition. As with the top-level resources element, this is also a JSON array and contains the resource definition for the VM DSC extension. It is obvious that VM DSC extension without a VM is meaningless. By defining this as a child or nested resource inside the VM resource definition, we are creating an implicit dependency between the VM and the VM DSC extension. When ARM engine looks at this in the template, it schedules VM creation before the DSC extension. BTW, this VM DSC extension has the DSC configuration required to build the domain controller in this deployment.

Always make sure you that you create enough flexibility within the template for someone else to take this and deploy the template in their own environment.To this extent, I have used a parameter called assetLocation (line 75) in the DSC extension properties. You can call this whatever you want. This parameter specifies where all the template assets such as DSC configuration scripts and any additional template files are stored.

So far in this part, we have seen three different ways of defining dependencies between resources. If you check the template that we built so far for this scenario, you will observe that I have added a few more variables and parameters needed for the DC VM and its configuration.

Go ahead and deploy this.

In the next part, we will look at the nested template deployments.

Filed under: Azure, Azure Resource Manager, Azure Stack


Ravikanth is a principal engineer and the lead architect for Microsoft and VMware virtualized and hybrid cloud solutions within the Infrastructure Solutions Group at Dell EMC. He is a multi-year recipient of Microsoft Most Valuable Professional (MVP) award in Windows PowerShell (CDM) and Microsoft Azure. Ravikanth is the author of Windows PowerShell Desired State Configuration Revealed (Apress) and leads Bangalore PowerShell and Bangalore IT Pro user groups. He can be seen speaking regularly at local user group events and conferences in India and abroad.