In this demonstration, I want to show you how to use linked templates. That's how you can separate resources into separate template files to make management easier and to reuse resources and deployments. This is a little bit of a contrived example but what I'm going to do is separate out the app plan resource from the app service deployment. 

First of all, create a new file that I will save as appsplandeploy.json and start with the ARM template boilerplate structure. Then move the plan name parameter along with the plan resource from the existing template file to the new one. 

In the appsplandeploy template, I will need to define an output parameter that will pass the planname to the parent or calling template. That output parameter will be the plan name and will be of type String and the value is simply going to be the parameter planname that is being passed in. 

I'm going to create a new file for my web app deployment called websitedeploy. This will be the parent or master template. It will just be the content from the original template, so yes I could have just renamed the file.

We can see here that we already have some issues with our missing parameter and service plan, so I will need to add a link to the appsplandeploy template, and I will do that by creating a nested resource. 

While link and nested might not be intuitive, I guess that is exactly what we are doing; we are nesting this linked resource within our main resource template. One thing to be aware of is that the template file cannot be accessed locally, you must have that file accessible by HTTP, which means storing it somewhere on the Internet, and in my case, I've created container storage where I will upload that template file to. I'll just upload that file to my storage container templates inside the howarmtemplate storage account. I'll grab the link to the file and I will paste it into the URI property of the template link section. Obviously the other issue we need to address is the now redundant planname parameter and we do that by using a reference function to reference the output value from our linked template. So the reference name is the name of my linked template resource. I'll just change the name of that resource from nested deployment to linkedTemplate. 

We reference our outputs with the word outputs, then it picks up the name of the output, which is  planname, and then we want to use the keyword value to get its value.

We no longer need the dependsOn section, so I will get rid of that. Another thing you need to be aware of is that the reference function does not work as a parameter within another function, that is, you cannot nest it with another function. Replacing the planname parameters within the linked template reference inside the concat function will throw a template error.

One thing I forgot to mention was that in the app service plan template as it is being linked from our website deploy template we will not be prompted for our plan name parameter. Just for the purposes of demonstration, and it is definitely not best practice, I will use the default parameter to specify a plan name. Later on we will look at a much better option. I'll just save appsplandeploy and refresh it to my blob storage. Before we continue I'll demonstrate how that reference function within the concat function will give an invalid template error by running a Test-Az- ResourceGroupDeployment. Here we have the invalid template error's telling us there is a problem at line 30 column 9 and the function reference is not expected at this location. Line 30 column 9 isn't really accurate but the closest reference we have to that is within the tags property, but I know this to be the case and I will change it and we will retest. Having changed that tag property it passes the test deployment so I can now deploy for real using the new-azresourcegroupdeployment command. Going back to the portal and into deployments of the resource group, we can see the link template and the website deploy are both in action. If we go and have a look at the link template deployment and in outputs we can see the plan name output value and obviously that is also the input for the website deploy deployment.

Let’s recap what’s gone on here. We started with a resource template that had an app service plan and a website. Then we took the app service plan and we put it in another template file; this is called a linked or nested template. The app service plan template file is linked to the master template using a deployments resource. Values are passed from the master into the linked template with parameters, and values generated in the linked template can be passed back to the master with outputs. Input parameters take the same format as we’ve already seen, while outputs are analogous to return values of a programming function. Linked or nested templates must be stored on-line and referenced with a URL. Template deployments can be tested with the Azure CLI test-azresourcegroupdeployment command, taking the resource group and template file as parameters. Once successfully tested a template can be deployed to Azure with the new-azresourcegroupdeployment command.