Chapter 6. Azure Resource Manager

Most days, you want to spend as little time as possible on how you deploy an application environment, and get on with the actual deployment. In many IT environments, there’s a move toward development and operations teams that collaborate and work closely together, with the DevOps buzzword thrown around a lot at conferences and in blogs.

There’s nothing inherently new or groundbreaking about the DevOps culture, but often different teams didn’t work together as they should. Modern tools have spurred the DevOps movement, with continuous integration and continuous delivery (CI/CD) solutions that can automate the entire deployment of application environments based on a single code check-in by a developer. The operations team is usually the one that builds and maintains these CI/CD pipelines, which allows much quicker tests and deployments of application updates for developers.

The Azure Resource Manager deployment model is central to how you build and run resources, even though you probably haven’t realized it yet. Resource Manager is an approach to how to build and deploy resources, as much as the automation processes and templates that drive those deployments. In this chapter, you learn how to use Resource Manager features such as access controls and locks, consistent template deployments, and automated multi-tier roll-outs.

6.1. The Azure Resource Manager approach

When you created a VM or web app in previous chapters, a resource group was first created as the core construct to hold all of your resources. A resource group is central to all resources: a VM, web app, virtual network, or storage table can’t exist outside of a resource group. But the resource group is more than just a place to organize your resources—a lot more. Let’s look at what the underlying Azure Resource Manager model is and why it’s important as you build and run applications.

6.1.1. Designing around the application lifecycle

Hopefully, you won’t build an application and then never maintain it. There are usually updates to develop and deploy, new packages to install, new VMs to add, and additional web app deployment slots to create. You may need to make changes to the virtual network settings and IP addresses. Remember how I mentioned in previous chapters that your virtual networks in Azure may be managed by a different team? You need to start to think about how you run on a large, global scale, and in terms of the application lifecycle and management.

There are a couple of main approaches for grouping resources in Azure:

• All resources for a given application in the same resource group—As shown in figure 6.1, this approach works well for smaller applications or development and test environments. If you don’t need to share large networking spaces and can individually manage storage, you can create all the resources in one place, and then manage updates and configuration changes in one operation.

  Figure 6.1. One way to build an application in Azure is for all the resources related to that application deployment to be created in the same resource group and managed as one entity.

  

• Like-minded resources grouped by function in the same resource group. As shown in figure 6.2, this approach is often more common in larger applications and environments. Your application may exist in a resource group with only the VMs and supporting application components. Virtual network resources and IP addresses may exist in a different resource group, secured and managed by a different group of engineers.

Figure 6.2. An alternate approach is to create and group resources based on their role. A common example is that all core network resources are in a separate resource group than the core application compute resources. The VMs in the compute resource group can access the network resources in the separate group, but the two sets of resources can be managed and secured independently.

Why the different approaches? The answer isn’t all down to job security and those lovely silos some teams like to work in. It’s more about how you need to manage the underlying resources. In smaller environments and applications where all the resources exist in the same resource group, you’re responsible for everything in that environment. This approach is also well-suited to development and test environments where everything is packaged together. Any changes you make to the virtual network only impact your application and resource group.

The reality is that networks don’t change often. The address ranges are often well defined and planned so they can coexist across Azure and office locations around the world. Logically, it often makes sense to place the network components in their own resource group. The network is managed separately from the application. Storage may be managed and updated separately in the same way. There’s nothing inherently wrong with the division of resources like this, as long as the IT staff doesn’t get stuck in a silo mentality, resulting in a lack of cooperation.

For your applications, the division of resources can also be a benefit in that you’re largely free to make the changes and updates as you wish. Precisely because you don’t have the network components in your resource group, you don’t need to worry about them when you make application updates.

6.1.2. Securing and controlling resources

Each resource can have different security permissions applied to it. These policies define who can do what. Think about it—do you want an intern restarting your web app or deleting the VM data disks? And do you think your good buddies over in the network team want you to create a new virtual network subnet? Probably not.

In Azure, there are four core roles you can assign to resources, much like file permissions:

• Owner—Complete control. Basically, an administrator.
• Contributor—Able to fully manage the resource, except making changes to the security and role assignments.
• Reader—Can view all information about the resource, but make no changes.
• User access administrator—Able to assign or remove access to resources.

Role-based access control (RBAC) is a core feature of Azure resources and automatically integrates with the user accounts across your subscriptions. Think of file permissions on your normal computer. The basic file permissions are read, write, and execute. When combined, you can create different sets of permissions for each user or group on your computer. As you work with network file shares, permissions are a common occurrence to control access. RBAC in Azure works along the same lines to control access to resources, just like file permissions on your local computer or network share; see figure 6.3.

Figure 6.3. The access control for each Azure resource lists what the current assignments are. You can add assignments, or select Roles to see information about what permission sets are available.

