Azure Resource Manager
The course is part of these learning pathsSee 4 more
The Azure cloud is a collection of resources that work in unison to deliver a product or a service. Hardware is virtual and services can be created and destroyed at the stroke of a key. In the context of DevOps, resources can be "spun up" as part of a pipeline. It is crucial that when resources are deployed multiple times, those deployments are consistent, repeatable, and can be automated. Doing it manually through the Azure portal isn’t practical. Azure Resource Manager (ARM) has an interface for processing resource templates that specify resource deployments.
In this course, we look at how those templates can be built and deployed. We start with a simple template and move on to more complex examples to illustrate many of the useful features available when deploying resources with templates. This course contains plenty of demonstrations from the Azure platform so you can see exactly how to use Azure Resource Manager in practice.
If you have any feedback on this course, please reach out to us at firstname.lastname@example.org.
- Understand what Azure Resource Manager (ARM) is and its use cases
- Learn about the different ARM templates available and how they can be used
- Deploy databases using an ARM template
- Export a template and create templates using QuickStart templates
- Deploy resources using a script
This is a beginner-level course aimed at anyone who wants to learn more about managing and configuring their Azure environment, and fast-tracking their deployments.
To get the most out of this course, you should have a basic understanding of the Azure platform.
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.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.