With Bicep there is a new DLS in town for Azure deployments.
It sits on top of ARM templates and allows declarative deployments which enables easier reuse of components and makes the templates more readable.
Whereas ARM templates are gigantic json files that are hard to read and even harder to maintain, Bicep promises to simplify much of that:
- Bicep is much smaller in size as it replaces all the json boilerplater with a DSL
- Bicep allows splitting individual components into different files, allowing multiple templates to reuse the same components (in a much better way than nested ARM templates ever could)
- By being a transparent abstraction over ARM it doesn’t lack the latest features anytime now services are released (looking at you Terraform)
- Further because Bicep is transpiled into ARM it also allows the reverse: take any existing ARM template and quickly turn it into a Bicep file. This makes getting started super easy!
- All the native tooling that has been built around ARM still works
Currently there is a CLI and Visual Studio Code extension to get started. And as of version 0.3 (v0.3.1 really) Bicep is not only supported under Azure support but it is also natively integrated into Powershell (v5.6.0+) and Az commandline (v2.20.0+).
This means you can take any existing command like
az deployment group create -g $ResourceGroup -f ./deploy.json
and turn it into:
az deployment group create -g $ResourceGroup -f ./deploy.bicep
Of course to get there you first need to create your bicep file. Luckily the tooling has built in decompilation from ARM templates so you can start from your existing ARM template.
bicep decompile deploy.json
to turn any existing ARM template into a Bicep file.
Note that the decompilation still has issues with more complicated templates and a few features are not yet supported.
The decompilation works straight away and what you’ll find is that the Bicep file is much easier to read and even slightly smaller than the json file.
Since the tooling supports bicep natively (ARM template are generated on the fly) all the known workflows for deployments (as well as diagnostics tooling and logging) remains the same.
Deploying a bicep file is now as easy as:
az deployment group create -g -f ./deploy.bicep
You don’t ever have to look at an ARM template again and can simply use bicep files from now on (if you want to).
Of course if you need to take a look at the ARM template you can simply generate it:
bicep build deploy.bicep
As mentioned in the beginning you can separate various components into their own files and reference them from your main file. This is helpful if you have common patterns (e.g. webapp + app insights + CDN) that are reused across your project/organization or if you want to enforce certain component configurations across your team/organization. You can package them up into individual bicep files and anyone can reference them from their main bicep file. The tooling simply takes care of merging the files back a single ARM template for deployment under the hood.
This makes code reuse super easy compared to native ARM templates and I can definitely see myself using bicep for all my infrastructure deployments in the future as they are much easier to write than ARM templates!
Deploying with github actions
Currently there is no github actions that directly deploys your bicep file (but it’s planned).
I tried deploying using a simple az cli script as soon as v0.3 was released but initially there was a bug which is fixed now.
So deployment in github action is straightforward as well:
- name: Azure CLI ARM deployment uses: azure/CLI@v1 with: inlineScript: az deployment group create -g $ResourceGroup -f ./deploy.bicep
Take a look at host-merger which I already upgraded to use bicep.
I’ll definitely upgrade all my ARM templates to use Bicep in the future!