As you explore the available roles, you may notice several resource-specific roles. These include the following:

• Virtual Machine Contributor
• Website Contributor
• Network Contributor

Can you guess what those roles mean? They take the core platform Contributor role and apply it to a specific resource type. The use case here goes back to that concept of how you manage like-minded resources. You might be assigned the Virtual Machine Contributor or Website Contributor role. Any VMs or web apps created in that resource group would then be available for you to manage. But you couldn’t manage network resources, which may be in a different resource group entirely.

6.1.3. Protecting resources with locks

The permissions-based approach of RBAC is great to limit who can access what. But mistakes can still happen. There’s a reason you typically don’t log on to a server as a user with administrative, or root, permissions. One wrong keystroke or mouse click, and you could mistakenly delete resources. Even if you have backups (you do have backups, right? And you test them regularly?), it’s a time-consuming process that may mean lost productivity or revenue to the business. In chapter 13, you’ll learn more about the ways the Azure Backup, Recovery, and Replication services protect your data.

Another feature built in to the Resource Manager model is resource locks. Each resource can have a lock applied that limits it to read-only access or prevents delete operations. The delete lock is particularly helpful, because it can be all too easy to delete the wrong resource group. Once you start a delete operation, there’s no going back or canceling the operation after the Azure platform has accepted your request.

For production workloads, I suggest you implement locks on your core resources to prevent deletes. This is only at the Azure resource and platform levels, not for the data within your resources. For example, you could delete files within a VM or drop a table in a database. The Azure resource locks would apply only if you tried to delete the entire VM or Azure SQL database. The first time a lock kicks in and prevents the wrong resource group from being deleted, you’ll thank me!

Figure 6.4. Create a resource lock in the Azure portal.

1.  Open the Azure portal in a web browser, and then select any resource group you have, such as cloud-shell-storage. Choose Locks at left in the portal.

2.  Enter a Lock Name, such as Protect, and then select Delete from the Lock Type drop-down menu. Choose OK, and your new lock appears in the list.

3.  Select Overview for the resource group, and then try to delete the resource group. You need to enter the resource group name to confirm that you wish to delete it (which is also a good mental prompt to make sure you have the right resource to delete!).

4.  When you choose the Delete button, review the error message that’s displayed to see how your lock prevented Azure from deleting the resource.

6.1.4. Managing and grouping resources with tags

One final feature in the Azure Resource Manager model that I want to bring up are tags. There’s nothing new or special about how you tag resources in Azure, but this is often an overlooked management concept. You can apply tags to a resource in Azure that describes properties such as the application it’s part of, the department responsible for it, or whether it’s a development or production resource.

You can then target resources based on tags to apply locks or RBAC roles, or report on resource costs and consumption. Tags aren’t unique to a resource group and can be reused across your subscription. Up to 15 tags can be applied to a single resource, so there’s a lot of flexibility in how you tag and then filter tagged resources.

1.  Open the Azure portal in a web browser, and then select any resource, such as cloud-shell-storage. Choose the Tags button, as shown in figure 6.5.

Figure 6.5. You can create up to 15 name:value tags for each Azure resource.

2.  Enter a Name, such as workload, and a Value, such as development.

3.  Select Save, and then open the Cloud Shell.

4.  To filter resources based on tags, use az resource list with the --tag parameter. Use your own name and value as follows:

az resource list --tag workload=development

6.2. Azure Resource Manager templates

So far, you’ve created a small number of Azure resources at a time. To do this, you’ve used the Azure portal or Azure CLI. Although I haven’t shown you Azure PowerShell, I did talk about it in the first chapter, and it’s available in the Cloud Shell. Maybe you’ve tried it without me. That’s okay, I don’t feel left out! As I mentioned in chapter 1, Azure has tools that let you choose what’s most comfortable for you and the environment you work in.

The downside of using the portal or CLI or PowerShell commands is that you must click a bunch of buttons in the web browser or type out lines of commands to build your application environment. You could create scripts to do all this, but you then must build logic to handle how to create multiple resources at the same time, or what order to create resources in.

A script that wraps Azure CLI or PowerShell commands starts to move in the right direction in terms of how you should build and deploy application environments—not just in Azure, but across any platform. There’s a move toward infrastructure as code (IaC), which is nothing new if you’ve been around IT for a while. All it means is that you don’t rely on a human to type commands and follow a set of steps; rather, you programmatically create your infrastructure from a set of instructions. Manual deployments introduce a human element that can often lead to minor misconfigurations and differences in the final VMs, as shown in figure 6.6.

Figure 6.6. Humans make mistakes, such as mistyping a command or skipping a step in a deployment. You can end up with slightly different VMs at the end of the output. Automation is often used to remove the human operator from the equation and instead create consistent, identical deployments every time.

