In this series so far, we looked at building ARM templates by example. The focus was not really on the resource types or how to use resource definitions. Instead, our focus was on learning the basics of template language. To that extent, we have a scenario that we want to deploy and we are incrementally building the template for it. While building an ARM template for this, we looked at how to use parameters and variables. We looked at using copy object to create multiple instances of a resource type without really writing the resource definition multiple times. We went on to find out how we can define dependencies between different resource types so they are orchestrated in the right order. We looked at how we can decompose the template into purpose-specific external templates and how to link them together. While learning these concepts, we created a template that almost built the scenario we started with. We will now add the remaining VMs based on the environmentType selected by the user. So, based on the VM instance count we need, we …

One of the ARM template authoring best practices is to decompose the JSON template, if applicable, into multiple target-specific templates. Think of this as creating re-usable code. You can leverage the re-usable parts of your code within multiple aspects of your application or the deployment. For linking different external templates within the main template, we need to define the Microsoft.Resources/deployments resource instance. Before we proceed let us look at the scenario for which we are building an ARM template. So far in this series, we have looked at building an ARM template that deploys the following components of this scenario: A storage account A virtual network A public IP address A load balancer Virtual network interfaces for the DC and other VMs based on the environment type. Finally, a VM with DNS and Directory Services running in it. By default, the Azure based IaaS deployments use the Azure DNS. If you have deployed the template that we built in the previous part of this series, you will notice that the virtual network us configured to use Azure DNS. Since we …

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. In 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 …

If you are following this series, by now you know how to use parameters and variables in ARM template language. We used that knowledge to create a template that creates storage account and virtual network. Let us revisit the scenario. In this part, we will extend the template to add publicIP, load balancer, and RDP endpoints for the virtual machines. Before we do that, let us review what we need. To achieve what we want in this, we will use copy object in the template. What is Copy Object? In our template, we already have the storage account and virtual network configuration defined. What we now need is a load balancer with a public IP so that we can access this deployment from the Internet. Also, we need the inbound NAT rules for enabling RDP access to the VMs in this deployment. But before we create the RDP rules for each VM, we need to know how many VM instances we are deploying. As shown in the scenario diagram, we need to be able to deploy …

If you have been following this series on ARM templates, in the last part, we started with a sample scenario that we are using to build an ARM template. Here it is again. In the last part, we completed creation of storage account required for backing the OS and data disks for virtual machines in the deployment. The next step in our scenario is to create the virtual network for the VM connectivity. A virtual network and any subnets required must exist before the creation of virtual machines. So, in today’s article, we will see how we can use variables in the ARM template language while incrementally building an ARM template for our scenario and add virtual network. Towards the end, we will review some best practices guidance with regards to using parameters and variables in developing ARM templates. Working with Variables Variables in ARM template language can be used to simplify the template. For example, in our template, we will be using the subnet name at multiple places. There is no point repeating the same …

In the earlier parts of this series, we briefly looked at different methods of deploying ARM templates and then basics of ARM template language. Starting today’s article, we will see our leaning in action. To get going with our leaning, we will start building the ARM template for the following scenario. We will incrementally build this scenario by learning different aspects of ARM template language. We won’t be covering all resource types in Azure but we will cover every aspect of the ARM template language and functions and expressions used in the template language. We will also review best practices in building these ARM templates as we proceed forward in this series. So, what is there in the scenario that we are building? A resource group to host different resource types in our scenario. A storage account for hosting the VM OS and data disks. A virtual network for VM network connectivity. A public IP to connect to this deployment from external world. A load balancer that has the RDP and PowerShell remoting endpoints for the non-DC virtual …