Mastering Arm Templates, Episode 3: Deployment
When it comes to determining a standard deployment strategy for ARM Templates, there are a number of options, but the goal is to choose a strategy that fits the audience and situation. In certain circumstances, it might make sense to mix and match these options to fit our overall deployment strategy.
To help with this decision, I’ve created a flowchart based on my own experiences and personal opinions.
Resource Groups- Templates are always deployed to a Resource Group, and Resource Groups cannot be created via ARM Templates. This means that the target Resource Group must exist prior to template deployment.
Template Validation- Prior to deploying a template, we can validate the template code to ensure there are no syntax errors or missing values. This is done by default when deploying templates through the Azure portal, but this can also be done via PowerShell.
Deployment Mode- Templates can be deployed in “incremental” or “complete” modes. The default deployment mode is incremental, specifying that the resources deployed to the target Resource Group are incremental changes or additions to the Resource Group. In contrast, when deploying in complete mode, we are specifying that the template deployment is the desired final state for the target Resource Group, and resources that exist in the target Resource Group that are not defined by the template will be removed. Utilizing complete mode should be used only when specifically needed, as this can result in resource loss.
Azure Portal Resource Deployment
One-time ARM Template deployments can be achieved by creating a new “Template deployment” resource within the Portal. It can be a valuable tool if we just want to test something, but prevents us from easily redeploying, reusing, or managing our templates.
Within the “Template deployment,” we can start with a sample or build our own custom template.
Here we can paste in the contents of our template. Generally, this consists of the “azuredeploy.json” contents.
After saving the template, we can input our parameters for the template deployment and then just click “Purchase” to deploy.
For those comfortable with PowerShell, deploying templates via PS scripts is fairly easy and there are some great methods to handle template deployment via PowerShell.
The first option is to utilize the “New-AzureRmResourceGroupDeployment” script, which provides the ability to reference a template and parameters file to be deployed to Azure. We can even append “-Mode (complete or incremental)” to specify our desired deployment mode. In the following example, a mode is not specified, resulting in the use of “incremental” mode.
The previous script is fairly easy to use and doesn’t require much input, but there is another deployment script that provides much more flexibility. Within the “Azure QuickStart Templates” repository, there’s a provided script Deploy-AzureResourceGroup, which will do things like validate the template prior to deployment and create a new Resource Group if the one referenced doesn’t exist.
The “Templates” blade within the Azure Portal is currently a preview feature that provides the ability to store, share, and deploy commonly used templates. This is a great method for easily creating common resources as an alternative to Azure Marketplace resources. For members of the team who aren’t working with ARM Templates on a regular basis but need to deploy a standardized resource, the Templates Blade is a great option. The biggest drawback of this method is the inability to easily nest or reference parameters files.
When creating a new template, a name and description are provided to specify the template’s purpose or additional details.
Now we’ll just paste in the code that’s stored in our “azuredeploy.json” file containing our resource definitions. We’ll click “OK” and “Add”.
The template will show up under the Templates blade and is available for deployment.
At the top of the Template, we’ll click the “Deploy” button.
After clicking “Deploy,” we receive the friendly parameters page that will allow us to input the parameter values for deployment.
Visual Studio can be an extremely powerful tool for handling ARM Templates. We can develop, manage with source control, and deploy our ARM Templates, all within the same tool. The graphical interfaces used during the deployment process can help prevent copy/paste errors that may occur when deploying via PowerShell, and we get the full value of specifying predefined parameter files.
To deploy a template in Visual Studio, we’ll start by creating a new project.
The Azure Resource Group project type can be found under “Visual C#” > “Cloud”. We’ll provide a name for our project and click “OK”.
After creating our new project, a second interface will allow us to choose which template we’d like to start with. In this case, we already have the code we want to use, so we’ll just choose “Blank Template”.
Now, all we have to do is copy our template files into our new Visual Studio project. Once we have the template files added to the project, we can right-click on our Visual Studio project and click “Deploy”, and select “New…”.
The deployment interface allows us to choose the Subscription, Resource Group, and our Template and Parameters file. This is a really nice feature when we have multiple parameters files stored in the project and want to easily select the appropriate parameters file rather than copy/pasting or typing them out into a PowerShell deployment script.
Deploy to Azure
Azuredeploy.net is a great tool to easily deploy ARM Templates from a public GitHub repository to your Azure environment. Azuredeploy.net cannot be used for private GitHub repositories and for this reason, doesn’t make sense for an organization’s use. However, this is a great feature for publicly shared templates, allowing others to easily deploy a template into their own Azure environment. In this case, we can navigate to the Cooper’s Cloud GitHub repository and deploy this N-Tier template into any Azure Subscription with the click of a button.
To add the “Deploy to Azure” button within a public GitHub repository, a README.md file is added to the repository containing the following string:
(This blog post originally appeared on Cooper’s Cloud.)