Improve Bicep Module Structure

[ranadeb-pramanick]

Hi ,

I started looking at bicep modules , and i feel that it could do some improvement. The current bicep module refers to a "single" .bicep file and we have to refer to this file from the main.bicep file. Currently since modules can refer to a single bicep file, it will lead to either stacking up a lot of resources in a single bicep file, or we will end up creating a lot of modules ( module explosion) which eventually needs to be called from main.bicep file. What i suggest is to expand the scope of a module to a "folder" containing not 1 but multiple .bicep files ( just like HCL does it for terraform) which will stitched up together at runtime . This will allow us to split resources across multiple bicep files, and create modules which are more elaborate.

[brwilkinson]

Hi @ranadeb-pramanick

Do you have any sample bicep modules that you are using ? or more examples related to your question ?

A few notes:

• the main bicep file can have any name, it doesn't have to be called 'main.bicep'.
• a module is just another bicep file. So you can either deploy the module directly or reference it from a parent bicep file.
• you can keep multiple bicep files in the same directory, you don't need to nest them in their own directory.
• you will have to find the best way to organize them to meet your project requirements.

I am currently keeping all of my bicep files in a single directory and attempting to use a naming standard to differentiate the usage of each bicep file.

https://github.com/brwilkinson/AzureDeploymentFramework/tree/dev/ADF/bicep

The main types of categories that I am using so far are:

• orchestration bicep files e.g. 00-ALL-SUB.bicep or 01-ALL-RG.bicep
• resource/provider bicep file (likely how you think of a Module) e.g. VNET.bicep
• child/nested bicep modules e.g. VNET-Peering.bicep or VNET-PrivateLink.bicep * note these get called from VNET.bicep
• helper bicep modules e.g. x.publicIP.bicep or x.vNetPrivateLink.bicep
• helper bicep module that doesn't create any resources e.g. y.disks.bicep

[brwilkinson]

@ranadeb-pramanick would be interested to continue the conversation with you on this, to make sure we can get all your ideas and share these concepts if there are any gaps in the current capabilities of how Bicep currently works.

If you were able to share a preferred architecture or your preferred file layout etc. that would be most helpful to discuss.

[brwilkinson]

One additional note, if you take a look at: 00-ALL-SUB.bicep

This is a Bicep file, equivalent to a module or also a standalone file (what you referenced as main.bicep), that can call other Bicep modules

E.g.

• RG
• RBAC
• RoleDefinitions

Those modules can be called from that parent file or directly/individually. Calling them all together from the parent also allows any dependencies to be added.

[brwilkinson]

Here is the latest information on the Bicep Module Registry, this will be an alternate method to Publish/Share/Consume Bicep Modules

https://www.youtube.com/watch?v=Bx250Y-wTjY&t=1840s

[ranadeb-pramanick]

Thank you for your response. I now have a better idea about bicep modules.

[brwilkinson]

Thanks @ranadeb-pramanic

I'll mark this as answered for now. If you have any other ideas or improvements for Bicep, we will look forward to hearing from you.