Bicep Christmas gift: the deployer() function

The Bicep language for Azure Infrastructure as Code (IaC) continues to evolve rapidly, reshaping how developers and cloud architects design, deploy, and manage Azure resources.

In this post, we’ll explore an exciting new function introduced in Bicep version 0.32, highlighting how it enhances the language’s capabilities for Azure Infrastructure as Code (IaC). These additions reflect Bicep’s continuous evolution, making it even more powerful and versatile for developers working with Azure.

A common challenge in Azure Infrastructure as Code (IaC) is identifying and reusing the identity executing a deployment. This capability would enable assigning roles or configuring access dynamically without hardcoding identity details or managing them externally.

Currently, Bicep provides functions like subscription(), retrieving metadata about the subscription in which the deployment is running. However, there wasn’t a built-in way to access details about the principal executing the deployment.

With Bicep 0.32 you now can! The function deployer() is introduced, which allows you to retrieve the object of the principal that is deploying the Bicep file!

The function deployer() allows you to retrieve the objectId of the principal that is deploying the Bicep file

The ability to natively access the deploying principal within Bicep would eliminate the need for additional automation scripts or manual intervention, making deployments more streamlined and robust.

One practical use case for this functionality is generating unique GUIDs for scenarios such as creating role assignments. By leveraging the unique attributes of the deploying identity — such as its Object ID or Tenant ID — along with other contextual details, you can create deterministic and consistent GUIDs.

generating unique GUIDs

The deployer() function also proves valuable in scenarios involving Azure Entra ID. For instance, when creating an Entra group using the new Graph extension, you can seamlessly assign the current user (or deploying identity) to that group. This dynamic capability simplifies group membership management and eliminates the need for workarounds.

Upgrade to 0.32 to get access to the deployer() function!

As we wrap up, it’s exciting to see how features like the deployer() function are expanding the capabilities of Bicep, making Azure Infrastructure as Code more powerful and intuitive.

With the holiday season upon us, it’s the perfect time to reflect. Whether you’re deploying in the cloud or just enjoying some downtime, here’s wishing you a joyous holiday season and a fantastic start to the new year! Looking forward to 2025!

***

Originally posted here: https://www.linkedin.com/pulse/bicep-christmas-gift-deployer-function-freek-berson-a8hye

Introducing Bicep on the Go: a new series of short videos!

Bicep on the Go: a new series of short videos showcasing specific Bicep features, having fun with Infrastructure as Code, and maybe even interviews with #community members! 💪Let me know if you’re interested!

(2) Bicep on the Go — Trailer — YouTube

Bicep on the Go — Trailer

Last weekend, an idea popped up💡… I’ve been presenting on Bicep infrastructure as Code at conferences around the world for quite some time now. Usually, these are 45 to 60-minute break-out sessions. I always prefer doing all demos live, so I was thinking, why not publish these demos as short clips for everyone to consume on demand?

Hence, the inception of Bicep on the Go! Easy-to-digest content designed to help you jump-start your IaC development

Link https://www.youtube.com/playlist?list=PLGLjpco69i8MAIyTX094CtLtNBiW-7iQ4 to the playlist, which already contains episode 1, about #Github #Copilot and the #Bicep visualizer!

📽️Most recently, I presented at the EUC User Group in Stockholm, so this trailer and the first few of on-the-go clips were taken from that event. Special thanks to Kent Söderlund and Gabriel Yttermalm for hosting the amazing End User Computing Sweden event earlier this month and recording!

#Bicep #MVPBuzz #IaC

Publish Bicep modules to registries with the source.

Bicep offers the ability to store your modules in a registry in Azure. This is based on storing them in an Azure Container Registry (ACR).

This approach offers several advantages, especially regarding DevOps practices, version control, shared access, and reusability.

Let’s consider the module below, which creates several Azure Virtual Desktop (AVD)- related resources, such as host pools, workspaces, and application groups.

Publishing your modules to an ACR is quite easy. In this example, I’ll use Azure CLI. First, create an ACR in case you don’t have one yet. Since an ACR is just another resource in Azure, you can use Bicep to create one, as shown below.

