Microsoft Azure Blueprints Service Basics

Author: Alexander Monakhov, Leonty Onischuk, Vitaly Gnusin DevOps Engineers, DataArt, Anna MedvedenkoProject Manager, DataArt

Our DevOps team tried to understand the intricacies of using the Blueprints service. In this article I will talk about the results of our little research: the structure and parameters of the Blueprint, I will touch on the topic of artifacts and the resource group in the context of using the service. I think the material can be useful, first of all, for DevOps engineers who work with the Azure infrastructure and need a convenient tool for creating and managing the environment. But programmers interested in cloud technologies will also find it interesting to read the article: Blueprints is a modern solution that allows you to optimize the process of software development and support.

1. What are Blueprints?

Blueprints – an Azure Cloud service that allows you to declaratively define a repeatable set of Azure Cloud resources that meet the standards and requirements of your organization.

Blueprints enable developers to quickly and easily deploy new Azure cloud environments while meeting all security and compliance requirements.

Blueprints - structure and application levels
Blueprints – structure and application levels

2. What can you do with Blueprints?

First of all, you can deploy different resources from templates and use artifacts:

  • Role Assignments.

  • Policy Assignments.

  • Azure Resource Manager templates (ARM templates).

  • Resource Groups.

Unlike ARM templates, the Blueprints service is designed to configure the environment. Such a configuration usually contains a set of resource groups, policies, roles, and, in fact, ARM templates. Blueprint contains all of these artifacts together and is versionable, which opens up the possibility of implementing CI / CD practices.

Also, unlike ARM templates, when resources are deployed via Blueprint, the connection between the definition (what should be deployed) and the destination (what has been deployed) is preserved. This relationship allows you to control the process of deploying resources.

Each Blueprint can (but does not have to) contain an ARM template.

3. Blueprint as Code

3.1 Prerequisites

For the convenience of working with Blueprints in Azure DevOps at the organization level, you can install Azure Blueprints extension by Neil Peterson

Working with Blueprints consists of the following steps:

  • Preparing the Blueprint, its artifacts (see below), and the assignment parameters file (assign.json).

  • Create (publish) a Blueprint version to the Azure Blueprints service.

  • Assignment of the Blueprint version – as a result, an environment is created that corresponds to the Blueprint artifacts and parameters from the file assign.json, or the existing environment is updated and brought in line with them.

3.2 Blueprint Artifact Structure

Blueprint artifacts are described by JSON files – each artifact is contained in a separate file.

In general, the folder with Blueprints and artifacts looks like this:

File blueprint.json – the main one, its purpose is to define the Blueprint itself. When a Blueprint is deployed, it is called first, and all artifacts are its child resources.

File assign.json is required for the Blueprint assignment operation, it contains the value of variables that are used in the Blueprint in the Assignment process (for example, the names of the created components, their SKUs, the region in which the described components will be created, etc.). Usually, the values ​​of variables or parameters in this file need to be changed. For this, file transformation is used.

3.3 File transformation

Function FileTransformcan modify the content of XML or JSON files.

Example :

The assign.json file that is used in the Blueprint assignment process. We need to change the values ​​of location, blueprintId, gOrganizationName and g_AzureRegion:

{
    "identity": {
      "type": "SystemAssigned"
    },
    "location": "testLocation",
    "properties": {
      "blueprintId": "testBlueprintId",
      "resourceGroups": {},
      "parameters": {
        "g_Organization_Name": {
          "value": "testOrgName"
        },
        "g_AzureRegion": {
          "value": "testLocation"
        }
      }
    }
} 

In the YAML pipeline, we specify the desired value of the variables, observing the structure of the file being modified:

variables:
  location: 'westeurope'
  properties.blueprintId: "/subscriptions/$(SubscriptionId)/providers/Microsoft.Blueprint/blueprints/AM-BP-feature-init"
  properties.parameters.g_AzureRegion.value: $(location)
  properties.parameters.g_Organization_Name.value: "Integration"

and transform the file:

- task: FileTransform@1
  inputs:
    folderPath: '$(Agent.BuildDirectory)blueprints'
    fileType: 'json'
    targetFiles: 'assign.json'

We can see the contents of the transformed file:

- script: type "$(Agent.BuildDirectory)blueprintsassign.json"

3.4 Types of artifacts

Blueprint consists of artifacts, and the following types of the latter are supported:

  • Resource groups – applied at the subscription level.

  • ARM templates are used at the level of subscriptions and resource groups.

  • Policy assignment – applied at the subscription and resource group level.

  • Role Assignments – Apply at the subscription and resource group level.

