Bicep Resources: What They Are and How to Use Them

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

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

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.

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 🙂

Understanding Bicep Resources

Using Bicep Resources

Declaration

Resource Name

Location

Tags

Managed Identities for Azure Resources

Resource-Specific Properties

Referencing an Existing Resource

Creating a Child Resource

Using Scope Extension Resources

Managing Resource Dependencies

Conclusion