Even with scripts, you still need someone to write them, maintain them, and keep them updated as new versions of the Azure CLI or PowerShell modules are released. Yes, there are sometimes breaking changes in the tools to accommodate new features, although they’re rare.

6.2.1. Creating and using templates

Resource Manager templates can help reduce human error and reliance on manually written scripts. Templates are written in JSON, an open and cross-platform approach that allows editing them in a basic text editor. With templates, you can create consistent, reproducible deployments that minimize errors. Another built-in feature of templates is that the platform understands dependencies and can create resources in parallel where possible to speed up deployment time. For example, if you create three VMs, there’s no need to wait for the first VM to finish deploying before you create the second. Resource Manager can create all three VMs as the same time.

As an example of dependencies, if you create a virtual NIC, you need to connect it to a subnet. Logically, the subnet must exist before you can create the virtual NIC. And the subnet must be part of a virtual network, so that network must be created before the subnet. Figure 6.7 shows the chain of dependencies in action. If you try to write a script yourself, you must carefully plan the order in which resources are created, and even then, you must build in logic to know when the parent resources are ready and you can move on to the dependent resources.

Figure 6.7. Azure Resource Manager handles dependencies for you. The platform knows the order in which to create resources and has awareness of the state of each resource without the use of handwritten logic and loops like those you must use in your own scripts.

Want to know something cool? You’ve already used Resource Manager templates, all the way back in chapter 2 and the very first VM you created. As you create a VM in the portal or the Azure CLI, under the hood a template is programmatically created and deployed. Why? Well, why reinvent the wheel and go through the process of building all that logic for the deployments? Let Azure Resource Manager do it for you!

Let’s see what a section of a Resource Manager template looks like. The following listing shows the section that creates a public IP address, just as you did in earlier examples when you created a VM.

Listing 6.1. Creating a public IP address in a Resource Manager template

{
      "apiVersion": "2017-04-01",
      "type": "Microsoft.Network/publicIPAddresses",
      "name": "publicip",
      "location": "eastus",
      "properties": {
        "publicIPAllocationMethod": "dynamic",
        "dnsSettings": {
          "domainNameLabel": "azuremol"
    }
  }
},

Even if JSON is new to you, it’s written in a (somewhat) human-readable format. You define a resource type—in this example, Microsoft.Network/publicIPAddresses. You then provide a name, such as publicip, and a location, such as eastus. Finally, you define the allocation method, dynamic in this example, and a DNS name label, like azuremol. These are the same parameters you provided when you used the Azure portal or CLI. If you use PowerShell, guess what? You’re prompted for the same parameters.

The difference with the template is that you didn’t have to enter any information. It was all included in the code. “Great,” you might be thinking, “but what if I want to use different names each time?” Same as with a script, you can dynamically assign them using parameters and variables:

• Parameters are values that you’re prompted for. They’re often used for user credentials, the VM name, and the DNS name label.
• Variables can be preassigned a value, but they’re also adjusted each time you deploy the template, such as the VM size or virtual network name.

6.2.2. Creating multiples of a resource type

As you build your templates, try to think ahead about how you may need to grow your applications in the future. You may only need a single VM when you first deploy your application, but as demand for the application grows, you may need to create additional instances.

In a traditional scripted deployment, you create a for or while loop to create multiple resource types. Resource Manager has this functionality built in! There are more than 50 types of functions in Resource Manager, just like in most programming and scripting languages. Common Resource Manager functions include length, equals, or, and trim. You control the number of instances to create with the copy function.

When you use the copy function, Resource Manager creates the number of resources you specify. Each time Resource Manager iterates over the create operation, a numerical value is available for you to name resources in a sequential fashion. You access this value with the copyIndex() function. Let’s discuss the previous example to create a public IP address, only this time, let’s create two addresses. You use copy to define how many addresses you want to create and copyIndex() to name the addresses sequentially.

Listing 6.2. Creating multiple public IP addresses with copy

{
      "apiVersion": "2017-04-01",
      "type": "Microsoft.Network/publicIPAddresses",
      "name": "[concat('publicip', copyIndex())]",
      "copy": {
        "count": 2
      }
      "location": "eastus",
      "properties": {
        "publicIPAllocationMethod": "dynamic",
      }
},

You also use the concat function to combine the public IP address name and the numerical value of each instance you create. After this template is deployed, your two public IP addresses will be called publicip0 and publicip1. Not super descriptive, but this basic example shows the concept of how you can use a numbering convention as you create multiple resources with the copy function.

6.2.3. Tools to build your own templates

So, I’ll confess. As much as Resource Manager templates are neat and one of the main ways I suggest you build and deploy applications in Azure, you still need to write the templates. There are a couple of different tools that simplify this for you, and hundreds of sample templates are available from Microsoft and third parties. In fact, one of the best ways to learn how to create and use templates is to examine the quickstart templates Microsoft makes available in its samples repo at https://github.com/Azure/azure-quickstart-templates.

