Define a resource
The main thing you do with Bicep templates is define Azure resources. Almost anything you can deploy in the Azure portal you can define as an Azure resource in Bicep code. Here’s an example of a typical resource definition in Bicep, this example creates a storage account.
Let’s look through each of the different components of the definition and talk about what each one does, and why it’s there. First we’ve got the resource key word, this tells Bicep that we’re about to define a resource. You’ll use this key word a lot in Bicep, it’s the bread and butter of Bicep.
Then you provide a symbolic name, in this example we’ve given the resource a symbolic name of storageAccount. A symbolic name is only used within the Bicep file. It’s a way for us, as Bicep authors, to refer to this resource. The symbolic name never appears within Azure.
Then we’ve got a resource type and API version. Every resource in Azure has a resource type, in this example, our resource type is Microsoft.Storage/storageAccounts. Every resource type has at least one, but usually many different API versions. These are essentially versions of the product that have been released by Microsoft which you use to interact with Azure. In this example, our API version is 2021-08-01. Generally speaking you want to use the latest API version for whatever resource type you’re defining.
Next you define a name, this is the name of the storage account that will appear in Azure. This is different from the symbolic name defined earlier, which only appears in our Bicep file. Most Azure names can’t be changed once created so you need to make sure what you’re using is correct, has some meaning, and there might be some naming rules depending on what Azure resource you’re building. Different resources have different rules around uniqueness, length, or what characters are allowed so make sure you conform to those rules.
Then we need to define the location for our storage account, this is the Azure region we’re placing the resource. In this example, we’re locating the resource in westus3, so it will be somewhere on the West US coast.
Now we get to the properties which will be different depending on what type of resource we’re deploying. This storage account has some properties that we need to set. One of them for example is the SKU, this tells us how many replicas of our data we need. In this example, we’re using Standard_LRS which is the cheapest storage tier, but there are lots of others you can configure as well. Then we need to define the kind of storage account we’re deploying, in this example, we’re using StorageV2. I won’t go into details about the different kinds of storage account you can have in this blog. Just know that for this purpose different resource types have different properties that you need to define.
Almost all resource types will have this additional properties section where we can set a bunch of other properties as well. Again these will be specific to whatever we’re deploying.
So how do you know what properties you need to set when defining your resources in Bicep. Well, I would strongly recommend to use Visual Studio Code with the Bicep extension to author your Bicep templates as it can help you in this area enormously. When you start typing in Visual Studio Code IntelliSense comes up with suggestions about what you’re typing.
For example, if you start typing storage, Visual Studio Code will give you snipets that you can select so you don’t have to type it all out.
Once you’ve chosen your resource type you’ll then be provided with all the API versions you can chose with the latest API version at the top.
It also can populate the resource with required properties so you know what properties you need to define for that resource type.
This will provide you with all the properties that need to be set for your resource type.
That’s great for a starting point but what if you want to define additional properties. Well you can press Ctrl + Space and Visual Studio Code will display all the properties you can define for that resource type. Depending on what level within the resource you press, Ctrl + Space gives you different options. At the top level you’ll see these properties.
From the additional properties level you’ll see these properties.
If you’re still a bit hesitant about what properties you should configure for your resource you can look at the Microsoft Documentation. For example, the Microsoft Doc for storage accounts is Microsoft.Storage/storageAccounts – Bicep & ARM template reference | Microsoft Docs. This document shows the API versions, the template format for both Bicep and JSON, all the properties values available for the resource, a description of each property, a value for each property, and if you scroll to the bottom of the page it has links to example Bicep and JSON templates, so you can see how others have deployed their storage accounts.
So here are some tips for defining resources in Bicep:
- The Visual Studio Code extension for Bicep helps you to find the resource types and API versions for the resources that you create.
- If you’re familiar with ARM templates, note that the API version matches the version you’d use there too.
- Symbolic names are used only within the Bicep file and don’t appear in Azure.
- Resource names do appear in Azure.
Usually when you’re deploying a resource in Bicep you won’t just be deploying one resource, you’ll be deploying many. Now some of these resources will depend on each other and will need to be deployed in a certain order. For example, if you’re deploying a web application it will have dependencies on other resources. You’ll need to deploy an App Service Plan which represents the server hosting resources and is declared with the below:
This resource defines the App Service Plan name, location and SKU size. Next you define an App Service App. Below we define the App Service App name, location, server farm ID, and HTTPS setting. The serverFarmID property defines where this App Service App will be deployed to, which needs to be associated with an App Service Plan. We’ve already defined the App Service Plan, so in the serverFarmID we can reference the App Service Plan with the symbolic name of the App Service Plan resource. To correctly link the App Service App to the App Service Plan, Bicep needs the resource ID of the App Service Plan. So, after we define the symbolic name of the App Service Plan we end it with .id. This accesses the resource ID of the App Service Plan and by doing this Azure understands the implicit dependency the App Service App has on the App Service Plan. So Azure will fully deploy the Plan before the App.
Once you’ve written your Bicep code you’ll want to deploy the template to Azure and build your resources. You can do this from within Visual Studio Code as well using the Terminal.
You can use both Azure CLI and PowerShell to deploy your Bicep template within Visual Studio Code. The Microsoft documentation shows how to use both, so it mainly comes down to personal preference when deciding which to use. If you’re familiar with PowerShell, like myself, it can be easier to use PowerShell but Azure CLI will give you a very good experience and this is the direction Microsoft seem to be going. Bicep files have a default deployment scope of resource group, meaning when you deploy you’re Bicep file you’ll have to define what resource group you want to deploy your Bicep template to. You can deploy Bicep templates to other scopes such as Tenant, Management Group, and Subscription and I’ll cover these in a future blog. For now, you just need to know that certain Azure resources need to be deployed at a certain scope, like to create a resource group you have to deploy at least at the Subscription scope.
So to deploy our Bicep template to a resource group we would use the Azure CLI command below.
This command will deploy our Bicep file called main.bicep to the Demo1 resource group.
If you login to the Azure portal and go to the resource group we’re deploying to, you’ll see under Deployments it will say “1 Deploying”
If you click on it, it will show you what’s deploying to this resource group.
Again, if you click on the deployment name it will show you what Azure is actually deploying.
Once the deployment is complete it will say ‘Your deployment is complete’.
If you click on ‘Go to resource’ it will take you to the storage account, just as if we created it in the Azure portal. Behind the scenes, the Azure portal and Bicep are using the same API’s so there’s no difference in creating the storage account in the portal or in Bicep.
Back in the Visual Studio Code terminal you’ll see the provisioning state is succeeded.
I hope this blog has been informative and thanks for reading.
