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