If you want to roll up your sleeves and start to write you own templates, there are two main tools I recommend. The first is Visual Studio Code, a free, open source, multiplatform editor (https://code.visualstudio.com). Along with some built-in functionality such as source control and GitHub integration, extensions are available that can automatically build the different sections, or providers, for the resources to build up a template as shown in figure 6.8. If you download and install VS Code, go to View > Extensions, and then search for Azure.

Figure 6.8. Many extensions are available in Visual Studio Code to improve and streamline how you create and use Azure Resource Manager templates.

A more graphical way to build Azure Resource Manager templates is to use the full Visual Studio editor, as shown in figure 6.9. There are versions for both Windows and macOS, but you need a separate license to use it. A Community Edition is available, but take care if you build templates within your company. You typically need a more licensed version, so consult your license experts, because Visual Studio is targeted at application developers.

Figure 6.9. With Visual Studio, you can graphically build templates and explore JSON resources.

You can, of course, use a basic text editor. Part of the reason Azure Resource Manager templates are written in JSON is that it removes the need for any special tools. There’s a learning curve to working with JSON, which is why I recommend that you explore the quickstart templates on the Azure samples repo. Take care with indentation, trailing commas, and the use of parenthesis, brackets, and braces!

6.2.4. Storing and using templates

So, you love the idea of Azure Resource Manager templates, and you’ve installed Visual Studio or Code to write your own templates. How do you store and deploy them? In the end-of-chapter lab, you deploy a template from the Azure samples repository on GitHub. This is a public repository, and you may not want to make your application templates available to the entire world.

There are a couple of common scenarios to store Resource Manager templates privately:

• Use a private repository or network file share within your organization.
• Use Azure Storage to centrally store and secure templates for deployment.

There’s no right or wrong way to store and deploy templates. You have flexibility to use whatever processes and tools are already in place. The advantage of using a repository is that you typically have some form of version control so you can ensure consistent deployments and review the history of your templates if needed. The only limitation is that when you deploy the template, you need to provide the appropriate credentials to access the shared location. This authentication process can vary, such as providing a username or access token as part of the URL to a template in a repository, or providing a shared access signature (SAS) token if you use Azure Storage.

Public repositories such as GitHub can also be a great way to learn and share. I do suggest that you keep your production templates stored privately, but if you create a neat template for a lab environment or to try out some new features, sharing it on GitHub gives a little something back to the IT community and may help others who want to do the same deployments that you do. And as you begin to build your own templates, be sure to check out what templates already exist so that you don’t start from scratch and reinvent the wheel every time!

6.3. Lab: Deploying Azure resources from a template

All this theory around deployment models and approaches is great, but you’ll (hopefully!) start to see the benefits and efficiency when you use templates for real:

1.  Go to the Azure quickstart samples on GitHub (https://github.com/Azure/azure-quickstart-templates), and find one that interests you. A good place to start is a simple Linux or Windows VM.

2.  Built into the GitHub samples are buttons to deploy straight to Azure. Once you find a template you like, select Deploy to Azure, as shown in figure 6.10, and follow the steps in the portal. It’s much the same as when you created a VM earlier in the book, but there are only a few prompts to complete the required parameters. All the other resources are created for you and abstracted away.

Figure 6.10. For each Resource Manager template in the GitHub sample repo, there’s a Deploy to Azure button. If you select this button, the Azure portal loads, and the template is loaded. You’re prompted for some basic parameters, and the rest of the deployment is handled by the template.

3.  The final step to deploy your template is to accept the license agreement shown, and then choose Purchase. You’re creating Azure resources when you deploy a template, so Purchase means you agree to pay for the costs of those Azure resources.

One of the basic templates, such as a simple Linux or Windows VM, costs about the same as any other VM you’ve created so far. Make sure you delete the resource group after your deployment has finished, just like cleaning up after any other exercise.

Parameters in templates

As discussed in section 6.2.1, you can use parameters and variables in your templates. Remember, parameters are values that you’re prompted for, and variables are dynamic values that can be applied throughout a template. The values you’re prompted for (parameters) vary from template to template. So, depending on which quickstart template you select, you may be prompted for one or two values, or you may have to provide seven or eight.

As you design your templates, try to anticipate how you and other users may want to reuse the template as you deploy applications. You can provide a default value and limit what values are allowed. Take care with these default and allowable values, or you may constrain users too much and force them to create their own templates. Where possible, try to build reusable core templates that have enough flexibility.

4.  Once your template has deployed, go back to GitHub and examine the azuredeploy.json file. This file is the Azure Resource Manager template that was used to create and deploy the sample. See if you can understand the different resource types and configurations that are applied. As you work with more Azure resource types and templates, the JSON format will become easier to understand, honest!