As you work more with Azure Resource Templates you will find that you need to pass information from one resource you have created into another. This is fine if you had the information to begin with within your variables and parameters, but what if it’s something you cannot know before deploy, such as the dynamic IP address of your new VM, or the FQDN of your new public IP address for your service?
The answer is to use References to access properties of other resources within your template. However, if you need to get information between templates then you also need to look at outputs.
A crucial tool in this process is the Azure Resource Explorer (also now available within the Azure Portal – click Browse and look for Resource Explorer) because most often you will need to look at the JSON for your provisioned resource in order to find the specific property you seek.
In the JSON below I am passing the value of the current IP address of the NIC attached to a virtual machine into a nested template as a parameter.
“ipAddress”: { “value”: “[reference(concat(parameters(’envPrefix’),parameters(‘vmName’),’nic’)).ipConfigurations[0].properties.privateIPAddress]” }
The markup looks complex but isn’t really. The concat bit is building the name of the resource, which I do based on parameters within the resource template. Basically, you specify reference in the same way as you would variable or parameter. You then need to provide the name of the resource you want to reference (the concat markup here, but it could just be ‘mynic’) and then the property you want, using dot notation to work your way down the object tree.
I’ve used the example above for a reason because it covers all the bases you might hit:
- When you look at the JSON for the deployed resource you will see a properties section (just as you do in your template). You don’t need to include this in your reference (i.e. mynic., not mynic.properties.).
- My nic can have multiple IP assignments – ipConfigurations is an array – so I am using [0] to look in the first item in that array.
- Within the ipConfiguration is another properties object. This time I need to include it in the markup.
- Within the properties of the ipConfiguration is an attribute called privateIPAddress, so I specify this.
It is important to remember that I can only use reference to access resources defined within my current template.
So what if I want to pass a value back out of my current template to the one I called it with? That’s what the Outputs section of my template is for, and by and large everything in there will be a reference to a property of a resource the current template has deployed. In the code below I am passing the same IP address back out of my template:
“outputs”: { “ipAddress”: { “value”: “[reference(concat(parameters(’envPrefix’),parameters(‘vmName’),’nic’)).ipConfigurations[0].properties.privateIPAddress]”, “type”: “string” } }
Within my parent template I access that output by using the reference keyword again, this time referencing an output from the template resource. In the example below I am passing the IP address from my domain controller template into another nested deployment that will reconfigure my virtual network.
“parameters”: { “VirtualNetwork”: { “value”: “[variables(‘VirtualNetwork’)]” }, “DNSaddress”: { “value”: “[reference(‘DomainController’).outputs.ipAddress.value]” } }
Note that this markup requires me to specify .value on the end of the reference to pass the information correctly.
References and outputs are important because they allow you to pass information between resources and nested deployments. They allow you to keep your variable count low and understandable, and your templates small and well defined with nested deployments for complex environments.