Let me ask you a question. Would you consider building a house without knowing what it would look like when you're done? The supplies needed? An idea of what is allowed by building and safety codes? I assume the answer to those questions are an emphatic, NO. So why do you build your Azure environments that way?
As a consultant for a managed service provider, producing a consistent, supportable and reproducible environment is a part of my design philosophy. Deviating from my company's design principles and best practices increases support costs and leads to unhappy customers. That's why I'm very interested in technologies that can save me time and effort.
There are many techniques to control the deployment of an Azure environment. Techniques range from the low tech spreadsheet with a checklist of tasks, to the modern infrastructure-as-code technologies like Terraform or Ansible. In my view, checklists are too slow and error-prone, and infrastructure-as-code technologies need too much ramp-up time to be effective for the small Azure environments our customers need. Microsoft might have hit the sweet spot between simplicity and power with Azure Blueprints.
Azure Blueprints is a new service, currently in preview, that helps you define your environment's foundation before you start building your Azure "house". Azure Blueprints use existing Azure services like Azure Policies, permissions and ARM templates to give you control of the rollout of your environment. Let's take a look a the components of an Azure Blueprint.
Azure Blueprints are made up of building blocks called artifacts. Each Artifact is a current Azure service so you are likely already familiar with them.
- ARM Templates - Use your own ARM templates or any of the Azure Quick Start templates
- Resource Groups - Specify the resource groups you want to create
- Roles Assignments - Apply IAM roles to the deployed resource groups to apply permissions to users and/or groups
- Policies Assignments - Apply Azure Policies and/or Initiatives to your environments
Blueprint creation workflow
What does creating a new Blueprint look like? The creation of a Blueprint involves three simple steps:
- Create a draft of your Blueprint - Add Artifacts (ARM templates, Policies, Resource Groups and Roles) into a hierarchy to define your environment. When you add an ARM Template to your design, you will have the option to define the parameters when you build the Blueprint or allow the parameters to be defined when the Blueprint is assigned.
- Publish your Blueprint - After your Blueprint is ready to go, publish it by giving it a version number and description. It is now ready to be assigned.
- Assign your Blueprint - Assign your published Blueprint to your subscriptions or management groups. After assignment your environment will be created, resources deployed and polices applied.
At the time of assignment you can choose to use Lock Assignments to protect your design. The Lock Assignment allow you protect the artifacts you've defined as read-only or to prevent them from being deleted, even by subscription owners.
Lock Assignment settings:
- Don't Lock - The assignment is not locked. Users, groups, and service principals with the appropriate permissions can modify and delete deployed resources.
- Do Not Lock - The assignment is locked. Deployed resources can't be deleted - even by subscription owners. Not all resource types support locking. Due to caching, locks may take up to 30 minutes to become enforced.
- Read Only - The assignment is locked. Deployed resources can't be modified or deleted - even by subscription owners. Not all resource types support locking. Due to caching, locks may take up to 30 minutes to become enforced.
Now that we have created a Blueprint, what do we do when we want to make changes? The process is very similar to the initial Blueprint creation.
- Create a new Draft - Select the Blueprint you want to create a new version and edit it to make the necessary changes
- Publish the Blueprint - Publish the Blueprint with a new description and version number
- Assign the Blueprint - Assign the new published Blueprint to a subscription or management groups
Updating Assigned Blueprints
If you need to make changes to a Blueprint after it has been assigned, you can update the settings of the version but not add or remove Artifacts. To accomplish this you would need to create a new version of the Blueprint.
Changes we can make when updating an assignment are:
- Adding or removing lock assignments or changing the lock assignment type
- Changing the values of dynamic parameters
- Changing the assigned Blueprint to a newer version
Now that we understand the basics of Azure Blueprints, let's consider the following scenario. You have been assigned a project to assist a team of developers to deploy small Azure environments for an application they're writing. I have listed the design requirements below. Let's walk through how we could do this with Azure Blueprints.
- [ ] VNet configured with NSG
- [ ] Resource group for network resources
- [ ] Resource group for VM
- [ ] Contributor role for "Cloud Admins" group on the subscription
- [ ] Virtual machine contributor role for "Helpdesk Team" on the Virtual Machine Resource Group
- [ ] Ensure VM are backed up
- [ ] Assign Usage tag to all resources
- [ ] Make the environment reproducible for other subscriptions
- [ ] Disallow environment user from deleting the defined resources
Walk through of creating a Blueprint
- Open the Azure Portal and launch the Azure Blueprints service
- In the Create a blueprint section, click Create
- Select the Basic Networking (VNET) template
- Enter Blueprint name, Blueprint description and Definition location, then click Next: Artifacts
The location can be a subscription or a management group
At the subscription level
- Type "Azure Backup" in the search field and select Azure backup should be enabled for Virtual Machines > Click Add
- Type "add a tag" in the search field and select Add a tag to resource groups > Click Add
- From the Create Blueprint hierarchy > select the Add a tag to resource groups policy and enter the tag: Usage and tag value: Production
- Add artifact > Enter Artifact display name Virtual Machine Resource Group > uncheck the box This value should be specified when the blueprint is assigned and enter VirtualMachine-RG for the Resource Group Name
- Add artifact > Role assignment > Select Contributor for the Role and choose the Cloud Admins group (this is a preexisting Azure AD group)
At the VNET Resource Group level
- Add artifact > Azure Policy > select the policy: Inherit a tag from the resource group
At the Virtual Machine Resource Group level
- Add artifact > Azure Policy > select the policy: Inherit a tag from the resource group
- Add artifact > Role assignment > Select Virtual Machine Contributor for the Role and choose the Helpdesk Team group (this is a preexisting Azure AD group)
- Click Save Draft
- Click on Blueprint definitions, this will list your Blueprints
Notice the different icons; the lighter icon denotes draft Blueprints and the darker ones are published
- Open Blueprint definitions > Click on Blueprint-01 > Publish Blueprint
- Enter version number and description
- Click on Blueprint-01 > Assign blueprint
- Enter Assignment name, Location, definition version
- Choose Lock Assignment value Do Not Delete to prevent artifacts defined by blueprint from being deleted
- Assign values to the available template parameters
Blueprint parameters can be defined during its creation or they can be left to be entered when the Blueprint is assigned.
- Verify resources deployed correctly
Connect to Azure tenant
- Connect to your Azure tenant via PowerShell
Export Blueprint for redistribution
- We can use the Az.Blueprint PowerShell module to export the Blueprint with the following commands:
$bpDefinition = Get-AzBlueprint -Name 'Blueprint-01' -Version '1.0'
Export-AzBlueprintWithArtifact -Blueprint $bpDefinition -OutputPath 'C:\Images\Blueprints'
- The result of running those commands looks like this:
- If you browse to the specified directory, you will find a folder that matches the name of your Blueprint that contains a JSON file and a subfolder called Artifacts that contains your artifacts.
- Now we have exported the Blueprint named Blueprint-01 for use with other projects. We can save it locally or share it with Git or Azure DevOps.
How we met our requirements
Let's take a quick look at which settings and artifacts we used to meet our requirements in this scenario:
- [x] VNet configured with NSG - Blueprint template that included ARM templates
- [x] Resource group for network resources - Resource group artifact
- [x] Resource group for VM - Artifact - Resource group artifact
- [x] Contributor role for "Cloud Admins" group on the subscription - Policy assignment artifact
- [x] Virtual machine contributor role for "Helpdesk Team" - Role assignment artifact
- [x] Ensure VM is backed up - Policy assignment artifact
- [x] Assign Usage tag to all resources - Policy assignment artifact
- [x] Make the environment reproducible for other subscriptions - Az.Blueprint PowerShell module
- [x] Disallow environment user from deleting the defined resources - Lock assignment
I am excited about how easy the Azure team has made creating new deployments using Azure Blueprints. As someone who is not familiar with tools like Ansible or Terraform, Azure Blueprints will be a good building block into the infrastructure as code mindset. I'm looking forward to testing it further and using it in my customer deployments.
Check out these sites for more information:
Mike Pagán is a Senior Solution Architect and Azure Product Manager for a technology consulting company in the Midwest. He has over twenty years of experience designing and delivering Microsoft infrastructure solutions. Over his career, Mike has attained certifications from Microsoft, VMware, Cisco, and CompTIA. He is currently focused on designing Azure solutions for his customers and building a top-notch Azure practice. In his free time, he enjoys spending time with his wife and three kids, woodworking, and gardening.