![Bicep Resources]()
When deploying resources to Azure, developers often need to manage a variety of resource types, such as virtual machines, storage accounts, and networks. Bicep, a domain-specific language for deploying Azure resources, simplifies this process by providing a declarative syntax that abstracts away the complexities of Azure Resource Manager (ARM) templates. In this article, we’ll explore what Bicep resources are and how to use them effectively.
This is a new series of articles about ‘BiCep’ technology by Microsoft – it is a game changer for resource management in the cloud – well worth investigating if you are a cloud builder!
Understanding Bicep Resources
In Bicep, a resource is a unit of deployment that represents a single Azure resource, such as a virtual machine or a storage account. Resources are defined using the resource keyword, followed by the resource type and name. Here’s a basic example of defining a resource in Bicep:
![Bicep Resource Simple Example]( "Bicep Resource Simple Example")
In this example, myStorageAccount is the name of the resource, Microsoft.Storage/storageAccounts@2021-06-01 is the resource type, and the object following the = sign contains the properties of the resource.
Using Bicep Resources
Declaration
The declaration of a resource in Bicep includes the resource type, name, and properties. Here’s an example of declaring a virtual network resource:
![Res Declaration]( "Res Declaration")
In this example, virtualNetwork is the name of the resource, Microsoft.Network/virtualNetworks@2021-02-01 is the resource type, and the properties object contains the address space of the virtual network.
Resource Name
The resource name is specified as the first argument in the resource declaration. It provides a unique identifier for the resource within the Bicep file.
Location
The location property specifies the Azure region where the resource will be deployed. It ensures that the resource is deployed to a specific geographic location.
Tags
Tags are key-value pairs that can be used to categorize resources in Azure. They can be used for organizing deployed resources, cost management, and other purposes.
Managed Identities for Azure Resources
Managed identities for Azure resources provide an identity for applications to use when accessing Azure resources. You can enable managed identities for a resource using the identity property.
Example
![Managed Identities]()
In this example, myAKSCluster is the name of the resource, eastus is the location, and { environment: ‘dev’ } are the tags. The identity is set to SystemAssigned.
Resource-Specific Properties
Resource-specific properties vary depending on the type of resource being deployed. For example, a virtual machine resource may have properties related to its size, operating system image, and networking configuration. These properties are specified within the properties object of the resource declaration.
The following example sets the access tier property for a storage account to “Cool” using the Bicep syntax:
![]()
Referencing an Existing Resource
Sometimes, you may need to reference an existing resource in your Bicep template. You can do this using the existing keyword. Here’s an example of referencing an existing storage account:
![Referencing an Existing Resource]()
Creating a Child Resource
Child resources are resources that are created as part of another parent resource. You can define child resources using the child keyword. Here’s how you can create a child resource:
![Creating a Child Resource]()
In this example, childResource is a child resource of parentResource.
Using Scope Extension Resources
Scope extension resources allow you to define resources that are scoped to a specific resource group or subscription. Here’s an example of using a scope extension resource:
![Using Scope Extension Resources]()
Managing Resource Dependencies
When deploying resources, it’s essential to ensure that certain resources are deployed before others. For instance, you must have a logical SQL server in place before deploying a database. This relationship is established by specifying one resource as dependent on another. The order of resource deployment is determined by implicit and explicit dependencies.
Azure Resource Manager assesses these dependencies and deploys resources in the order of their dependencies. When resources are not dependent on each other, the Resource Manager deploys them concurrently. Dependency definitions are only necessary for resources deployed within the same Bicep file.
Example
![Managing Resource Dependencies]()
The above code depicts dependency by referencing the nameServers property of the uniqueDnsZone resource in the customResource declaration. This means that the customResource depends on the uniqueDnsZone resource, as it needs the nameServers information from the DNS zone to function correctly. This dependency ensures that the DNS zone is created before the custom resource, fulfilling any prerequisites for the custom resource’s configuration.
Conclusion
Bicep resources are a powerful feature that simplifies the deployment of Azure resources. By defining resources in a declarative manner, you can easily create, manage, and reference Azure resources in your Bicep templates. With the examples provided, you should now have a better understanding of how to use Bicep resources in your own deployments.
Happy cloud building 😀
Want to know more? … get your fill-up here 🙂