Allow Compilation of multiple bicep files into a single template

[nbwdk]

Is your feature request related to a problem? Please describe.
Not being able to handle a central template store that can be easily be used and adopted by Dev teams, to build a baseline infrastructure.

Describe the solution you'd like
Would like to create single ARM template or template spec based out of a combination of bicep files.
This would make it possible to create standard templates per resource type or solutions by a central team. and then combined and build by each adoption team.

[anthony-c-martin]

@nbwdk - does the proposed modules spec cover your use case here? Is there anything you would want to change about / add to this?

[nbwdk]

It covers most of my use case. Only thing missing is the parameters file. If it is possible in any way to add this as well. Often a pre-defined parameters files is needed, because the ARM template takes a specific object is a param. An example of this could be an array of subnets for a virtual network arm template. The user of the arm template needs to know how the subnet resource is structured in order to create the correct param value. This is done for them in a pre-defined param file. This could be a comment with an example.

So same modularity for parameter files, to create a baseline or MVP for deployments.

[alex-frankel]

This is done for them in a pre-defined param file

If the ask is to continue supporting a separate parameters file, we will definitely do that. The current deployment clients support parameters files (e.g. az deployment create -f ./main.json -p ./parameters.json)

At some point, we'd like to have a "bicep-style" params file (#399) that feels more native.

[nbwdk]

The params have some default vales, but often needs to be overwritten by the user.

We have a library of pre-defined resources that can combined in any matter through a PowerShell script, into one linked templates with one parameter file.

This is an example of the as-is structure:

/Modules

• storagetemplate.json
• storageparameter.json
• keyvaultTemplate.json
• keyvaultParameters.json
• VirtualNetworkTemplate.json
• virtualNetworkParameters.json
• virtualMachineTemplate.json
• virtualMachineParameters.json

Example of to-be structure:

• MainTemplate.json
• MainParameters.json

This makes to easier to have a complaint set of templates that can be used by the adoptions teams. Knowing they only have to change one file prior to deployment.

This is the part I want to be part of the build process. Module fixes that for the templates, but not the parameter files.

[alex-frankel]

I see so in bicep, If I am calling let's say keyVaultTemplate as a module, you want to be able to call a file to pass the parameters for that module. Something like:

main.bicep:

module kv './modules/keyvault.bicep' = {
  parameters: './modules/keyvaultParameters.bicep
}

Is that the modularity you are looking for?

[nbwdk]

We are closing in. Maybe a quick call to clarify more precise would be needed here?

[alex-frankel]

That would be great - can you email me at [email protected] and we can set it up?

[aelking]

I am going through a similar issue at the moment.

I have had to write a powershell script to take the master parameters files for each environment and break it down into the parameter files for each resource type, as arm templates do not allow additional parameters to exist in the parameters file for deployment, and we have lots have shared parameters.

The orchestration of the environment is then done using Azure DevOps

e.g. Master Files
dev.parameters.json
prod.parameters.json

Resource Files
keyvault.template.json
keyvault.dev.parameters.json
keyvault.prod.parameters.json

[kilasuit]

@nbwdk are you wanting to compress all your files into a single template.json/template.parameters.json ??

@aelking the way I get round this is to have a master controller template for dev/prod that sets all the parameters needed as a variable and not bother at all with any .parameters.json files & just require an object to be passed to each sub template as this allows reuse on cmdline and in other tempates without additional files always being needed as you can pass the object needed through to the lower level templates and optionally can manipulate this with other tooling like PowerShell as required.

[SabapathyKannappan]

Is there a way to refer/include a resource declared in one bicep file into another? kind of import of one bicep to another bicep ?

[alex-frankel]

Modules are the only way to achieve what you are describing today. If you need a resource reference, you can use the existing keyword.

We have a proposal (#2245) we are trying to get done for v0.5 that will allow you to properly pass resources between modules.

[piquet-h]

I'd like to see specific inclusion as opposed to separate nested deployments also.

A full inclusion means the 'Complete' deployment mode makes sense. Currently, it's only complete on the outer deployment, while the nested ones are always incremental. This is counter intuitive.

If it was a full inclusion, rather than reference, then 'Complete' would apply to all, deleting resources that are no longer in the template. This would make it significantly closer to a "make it look like this infrastructure code" style of deployment.

[JanuszNowak]

Was looking also for option for this, so up voting.

[sb1975]

I see so in bicep, If I am calling let's say keyVaultTemplate as a module, you want to be able to call a file to pass the parameters for that module. Something like:

main.bicep:

module kv './modules/keyvault.bicep' = {
  parameters: './modules/keyvaultParameters.bicep
}

Is that the modularity you are looking for?

Is there a plan to support something like below, this will help to deploy nested modules with their own parameters file. In large deployments this seems like a very useful feature please .

module kv './modules/keyvault.bicep' = {
parameters: './modules/keyvaultParameters.json
}

[mrvamsidhar]

@sb1975 I am looking for similar feature. Is there any update on this?