A while ago I signed up to participate in the Azure Advent Calendar. An awesome initiative by Gregor Suttie and Richard Hooper.

My goal for my contribution was to summarize the past few months of my Azure Blueprint experiences and provide a clear introduction into managing Blueprints as Code.

During the video we’ll briefly touch the Azure Blueprint basics and creating a fresh Blueprint using the Azure Portal.

From there we’ll move on to working with Artifacts, exporting the newly created Blueprint and then go about managing that Blueprint as code. For simplicity and to prevent too much of a technical deep dive into JSON, I focused on a single artifact. But the principle remains. If you’re going to start with Blueprints as Code, this will hopefully help you kick start your journey.

Of course, there are multiple ways to go about doing this. We’re using the Azure Portal to help you design an initial Blueprint, understand what’s happening and go from there. But once you get the hang of it and understand how artifacts work and how you can fit your resource into them, I recommend looking into the Azure Blueprints Generator for Visual Studio Code by @AmineCharot. The plugin provides you with a pretty a pretty straight forward way of creating your Blueprints from scratch.

The Video
Alright, so the video is probably what you are here for: I can write out the entire script, but it’s probably easier to just watch the video 🙂

The Code
The samples for “MyFirstBlueprint” can be found at https://github.com/whaakman/azureadventcalendar-blueprint-files

The Assignment file
One specific item that deserves some explanation; the assignment file.

During the video we used the assignment file as pasted below. As mentioned in the video, the file contains similar values as provided through the assignment using the Azure Portal.

{
    "identity": {
        "type": "systemAssigned"
    },
    "location": "West Europe",
    "properties": {
        "blueprintId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/providers/Microsoft.Blueprint/blueprints/bpAsCode",
        "resourceGroups": {},
        "locks": {
            "mode": "AllResourcesDoNotDelete"
        },
        "parameters": {
            "webApplicationshouldonlybeaccessibleoverHTTPS_effect": {
                "value": "Audit"
            }
        }
    }
}

When deploying a Blueprint, the BlueprintID must match with what eventually will be present within Azure. The Blueprint ID is pretty easy to determine. The ID depends on whether the Blueprint is stored on a subscription level or on a Management Group level and is build up as follows:

Blueprint ID on a ManagementGroup Level
/providers/Microsoft.Management/managementGroups/myManagementGroupId/providers/Microsoft.Blueprint/blueprints/BlueprintName

Blueprint ID on a Subscription Level
/subscriptions/SubscriptionID/providers/Microsoft.Blueprint/blueprints/BlueprintName

Each Blueprint.json also requires a region as for each Azure Resource Manager deployment a location is required. Note that this isn’t the actual location that your resources will be deployed in, you can still specify a location for your Resource or Resource Group deployments.

Also note that the “resourceGroups”: {} object is empty but still present. Blueprint.json always requires “resourceGroups”: {} to be present, even though you don’t necessarily need to deploy a Resource Group. Therefor, the parameter needs to be populated as well and also needs to be present within the assignment file.

Another notable section is “Parameters”. This is where you store the values of your parameters. I’ve used the same example during the video but to recap the using an ARM Template example this is what’s happening:

“We started with adding the value for “webAppName” to the assignment file. During the assignment the value is parsed into the “Blueprint.json”. During the artifact deployment (artifact-template-webapp-deploy.json), the parameter value is available to the artifact, which then grabs the value and parses it into the actual ARM template just as if you were providing parameters during an ARM deployment.” (https://www.wesleyhaakman.org/deploying-and-managing-your-azure-blueprints-as-code/)

All the background information as referred to during the video can be found here:

The use case
https://www.wesleyhaakman.org/why-you-need-to-build-landing-zones-and-use-azure-blueprints/

The basics
https://www.wesleyhaakman.org/deploying-and-managing-your-first-landing-zone-with-azure-blueprints/

Blueprints as Code
https://www.wesleyhaakman.org/deploying-and-managing-your-azure-blueprints-as-code/

Blueprint Level Parameters
https://www.wesleyhaakman.org/azure-blueprints-level-parameters/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.