Ever since the release of ARM, and now Bicep, there has been a glaring omission from what we can create with this infrastructure as code languages - Entra ID (formally Azure AD) resources. There was an obvious reason for this, as Entra ID resources are created using the Graph API, which is a completely separate API from ARM. This has meant that we’ve had to resort to other methods for creating Entra ID resources as part of our deployments, things like deployment scripts or separate tasks in a pipeline.
Deployment scripts are a feature of Bicep (and ARM templates) that allow you run either Azure PowerShell or Azure CLI scripts as part of your infrastructure as code deployment. This provides a means to do things in your deployment that Bicep can’t do natively. You’ll often hear this referred to as an “escape hatch”. If you can write it in Azure PowerShell or CLI (or any other PowerShell module if you download it), then you can do it in your deployment script.
Whilst we’ve been using Bicep files for a while now to create infrastructure as code, we’ve been stuck using the same JSON parameter files we had been using with ARM templates to be able to pass in parameters to our Bicep code. Well, no more! We now have a Bicep parameter file, the .bicepparam file, which allows us to use Bicep syntax and offers several benefits.
All of that said, the JSON parameter files still work, so why should you switch?
It’s time for the Azure Spring Clean. The annual event is organised by Joe Carlyle and Thomas Thornton to encourage you to look at your Azure subscriptions and see how you could manage it better.
In this year’s article, we will look at a tool called Checkov that can help you check your Bicep code for best practices and compliance. So let’s get started.
What is Checkov Checkov is an open-source tool that can be used to scan Infrastructure as Code (IaC) for best practice and compliance.
As you probably know, I talk quite a bit about Bicep. Invariably when I do, I get a comment or question like “why would I switch from Terraform to Bicep” or “This is pointless, Terraform already does all this”. Well, here’s the secret: if you’re using Terraform and are happy with it, then Bicep isn’t aimed at you!
Microsoft’s primary goal when creating the Bicep language was to remove the barrier of entry when using Infrastructure as Code in Azure.
Over the last few months, I’ve been working on YouTube series called Bicep for Real, which aims to help you learn the Bicep language whilst applying it to a real project and a real-world scenario. This series goes beyond just Bicep and covers version control, automated tests, CI/CD and automated deployments. The aim is for people to come away from this series not only with knowledge of the Bicep language but also how it applies to their projects and real-world workloads.
Azure App Service has supported running containers for a while now, both in standard App Service and in Azure Functions. Setting this up through the UI is pretty straightforward, however, creating the same setup using Infrastructure as code can be a bit tricky. There are several different configuration settings that need to be added that are not always obvious. In this article, we will cover them what these are and when to use them and put them all together in one place.
This week, I discovered that it is possible to use the functions that are in Bicep (and ARM) templates in C# code. Why would you want to do this? Well, for the most part, you wouldn’t. Basic functions like concatenate, split etc., already have equivalents in C# code that would produce the same results. However, I had a specific scenario where it did prove useful.
In my scenario, I needed to generate a unique string identifier for some resource naming.