Consider an example file blueprint.json:

{
    "properties": {
        "description": "This will be displayed in the essentials, so make it good",
        "targetScope": "subscription",
        "parameters": { 
            "principalIds": {
                "type": "string",
                "metadata": {
                    "displayName": "Display Name for Blueprint parameter",
                    "description": "This is a blueprint parameter that any artifact can reference. We'll display these descriptions for you in the info bubble",
                    "strongType": "PrincipalId"
                }
            },
            "genericBlueprintParameter": {
                "type": "string"
            }
        },
        "resourceGroups": {
            "SingleRG": {
                "description": "An optional description for your RG artifact. FYI location and name properties can be left out and we will assume they are assignment-time parameters",
                "location": "eastus"
            }
        }
    },
    "type": "Microsoft.Blueprint/blueprints" 
}

We see two optional parameters parameters: principalIdsand genericBlueprintParameter

These parameters can be used in any child artifacts. In this case, we define the ResourceGroup parameter in the fileblueprint.json rather than in a separate file.

3.5 Parameters

Almost everything in Blueprint can be parameterized. The parameters are defined in the blueprint.json file and can be used in any artifacts.

The parameter can be defined in a simple way:

"parameters": { 
    "genericBlueprintParameter": {
        "type": "string"
    }
}

Parameter types can be found in this section of the documentation

Parameters can be accessed in the same way as in the properties of ARM templates (defaultValue, allowedValue, etc.). We can also call the parameters defined earlier:

"properties": {
    "genericBlueprintParameter": "[parameters('principalIds')]",
}

We can also get the value of the parameter through a construction of the form:

${{ parameters.genericBlueprintParameter }}

3.6 Resource Group Properties

We have defined the Resource Group properties in the main fileblueprint.json with the following parameters:

  • Location: “location”: “eastus”.

  • Hostname for ResourceGroup: SingleRG.

The resource group has not yet been created, this will happen after the assignment.

Optionally, we can specify the name of the resource group by adding “name”: “myRgName” as a child parameter of the SingleRG object (for more details, see here).

3.7 Artifacts

All artifacts must have the following parameters:

  1. Kind, according to which, the artifact can be:

    a. template,

    b. roleAssignment,

    c. policyAssignment.

  2. Type which for artifacts will always be: Microsoft.Blueprint / blueprints / artifacts.

  3. Properties – the main section, which describes all the properties of the artifact.

    For example:

    a.dependsOn may optionally indicate dependency on other artifacts. More informationhere

    b.resourceGroupcan optionally indicate the name of the resource group where the resources will be located. If this parameter is not specified, the resource group specified in the bluepring.json file will be used to host the resources.

The complete specification for each type of artifact is described here: Policy Assignment, Role Assignment, Template

3.8 Working with Blueprints in pipelines

To work with Blueprints you can use:

  • powershell cmdlets (Az.Blueprint module, for details see here);

  • tasks developed by Neil Peterson (for more details see here, we will use them in this article).

3.8.1. Blueprint creation

steps:
- task: nepeters.azure-blueprints.CreateBlueprint.CreateBlueprint@1
  displayName: 'Create Azure Blueprint'
  inputs:
    azureSubscription: 'nepeters-subscription'
    BlueprintName: 'blueprints-demo'
    BlueprintPath: ./create
    IncludeSubFolders: true
    PublishBlueprint: true
    ChangeNote: 'Added new artifacts.'

Results can be viewed atAzure portal -> Blueprints -> Blueprint definitions

3.8.2. Purpose of Blueprint

steps:
- task: nepeters.azure-blueprints.AssignBlueprint.AssignBlueprint@1
  displayName: 'Assign Azure Blueprint'
  inputs:
    azureSubscription: 'nepeters-internal'
    AssignmentName: 'prod-test-one'
    BlueprintName: 'prod-test-one'
    ParametersFile: 'assign/assign-blueprint.json'
    AlternateSubscription: true
    SubscriptionID: '00000000-0000-0000-0000-000000000000'
    Wait: true
    StopOnFailure: true

Results can be viewed atAzure portal -> Blueprints -> Assigned blueprints… This section is especially useful for obtaining detailed logs for Blueprint assignment errors.

As you can see, working with Blueprints is not much more difficult than working with ARM templates, but it provides much more functionality and allows you to control the environment. An important point is the possibility of hierarchical application of blueprints. Using this Azure service, you can not only automatically deploy your environment, but manage it in compliance with all security and compliance requirements.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *