ARM

How to make developing Bicep and ARM deployment scripts easier using Docker and VS Code remote Docker extension

Project Bicep is a new Microsoft DSL for deploying resources in Azure, built on top of ARM tempalets

If you’ve been to any cloud or devops conference or meetup in the last year, you’ve probably heard about Terraform, the Infrastructure as Code tool from Hashicorp, it’s been one of the big talking points of the devops community for some time now. Terraform is a proprietary language for creating infrastructure as code deployment solutions, and one of it’s biggest selling points is that it supports multiple different cloud vendors including Azure.

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build Initially this might seem like a bit of an odd topic, “Build” in a software development process usually refers to the process of compiling an application and preparing it for distribution (creating MSI files etc.). Whilst we are writing infrastructure as code, there’s no compilation involved, no creating of installers, so what are we doing here?

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build In part 1 of this series we took our first step in building an Infrastructure as code pipeline by moving our infrastructure files into source control. Now that we have this code in a central repository we can use this as a base for the next steps in this process.

Role Based Access Control is Azure’s method for setting permissions on resources to control who can manage and administer these resources. Each type of Azure resource has a number of permissions that can be set on it, and these permissions can be grouped into roles that can be applied to users or groups of users to grant rights to manage resources. Out of the box Azure comes with a large number of pre-defined roles for common workloads.

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build Defining Infrastructure as Code is becoming prevalent in all areas of IT, but none more so than in the cloud. Be this Azure Resource Manager Templates, AWS Cloudformation or third party tools like Terraform. Once you’ve gone down this route, you open up the ability to treat your infrastructure code like any other code, and because it’s just code you can now leverage some of the tools developers have been using for years in their software lifecycle.

Back in June Microsoft introduced the ability to have an ARM template deploy to more than one resource group, at Ignite this year they went a step further to allow cross subscription deployments. It is now possible to have a single deployment create resources in multiple resource groups, regions and subscriptions, which is really useful if you are trying to deploy environments that include separate DR locations, or deployments that impact both a client and a core set of infrastructure.

Virtual Machines in a Scale Set provide a great way to spin up many identical machines in parralell. Thes VMs are all based on a common VM image and so unless all you need on your VMs is Windows, you are going to need to load applicaitons and data into these VMs. Getting your applications into that image can be done one of two ways: Use a Gallery image for your scale set and apply your applications on each VM when it is deployed using something like the PowerShell DSC extension, or Chef/Puppet etc.

A while back I wrote an article talking about the new “Condition” option in Azure Resource Manger (ARM) templates. This was the first step into conditional logic in ARM templates and worked great where you needed to apply a condition at the resource level. Where it fell down was where you needed a condition inside a resource, this resulted in you having to duplicate objects with different settings and work around issues like duplicate naming.