Deploy your environments in the click of a button with Azure Blueprints

If you’re going to be working with Azure you’re going to be working with cloud environments. And probably not just one environment. Maybe you need one for development, one for testing and one for production. Maintaining these environments can turn into a painful process.

Wouldn’t it be nice if you could spin up an environment you trust in the click of a button, and only when you actually need it? Let’s look at how Azure Blueprints can make your life easier.

The target audience of this article is anyone who is new to Azure, but also for those who have more experience. It will introduce you to Azure Blueprints and show you one of the ways you can use Infrastructure as Code along with Azure. After reading this article you’re ready to start building your own blueprints.

So first of all, what are Azure Blueprints?

Think of Azure Blueprints as you would of a blueprint of a building: A set of drawings that define the specifications needed to construct the building. In the same way, an Azure blueprint is a set of files that define the specifications needed to construct the cloud environment.

An Azure Blueprint consists of two main components: A blueprint file and artifacts, both written in JSON. Artifacts can be cloud resources, role assignments, and policy assignments. This way you can control who’s got access to your environment and at the same time enforce policies that ensure your environments comply with any regulations you might need to follow.

The structure of the blueprint needs to be as follows, where the blueprint file is at the root of the directory, with the artifacts in an artifact folder.

Let’s look at a very simple blueprint to see what I’m really rambling about. We’re going to see how a web app can be deployed into Azure by using Azure Blueprints. For simplicity, I’m leaving out role assignments and policy assignments.

To create a web app in Azure we need to provision two resources:

• An app service plan
• A web app

The app service plan takes care of stuff like the amount of computing power we want for our web app. I’ve created the app service plan and web app as separate artifacts:

The web app is declared as follows:

Artifacts are declarative representations of azure resources. Here are a few things worth noticing:

• Everything inside of “template”:{} is actually just an ARM-template.
• The section with “parameters”:{} at the bottom are blueprint level parameters that come from the blueprint file.
• “resourceGroup” tells the blueprint where to logically put the web app. The resource group name is a placeholder name that is defined in the blueprint file.
• The “dependsOn”:[]-section tells the blueprint what other artifacts need to be created before this one. In this case, the app service plan must be created before the web app. Just referencing the name of the artifact JSON file does the trick.

The famous blueprint file that I’m talking so much about looks like this:

As you can see the blueprint file defines blueprint properties, such as parameters and resource groups that can be referenced in other artifacts.

Great! We got all the files we need for our blueprint, but how does this turn into actual stuff in Azure? It can be done in several ways, for instance in the Azure portal or by using the Azure API, but we’re going to be super “DevOpsy” and use Powershell.

Let’s create and publish the blueprint to Azure.

The command “Import-AzBlueprintWithArtifact” imports the blueprint files and creates the blueprint. Now it is going to exist in Azure, only in draft mode. The next step is to publish it, which is what the last line “Publish-AzBlueprint” does. In the portal it looks like this:

The blueprint is created and published, but to actually get our web app we need to assign the blueprint, which is just a fancy way of saying we’re deploying it.

When assigning the blueprint we can set our blueprint parameters during runtime, which can be useful when running the script in some CI/CD orchestration tool. I’m adding a suffix to the blueprint parameters so that I’m getting my “DEV”-environment. After the command “New-AzBlueprintAssignment” is run, the blueprint will be deployed.

And there we go, we have ourselves a web app, which we can tear down and redeploy at will! I know there’s a lot of magic going on here, but that’s kind of the whole point. We only need to declare our files, tell Azure this is the environment we want and we don’t care how it’s created.