Key Concepts in Azure Bicep Syntax

Azure Bicep is a great tool for Azure administrators and it is not difficult to learn. It provides a number of benefits for infrastructure as code:

1. Concise and readable syntax: Bicep offers a simplified syntax that is easier to read and write than traditional ARM templates, while still retaining the full capabilities of ARM templates.
2. Modularization: Bicep allows you to break down your infrastructure code into smaller, reusable modules, making it easier to manage and maintain.
3. Built-in and user-defined functions: Bicep provides a number of built-in functions that can be used to simplify common tasks, and also supports the creation of custom user-defined functions for more complex scenarios.
4. External references: Bicep supports the use of external references, allowing you to reference resources defined in other templates or environments.
5. Multiple deployment options: Bicep templates can be deployed using the Azure CLI, Azure PowerShell, or the Azure portal, providing a flexible and convenient deployment experience.

Azure Bicep Blog series:

To learn more about Azure Bicep, you can check out my other blog posts in this series:

Syntax

Azure Bicep uses a YAML-like syntax with indentation-based scoping. Here are a few key syntax rules to keep in mind:

Resources, parameters, variables, and outputs are defined using the resource, param, var, and output keywords, respectively. Properties are defined using a colon : followed by a value or a block of values enclosed in curly braces {}. Strings are enclosed in single quotes ‘.

Secure strings are defined using the securestring data type and are not enclosed in quotes. Lists are defined using square brackets [] and can contain values of any type. Objects are defined using curly braces {} and can contain properties of any type. Comments start with a # character and continue until the end of the line.

Resources

The core building block of an Azure Bicep template is a resource, which represents an Azure resource that you want to deploy. Resources have a type (e.g. Microsoft.Compute/virtualMachines), a name (e.g. my-vm), and a set of properties that configure the resource.

Here’s an example of a simple virtual machine resource:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

resource vm 'Microsoft.Compute/virtualMachines@2021-03-01' = {
  name: 'my-vm'
  location: 'westus2'
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_DS1_v2'
    }
    storageProfile: {
      imageReference: {
        publisher: 'Canonical'
        offer: 'UbuntuServer'
        sku: '20.04-LTS'
        version: 'latest'
      }
      osDisk: {
        createOption: 'fromImage'
      }
    }
    osProfile: {
      computerName: 'my-vm'
      adminUsername: 'azureuser'
      adminPassword: '<your-password-here>'
    }
    networkProfile: {
      networkInterfaces: [
        {
          id: nic.id
        }
      ]
    }
  }
}

This resource deploys a virtual machine with the name my-vm, using the Standard_DS1_v2 VM size, an Ubuntu Server image, and an admin username and password. The networkInterfaces property references a network interface resource, which is defined elsewhere in the template (not shown).

Parameters

Azure Bicep templates can also define parameters, which allow you to pass in values at deployment time. Parameters are defined at the top of the template and have a name, a data type, and an optional default value.

Here’s an example:

1
2

param adminUsername string = 'azureuser'
param adminPassword securestring

The first parameter sets a default value for the admin username, while the second parameter does not specify a default value and will prompt the user for a value during deployment. SecureString parameters are used to secure sensitive data.

Variables

Variables can be used to simplify expressions and avoid code duplication. They are defined at the top of the template and have a name, a data type, and an expression that defines the variable value.

Here’s an example:

1

var location = 'westus2'

Modules

Modules are a way to break down a large template into smaller, reusable parts. Each module is a separate Bicep file that can be deployed independently or used as part of a larger template. To use a module, you define a module resource in your main template and specify the path to the module file, as well as any input parameters that the module requires.

Outputs

Finally, Azure Bicep templates can define outputs, which are values that are returned after deployment. Outputs can be used to pass information between templates, or to display information to the user after deployment.

Here’s an example:

1

output vmFqdn string = vm.properties.osProfile.computerName + '.westus2.cloudapp.azure.com'

This output returns the fully qualified domain name (FQDN) of the virtual machine that was deployed in the previous example. The + operator concatenates the computer name and the region to create the FQDN.

Tools

To use Azure Bicep, you’ll need to install the Bicep CLI, which provides a command-line interface for working with Bicep files. The CLI can be installed on Windows, macOS, or Linux, and can be used to build, validate, and deploy Bicep templates.

Alternatively, you can use the Azure Portal or Azure DevOps to deploy Bicep templates without installing the CLI. The Azure Portal provides a graphical interface for uploading and deploying templates, while Azure DevOps provides a pipeline-based approach for deploying templates as part of a larger DevOps workflow.

I hope this overview of Azure Bicep has been helpful! If you have any more questions or would like to see more examples, please let me know.

To learn more about advanced concepts, check out the part 2: Advanced Concepts in Azure Bicep Syntax

Vukasin Terzic