Skip to main content

Using YAML to Drive Azure Resource Deployment with Bicep: Part 2

· 4 min read
Hasan Gural

Welcome back! In our previous session, we delved into the strengths of YAML as a tremendous alternative for orchestrating Azure configurations via Bicep. Today, I'll guide you through deploying Azure resources using a YAML with Bicep.

🧑‍💻 Using YAML and Bicep Together​

Revisiting the previous post, you might remember our YAML file, structured as follows:

resourceGroups:
  - name: "app01"
    location: "westeurope"
    tags:
      environment: "dev"
      project: "project01"

  - name: "app02"
    location: "northeurope"
    tags:
      environment: "dev"

This file lists two resource groups, app01 and app02. Each resource group has a name, location, and tags property. It's like a to-do list for our task. Now, we will write a resource block in Bicep to create these resource groups in Azure.

💬 Iterating Through the YAML File​

We will use the resource keyword to create resource groups in Azure. The resource keyword is followed by the resource type, which, in this case, is Microsoft.Resources/resourceGroups. The @ symbol is used to specify the API version for the resource type.

There are two key points I want to highlight here:

  • I have created a variable named loadContent to load the YAML file. This variable is used to load the content of the YAML file. Afterward, I created another variable called resourceGroups to store the resource groups from the YAML file, utilizing the contains function for this purpose. The function named contains checks if the specified key exists in the YAML file. If it does, it returns the value of the key; otherwise, it returns an empty array.
  • In the resource block, I have utilized a for loop to iterate through the resourceGroups' array and create a resource group for each item in the array, respecting the name, location, and tags properties.
targetScope = 'subscription'

var loadContent = loadYamlContent('./resourceGroups.yaml')

var resourceGroups = contains(loadContent, 'resourceGroups') ? loadContent.resourceGroups : []

resource resourceGroups 'Microsoft.Resources/resourceGroups@2021-04-01' = [for group in resourceGroups: {

  name: group.name
  location: location
  tags: group.tags

}]

output resourceGroups array = resourceGroups

🚀 Kicking Off the Deployment​

Let's start initiating the deployment for the above Bicep file and see the results in Azure. To deploy our Bicep file, we'll use the Azure CLI, which is the interface that allows us to interact with Azure resources. I'm going to assume that you have already installed the Azure CLI on your machine and logged in to your Azure subscription.

Once you're logged in, we can now initiate the deployment of our resource groups specified in the Bicep file. To do this, we run the az deployment sub create command, specifying the location for the deployment and the path to our Bicep file:

az deployment sub create --name deployFromYaml `
                         --template-file "main.bicep `
                         --location 'westeurope'

The reason we use the az deployment sub create command is because we are deploying resources at the subscription scope. This command creates a deployment in the selected subscription and generates a deployment name based on the name provided in our example, deployFromYaml. In the Azure Portal, you can view this deployment under the Deployments section.

🏁 Verifying the Deployment​

Starting the verification process should be quite straightforward after the deployment. You can check the resource groups either in the Azure Portal or by running the following Azure CLI command:


 az group list --output table | findstr 'app01 app02'

This command lists all the resource groups and filters the output to show only those that include 'app01' or 'app02' in their names, making it easier to verify the successful creation of your resource groups.

image

🎉 Conclusion​

I'd like to highlight an alternative approach to interacting with Bicep, moving beyond the traditional use of Bicep parameter files or JSON parameter files. By leveraging YAML, we open the door to a method that is not only easier to read but also more efficient, especially when it comes to handing over your automation processes to non-technical users. Its readability makes it ideal for non-technical users, easing the handover of automation tasks to infrastructure automation.