In this movie Sharon discusses Azure templates and the advantages to using templates for our Azure deployments. The components of the templates are also explained.
- [Instructor] Azure Templates is another one of those features in Azure that is awesome when you know about it. In my previous Azure courses, I have been showing you how to create resources in Azure, using the portal, which is okay, but templates will make everything so much easier. There are several benefits to using Azure templates. You can deploy multiple resources at one time, meaning you can provision an entire environment with one script. You can ensure the same build is provisioned, time after time after time.
There are several methods that you can use to deploy templates within Azure. The first, is actually using the template within Azure itself. For those of you who are comfortable in PowerShell, you can use PowerShell scripting to deploy your templates. The Command Line Interface or CLI, is also supported. As is REST APIs. You can also deploy templates directly from GitHub and your own repository if you wish. When you deploy your templates in Azure, you'll have the option to choose, a complete update or an incremental update.
A complete update will delete all the resources in the resource group that are not identified in that template. Therefore, if you have let's say a virtual machine in the resource group and that virtual machine is not specified in the template, that virtual machine will be deleted. Any resources that are in the template, but are not in the resource group will be created. And finally, any resources in the template that have updated settings will be updated in the resource group as well.
And keep in mind with the complete update, if the resource has the same settings, it is not reprovised. Next we have the incremental update. Again for our add, resources identified in the template, but do not exist in the resource group are created. Resources that have updated settings in the template will be reprovised to your resource group as well. And resources in the resource group are not deleted, if that resource is not in the template.
Going back to our previous example, if you have a virtual machine in your resource group, but that virtual machine is not identified in that template, in this case, that virtual machine will be left alone. You will be using the same format for all of your template JSON files. Basically we'll start off with a curly bracket, we'll have our schema. This schema is what we are using today, being early March 2017. Next you'll have the content version, the parameters, the variables, resources and outputs.
And then you'll close that off with another curly bracket. Let's explore these in a little bit more detail. The scheme defines a location of the JSON schema. And again, as I've already mentioned, as of today use the one that we have outlined here. And is this a required parameter? Yes, it is. You must always include this in your template files. Let's look at content version. This is the template version, this is for your tracking. It is not used by Azure. So this defines your source control.
And is it required? Yes, it is. Even though it is not used by Azure, it is required. Next we have parameters. Parameters are the values that you will use for customized deployment. Such as location, name and properties. If you did not specify specific parameters for the deployment, the same resources would be deployed with the same properties, every time you deploy that template. And parameters are not required in your JSON file.
An example for our JSON file would be our environment name, we are allowing for a string and we can control what the user will select by specifying allowed values. In our example here, we can have a development or a production environment, and then you close it off. Next we have our variables. Variables allow you to specify one value that will be used in all instances within that template. Such as for your networks or your virtual machines.
I like to use variables to define as much as I can within the script. It's just so much easier than re-typing that same variable name over and over and over again. And these variables are not required. Let's take a look at variables. In our example here, we have a virtual network prefix, a virtual network subnet name, and a virtual network subnet prefix. In the template, we would call the variable itself and the associated values would be plugged in for us.
We also have resources. These define the resources that are to be deployed and it is required. I'm going to look at a quick example of resources. In this case, our resource will be our virtual networks. We can also pull off the parameter, as well as the virtual network subnet name from the variables. And finally outputs. Outputs specify what is to be returned and then you can put this value to another command if you wish. They are not required.
I know this looks a little scary initially, but trust me it is not that hard and I'll be showing you how easy it is to use existing templates and customize them for your needs.
- Implementing Azure Resource Manager templates
- Creating a template from a deployment
- Deploying a template using the portal
- Deploying a template using PowerShell
- Using Azure Quickstart Templates
- Using service principals
- Locking Azure resources
- Securing Azure subscriptions
- Azure active directory roles
- Designing custom RBAC roles