ARM templates comprise all the resources that you intend to deploy. This template will be injected as a single deployment to the resource, regardless of the number of resources that you have mentioned inside the template. As mentioned in the terminologies earlier, an ARM template is a JSON document that is written in a declarative syntax. This declarative syntax is what powers the declarative automation. Declarative automation refers to the automated deployment of resources that you define without the need to worry about how they will be deployed. The “how” part is the liability of the Azure Resource Manager, and it will make sure that whatever resources you requested are indeed deployed.
Before you start writing a template, it’s good that you take a look at the template design approaches. The following are some approaches that are commonly taken by administrators to design templates. Nevertheless, you always have the liberty to design in your own style and define your resources as required.
Template Design
For explaining the template design, let’s take a three-tier application that consists of an Azure virtual machine that serves a front end, Azure App Service that acts as a business logic, and finally a SQL database that will be the datastore for the whole solution. The end user will be interacting with the front end, and input from the user will be evaluated by the business logic, which will be written to the database.
The first approach here is to include all the resources that you need in a single template, as shown in Figure 8.2, and deploy to the resource group as a single operation. In the template itself, you can give the reference of the SQL database to the Azure App Service for them to communicate with each other.
FIGURE 8.2 Single template approach
The second approach is that you don’t have to define the entire infrastructure in a single template file. If you have multiple resources, it makes total sense to break down your template into different templates targeting individual resources. Remember how we used to write programs? We used to define classes in different files and then call them in the main file as required. You will take a similar approach here. There will be a parent template or a master template that links to the individual templates. Figure 8.3 shows how the master template and individual templates are deployed to the resource group.
Let’s say you have different lifecycles for your application tiers; then you may need to associate them to different resource groups. In the last two approaches, you were deploying the resources to a single resource group. However, in this approach, you will be writing a separate template for individual tiers targeting different resource groups. As you already know, a resource group is a logical group and will not hinder the communication between the tiers. These tiers can still interact with each other, though they are deployed to different resource groups. Figure 8.4 shows the pictorial representation of this approach.
As mentioned in the opening, the aforementioned are some of the common approaches. Nevertheless, an alternate approach can be taken per your requirements. Now, you will learn the structure of the ARM template and the relevance of each section.
FIGURE 8.3 Nested template approach