Now use the publish command, provide the bicep module you want to publish, and provide the target location, the ACR, and where you want to store it.

The result looks like the below: a container repository is visible under repositories.

You can now start using modules inside your Bicep templates. In the example below, I’m referencing the module stored in the ACR that creates the Azure Virtual Desktop resources.

Today, you already have the ability in VScode to view the source of the module; simply hit F12, and you are provided with the source.

This is, however, the transpiled version based on ARM Templates in JSON. Wouldn’t you rather want to see the Bicep module instead? You now can.

There is an experimental feature called publishSource that you can add to your bicepconfig.json. Afterward, you can add the option — with-source to your publish command.

Based on the header image of this article, what country will I be visiting this month? Reply to this post with your answer to win a copy of my book!

When you now press F12 you can see the original Bicep module containing our AVD resources! 💪 When you hover over the file name, you can see the source location, the ACR, module name, and version.

This makes working with Aure Container Registries a lot more convenient!

📖 Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure

Exporting and importing variables between Bicep files: compileTimeImports

 

Infrastructure as Code (IaC) has revolutionized how we manage and provision IT infrastructure. Azure’s adoption of this concept through Bicep, a domain-specific language, has made it easier and more efficient.

In case you’re (still) wondering what Bicep is, it is an open-source language developed by Microsoft for declaratively deploying Azure resources. It aims to simplify the authoring experience and provide a cleaner syntax compared to ARM templates. Bicep files are transpiled into ARM templates, making it a powerful yet user-friendly tool for Azure deployments.

In this blog, I cover how to use a feature (experimental) that allows you to export and import variables, user-defined functions, and user-defined types.

It has been in the Bicep builds for some time, but it’s a very useful feature, and I have never published on this before. Before you dive deeper into the functionality of exporting and importing variables between Bicep files, it’s important to highlight that this feature is currently experimental. To use this experimental feature of exporting and importing variables in Bicep, you need to enable it explicitly. This is done by modifying the bicepconfig.json. The configuration to add or modify is compileTimeImports, which should be set to true.

Now consider the Bicep module below. This module deploys a few Azure Virtual Desktop (AVD) resources like a host pool, application group, and workpace.

Note that you can use the @export() decorator. This makes the variable ‘prefix’ importable by other Bicep files or Bicep modules. As a result, we reuse the value without declaring it across multiple files. This is a simple example, but you can imagine adding multiple variables or even user-defined functions and user-defined types.

You can now use the exported variables in other Bicep files in a couple of different ways. To import a single value, use the import state as shown below. You use the keyword Import, followed by the name of the variable, followed by the source Bicep file. Super easy, right? You can now use the ‘prefix’ variable inside this Bicep file. In this example, we use it in line 23 to generate a name for the network interface.

If you want to import it using another name or alias, simply use the method below. You can now use the variable by referring to the alias you defined. In this case, ‘i_prefix’.

You can, of course, also import multiple variables at once using the code above by referring to them all individually.

Finally, an even easier way is to import all exported variables by using the ‘*’ sign as shown below. You can now use ‘imported’ as the name and specify the variable after the ‘.’ sign, and the Bicep VSCode extension even picks up on this, providing you with an auto-complete.💪

The great thing is you can also import inside .Bicepparam files in the same way. In the example below, I import the values and use them as values for my parameter files. If you are new to Bicepparm files, follow a previous article where I explain how this works.

It might seem like a simple feature, but to me, it is a super welcome addition to the language. It avoids declaring certain variables or types multiple times and improves reusing code. I like it, and the possibilities and use cases are endless! What do you think?

📖 Looking to get started with Bicep? I authored and published the book Getting started with Bicep: Infrastructure as code on Azure

Bicep Deployment Pane: Validate, What-If and Deploy at your fingertips!

 

Introduction

The Bicep VS Code extension keeps on improving. Besides validation, intellisense, code navigation, generating param files, the visualizer and much more, I tested a new experimental feature this weekend. The deployment pane!

