More about Infrastructure as Code Azure
- Ansible & Azure: Automating Azure’s Basic Building Blocks
- Azure Resource Manager Templates: A Guide to Efficient Automation
- Terraform on Azure: Platform-Agnostic Automation in the Cloud
- Azure Resource Manager (ARM) Benefits and Best Practices
- Azure Quickstart Templates How-To
- Infrastructure as Code: Azure Tips to Save You Time and Headaches
Azure Resource Manager templates enable teams to standardize the management of Infrastructure as Code (IaC). ARM template documents are written in JSON, using declarative syntax to define how infrastructure resources should be configured, deployed, and managed. Teams can use ARM templates to collaborate more efficiently and automate their processes.
In this article, you will learn:
- What ARM templates are
- How to create ARM templates
- Tips for optimizing ARM templates
- Azure Resource Manager templates with Cloud Volumes ONTAP
What Are Azure Resource Manager Templates?
Why use ARM templates?
Using ARM templates and an IaC model enables you to manage infrastructure resources with the same tools and methods as any other codebase. You can leverage version control and automate deployments easily and consistently. In particular, ARM templates can provide the following benefits:
- Declarative syntax—enables you to define infrastructure in human-readable terms. This reduces the chance of misconfigurations and enables you to use Azure Resource Manager templates as documentation for your infrastructure.
- Orchestration—Resource Manager intelligently manages the deployment of related resources to ensure assets are deployed in order. It also prioritizes parallel deployments when possible to ensure faster implementation.
- Modular files—enables you to segment and nest templates with reusable components. This reduces the total number of files needed, speeds definitions, and helps ensure standardization.
- Preview changes—Azure templates include a what-if operator that you can use to preview changes before deployment. This enables you to verify how templates affect your current configurations and to ensure that templates are correctly defined.
- Built-in validation—Azure templates are automatically validated before deployment to ensure success. This prevents templates from partially deploying resources.
Creating Your First ARM Template
When getting started with Azure Resource Manager templates you may want to build a few sample templates before deploying. Below you can see the process for building these templates.
Before you can get started, there are a few tools you need.
- JSON Editor—you can use any editor that supports JSON files. If you do not already have an editor, consider using Visual Studio Code, which offers an extension with tools for Resource Manager.
- Command-line interface—Azure JSON templates are deployed with a CLI. You can use either the Azure CLI or Azure Powershell for this, just make sure to use the latest version.
Create Your First Template
With the above tools, you’re ready to create your first template. Create a blank text file with a .JSON extension. Copy-paste the following code to your file. This will create a blank Azure Resource Manager template (a template that does not perform any automated actions, just for showing the correct format).
In this code, three elements appear in every template you’ll create:
- $schema—defines where your JSON schema file is stored. This file describes which properties are used in a template (i.e. what can be defined in the template). Schema files are defined by Azure.
- contentVersion—a version number, defined by you, to help you manage Azure Resource Manager templates. Version numbers here work the same as versioning any other code. It is your responsibility to ensure that numbers are used in sequence and sensibly.
- apiProfile—when you specify an API profile version and don't specify an API version for the resource type, Resource Manager uses the API version for that resource type that is defined in the profile.
- resources—the area where you define what resources you want to deploy or modify.
- outputs—the values that are returned after deployment.
4 Ways to Up Your ARM Template Game
After you’re familiar with creating and applying ARM templates there are a few tips you can incorporate into your process.1. Create separate ARM templates for different services
Try to keep your templates modular. Similar to using microservices, breaking Azure Resource Manager templates into components makes it easier to manage and update your files. It also enables you to more easily reuse template definitions in other deployments, ensuring consistent configurations. For example, if you are defining a deployment that uses app services, queue resources, and databases you can create a different template for each type.
When using modular templates, ARM enables you to link templates together. This ensures that deployments are performed in the correct order and that no elements are missed while still allowing you to work in sections. Linked templates can help you avoid the creation of monolithic deployments without adding manual steps.2. ARM templates generated from existing Azure resources
When you create Azure resources manually, ARM templates are automatically created. When creating a new template, it is recommended to take a look at these existing templates, to verify your definitions are correct.
To view templates for existing resources you can go to the Azure Portal, select the resource you want to view, and select Export template from the blade menu. From there you can view the JSON document, or see the format used in PowerShell, Azure CLI, or .NET.3. Copy functionality
If you need to create near-duplicate resources, you can use the copy element in the resources section of your ARM template. This creates one of more copies of the requested resources, eliminating the need to manually copy/paste definitions. The code looks like this:
With this functionality or in place of it, you may also want to leverage dynamic properties. These properties enable you to use parameters, variables, or output values to define resources according to programmatically defined conditions.4. Remember the location of DependsOn
DependsOn is an element you can use to define resources that are dependent on other resources. This ensures that resources are linked together after creation and defines the order of creation even if templates are applied simultaneously.
This element is used internally in Azure Resource Manager templates and cannot be used with linked templates. When defining DependsOn, you need to add it in order, with the dependent resource defined after the resource it relies on. This is also best practice for ensuring that your documentation and logic are clear.
To learn more about Azure templates, check out our article about Azure Quickstart templates, which explains how to use Quickstart templates to make cloud storage easier.
Azure Resource Manager with Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP supports up to a capacity of 368TB, and supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
In particular, Cloud Volumes ONTAP provides Cloud Manager, a UI and APIs for management, automation and orchestration, supporting hybrid & multi-cloud architectures, and letting you treat pools of storage as one more element in your Infrastructure as Code setup.
Cloud Manager is completely API driven and is highly geared towards automating cloud operations. Cloud Volumes ONTAP and Cloud Manager deployment through infrastructure- as- code automation helps to address the DevOps challenges faced by organizations when it comes to configuring enterprise cloud storage solutions. When implementing infrastructure as code, Cloud Volumes ONTAP and Cloud Manager go hand in hand with Azure Resource Manager to achieve the level of efficiency expected in large scale cloud storage deployment in Azure.