Part 3 - Azure Bicep - Advanced Deployments with Bicep Modules
Part 1 - Azure Bicep - Introduction
Part 2 - Azure Bicep - Deploy your Fist code
Introduction
In this part of the Bicep series we will discuss how to perform advanced deployments using Bicep as an Infrastructure As Code DSL language, while shedding the light on Bicep modules.
Prerequisites
- We assume that your development environment is setup for bicep, (if you still did not setup your development environment please follow the instructions mentioned in Part-one
- We assume that you have minimum knowledge on how to deploy azure resources using bicep, you can follow the instructions in Part-two
The Regaton App
Let's consider a scenario where want to programmatically deploy and maintain the below illustrated application in your azure environment using bicep
Detailing the application components
As shown in the above diagram our application "Regaton" consists in the following main components:
- A Web Application
- An SQL Database
- A storage Account
Yes only three Azure services but why consider it as complex ?
Actually if we take a deep look we notice the following: - The resources are distributed between different resource groups, this actually means that our deployment include different targets.
- Azure services like the Azure SQL Database and the Azure Web app, depends on other type of services such as "SQL Server", and "App service plan" to be available therefore should also be deployed.
Authoring concept
Let's see how we can achieve our required deployment while meeting all the requirements.
If we were using ARM templates we would use either nested templates which are child templates that are written in the same template file or linked templates which are ARM templates stored in a remote location ( mainly a storage account) and referenced by their Template Uri in the parent template.
When the above options represent a valid solution, however they do also represent many challenges which are not simple to overcome. Fortunately these challenges were eliminated with Bicep modules.
Modularization
Bicep allows splitting your deployment code into multiple local bicep files to be consumed as modules in your deployment. We refer to this concept by modularization.
Modularization offers many advantages among the below:
- The ability of using existing written modules in different deployments while applying minor or i many cases zero changes to the existing code.
- Allows Masking the complex details from the parent bicep files as only parameters and outputs are required to be exposed.
- Most importantly allows targeted deployments to specific scopes (subscription, resource groups)
Deployment code structure
Inspite of the above mentioned facts our Regaton application deployment code will consists of the following:
- A main bicep file that will contain the main code which is responsible of calling multiple modules each module with aim to deploy a set of resources in a target location.
- While multiple parameters files can be used, deployment parameters will be stored in a single file and passed through the main bicep file to all modules.
Bicep modules in action
While the complete deployment code of the Regaton application is available for you in the following github repository CharbelHanna/Azure/Bicep. let's start exploring the main bicep file "regaton.bicep" to discuss in details how the different modules are consumed.
Taking a closer look on the selected code, we will notice the following:
- To consume a module the following syntax is used
module <modulesymoblikname> 'Modulepath' = {
name: <ModuleName> // the deployment name that will be logged in Azure activity logs
scope: <Deploymentscope> // specifying the scope where the deployment should take place
params: {
your parameters goes here
}
}- The deployment scope is defined by referencing the symbolic name of the resource group that was created earlier, for example stgrg for the storage account resource group "regaRG3"
- Outputs from different modules are passed as parameters to other modules
In order to configure the web app to use and connect to the storage account and SQL database that are being deployed, it is essential to get the outputs from the respective modules. This is done as following:
- Defining the output variables in the source module as below
Notice the cross reference that we are using to supply the value of the output variable storageEndpoint
- Passing the output as parameters to the destination module as below
notice the parameters value reference <Modulesymname>.outputs.<variablename>
Conclusion
In this series I tried to shed the light on Azure Bicep as a new DSL language and how it can be used for Azure deployments and the main Bicep features.
More details on how to move from ARM templates can be found here .
Tt is important to note that Azure Bicep is 100% supported by Microsoft and it provides Day 0 resource provider support. Any Azure resource - whether in private or public preview or GA - can be provisioned using Bicep.
Comments