Hello Cloud Marathoners,
The infrastructure-as-code (IaC) is not a just a “buzzword”, it is brought by a necessity to manage your digital estate more predictably while source-controlling the changes that are introduced over time. In its turn, this approach makes it easier to keep your workload environments compliant and saves ton of time in troubleshooting, development and auditing your resources
In this post, we will look into the necessity of child resources in Azure and how Bicep language simplifies their management and declaration as a code.
why azure bicep child resources?
There are a number of scenarios where it makes perfect sense to declare resources within the context of their parent. For example; storage blob containers could not be declared and used without a parent storage account.
In addition to Blob containers, there are many other child resource types in Azure like:
- Virtual network subnets
- SQL databases
- Azure Cosmos DB containers
- SQL databases
- VM extensions
How could you define child resources?
Unsurprisingly, there is more than one way to define Azure Bicep child resources. Each approach will depend on a specific use case that you or your team is looking forward to delivering.
Further we will use the example of a storage account resource to describe different options of child resource declarations. This will make it easier to describe the concepts and available options to you. However, these concepts could be easily used on other Azure services like VMs and VNets that do have child resources too.
All the options and sample codes are available on Learn-Bicep GitHub repo page.
Option-1 : Child resource created with reference to parent
Our first option is declaring a child Blob container resource as a separate independent resource with a reference to a parent resource. Like, it is illustrated on the example screen-shot from the Learn-Bicep repo.
For this option to work, we would need to declare an Azure Storage Blob service too. Let’s look into how it could be done while considering a second option.
Option-2 : Including a child resource in the declaration
Our second option is declaring a Storage Blob service resource as a separate independent resource with a reference to a parent Storage Account resource. Then it has an inner declaration for a container child resources within the Storage Blob service.
Let’s look at the example screen-shot from the Learn-Bicep repo.
This option might be an ideal approach if you have few child resources in your declaration. However, it would not be the most efficient one to use, if the number of child resources you are required to deploy is in dozens, hundreds or even thousands.
Option-3 : Automation and looping with enumeration 🙂
The final option will serve you well, if you have 100s of pre-defined containers that should be deployed into your Azure environment.
By leveraging the “iterative loops” in Bicep we can easily iterate over these containers while creating them in a compact and repeatable manner, like in the following screen-shot from the repo code.
Looking for more Bicep goodness?
A community of developers and engineers started a great initiative – to help everyone to learn Azure Bicep for #free by sharing & contributing to the AWESOME-Azure-Bicep GitHub repo.
Please, like ⭐ subscribe 🍴 & fork it 👍
As always #SharingIsCaring
summary
In this post, you have learned about three different options to declare Bicep child resources.
All code samples and presented Bicep files are placed in “Learn-Bicep” GitHub repo 👉 https://github.com/ElYusubov/Learn-Bicep/blob/main/samples/14-deploy-child-parent-scenarios.bicep 👍
Would you be interested in a recorded short video that demonstrates these capabilities ?