I could not have thought about a better name for this feature as it literally is a pane in VSCode that helps you with the deployment of a Bicep template.

You can of course already easily perform deployment, validation, and what-If using PowerShell and the AZ CLI. Even a deployment can also be kicked off directly from the VSCode by performing a right-click on any Bicep file as shown below.

This article walks through the Bicep Deployment Pane feature, providing Validate, What-If and Deploy at your fingertips in VSCode!

Bicep Deployments pane example

Lets consider the Bicep template as shown below. If you have been following my previous blog posts, this will look familiar. It’s a simple Bicep template that deploys an Azure Virtual Desktop (AVD) host pool.

Let’s imagine I now want to deploy this to Azure. Before deploying it however, I want to validate my template first to make sure the ARM engine is able to process it, and let’s also perform a What-If first.

In case you’re not familiar with What-If, it allows you to preview the potential changes that will occur in the Azure resources as part of your template before actually applying those changes. It’s a great way to assess the impact of your intended deployment actions without making any actual modifications to the resources.

How to open the Bicep Deployment Pane

There are 2 easy ways to open the Bicep Deployment pane. Right-click any Bicep template and select ‘Show Deployment Pane’ or choose to open it to side. The latter is my favorite option.

Or, with any Bicep template open, click on this new Cloud icon at the upper-right corner of the VSCode editor.

Below is what you are presented with. I’ve zoomed out a little to give you a better idea of the overall experience, and we’ll zoom into each section of the deployment pane now as well.

Selecting a deployment scope

Before being able to perform a what-if, validate, or deploy you first need to define the deployment scope. Click ‘Pick Scope’ to start defining the deployment scope. After authentication, you are able to select the subscription and the resource group of your desired deployment.

Defining parameter values

Next, define the values for the parameters of the Bicep template. In this example, a template is used that contains a lot of default values, those are prepopulated in this section and you are able to modify those at this point and provide values for any parameters that are declared without default values. Also note that Boolean values are nicely shown as a checkbox, and parameters that have allowed values defined, are presented with dropdown boxes to easily perform a selection.

You can also point to a parameters file instead by clicking ‘Pick Parameters File’. Once a parameters file is selected, the deployment pane adapts to this as shown below. From this point, you are still able to modify the values by clicking ‘Edit Parameters’.

Before moving on the next section containing deployment actions, the deployment pane also prevents you from continuing with deployment actions in case the template contains errors.

Furthermore, in case you change a value you can also easily revert back to the default value by selecting ‘Reset to default’.

Validate, What-if, and deploy!

Let’s move to the action section and cover the options to perform a what-if, validate, and deploy action from within the deployment pane.

Click Validate to perform a validation of the template. Amongst another checks, the validate option looks at whether the declared variables and parameters are all used, ensures that nothing is returned from the template that might be sensitive, and that no hard-coded values are used.

In this case the template is validated and shows the result succeeded.

If we introduce a parameter in the template that is not being used. The validate step point this out and the option ‘Show JSON’ allows you to get more details on the location of the error.

Next, you can run a what-if directly from the deployment pane. This performs the same actions when using -WhatIf in the PowerShell CmdLet New-AzResourceGroupDeployment, or when adding what-if to the AZ CLI command.

The deployment pane shows the result of the what-if command, in this case indicating a new resource will be created.

Not such an exciting What-If result of course, but if we would for example make some changes in a subsequent deployment, the What-If result becomes more interesting and shows the changes that would be applied if the template was to be deployed.

And finally, when clicking Deploy, the Bicep template is deployed to Azure, and the result including the defined output are also shown in the deployment pane!

Concluding

I think the deployment pane is a great way to have validate, what-if and deploy options at your fingertips. Of course all of these actions can also be performed using AZ CLI, PowerShell and other methods, but having this directly integrated into VSCode just makes life easier.

Deployment Pane is an experimental feature at this point. To test drive the functionality, make sure to use a recent preview build (is used 0.19.84) and enable the feature in the extension settings as shown below.

Shout out to Anthony Martin who performed a live demo of this feature at last weeks Bicep Community Call!