IAC Productivization Using Azure Blueprint

Infrastructure as code – or IaC – is defined as the management of infrastructure using techniques similar to those of software lifecycle management.

Virtualization and cloud adoption have necessitated automation of infrastructure management and the provisioning process. Previously, infrastructure growth was limited by the fact that new equipment had to be purchased, which was staggered over time to reduce pressure on the IT team who had to prepare the equipment when it arrived.

Currently, all public clouds offer their own solution to manage the entire infrastructure using an IAC methodology. In particular, Azure uses Azure Resource Manager. However, Azure Resource Manager (ARM) presents a number of challenges when used in large-scale projects:

• How to use an ARM template to deploy to 50,100, 1,000 different subscriptions;
• How to maintain modular templates to maximise reuse;
• How to ensure that environments are updated with the template used for deployment.

The Azure Blueprints service may be used to solve all these problems. This Azure service allows a central repository of artifacts to be defined and for those artifacts to be assigned in the different subscriptions of an account.

Azure Blueprints

Blueprints currently support the following artifacts:

• Azure Resource Manager templates
• Resource groups
• Azure Policy assignments
• Role assignments

LIFECYCLE

A blueprint goes through the following stages in its lifecycle:

1. Creation of a blueprint. When a blueprint is created, it remains in draft status. In this state, the blueprint can be modified as many times as necessary but cannot be assigned to any subscription until it is published.

2. Publication of a blueprint. A blueprint must be published in order to be assigned to a subscription. Once this is done its status will change from Draft to Published.

3. Creation of a new blueprint version. Once a blueprint has Published status it cannot be changed, but a new version may be created and modified. When the changes to the new version are saved, the blueprint stays in Unpublished Changes status. These changes correspond to the draft version of the blueprint.

4. Publication of a new version of the blueprint. When changes of a version of a blueprint are published, it moves from Unpublished Changes status to Published. A single blueprint can have multiple versions, each of which can be assigned to a different subscription.

5. Assignment of a blueprint to a subscription. Once the blueprint is published, any of its versions may be assigned to an Azure subscription.

6. Updating an assignment. A blueprint assignment can be updated to do one of the following:

• Activate or deactivate the resource lock.
• Change the value of the dynamic parameters.
• Update the allocation to a new published version of the blueprint.

7. Deletion of a published version. A specific version of a published blueprint can be deleted but all assignments of that version must first be deleted.

8. Deletion of a blueprint. The blueprint and all its versions may be deleted but not before all assignments with that blueprint have been deleted.

Azure Blueprint Lifecycle

Thanks to the blueprint lifecycle we can see which version of the infrastructure is deployed in each of the subscriptions of an Azure account.

BLUEPRINT PERSONALISATION

Parameters are used to customise blueprints and make them reusable so that certain values can be defined when assigning a blueprint to a subscription. In this way reusable components are generated in different environments/subscriptions.

It is possible to define parameters at the level of the blueprint itself or at the level of the artifacts contained within it. When a parameter is defined at blueprint level, the artifacts contained within that blueprint may use it. A good example would be one that defines the designated resource prefix so that all resources coming from the blueprint share the same prefix in order to establish a consistent resource naming policy.

Parameters may also be differentiated according to when their value is assigned:

• Static parameters: The value of these parameters is set at the time of defining the blueprint and this cannot be altered later when the blueprint is assigned.
• Dynamic parameters: Those whose value is defined at the time of assigning a blueprint to a subscription. The value of these parameters can be updated later once the blueprint is assigned, which will cause the assignment of the blueprint to the subscription to be updated.

BLOCKING OF RESOURCES

This feature ensures the consistency of the resources deployed with Azure Blueprint. Depending on the type of lock chosen, this prevents resources from being modified or removed outside the scope of the blueprint.

Resource locks are defined within each blueprint at the time of assigning a blueprint to a subscription. These locks can only be changed from within the blueprint itself when creating a new allocation or updating an existing assignment.

The following resource lock modes are currently supported:

• Don’t Lock
• Read Only
• Do Not Delete

CONCLUSION ON AZURE BLUEPRINT

Use of the Azure Blueprint features described gives us a centralised tool that provides the following functionalities:

• Versioning of the different versions of our infrastructure templates.
• View of which version of our templates is deployed in each account subscription and tracking of the different deployments made over time.
• Fast and easy provisioning of infrastructure in multiple subscriptions.
• Reuse of components thanks to the use of static and dynamic parameters in blueprints.
• Safeguarding of infrastructure consistency through use of resource blocking.