Azure / bicep

Bicep is a declarative language for describing and deploying Azure resources
MIT License
3.21k stars 745 forks source link

Support to split template into multiple files? #363

Open sebader opened 4 years ago

sebader commented 4 years ago

Have you thought about supporting splitting one bicep files into multiple files within the same directory and merging them on build? I find this a very neat feature in terraform to make larger templates with many resources easier to read - without using modules, that is a different use case for me.

Like:

storageaccounts.bicep
sqldb.bicep
keyvault.bicep

bicep build .
==> my_combined_arm_template.json
alex-frankel commented 4 years ago

Makes sense - it is something we are considering.

Out of curiosity, when do you decide to split code in this way vs using a module?

sebader commented 4 years ago

When working with Terraform I actually do it basically every time. No matter how big or small the project is. I don't know if that is best practice with TF but I would say it is rather common. Happy for other people to comment on this :) There I usually do use one file per resource type. This is really mostly to keep an easy overview. Instead of scrolling up and down through a long template, you directly navigate to the file, e.g. for all the storage accounts.

Modules on the other hand, are really more about re-using.

segraef commented 4 years ago

Basically it is a good idea to be able to split files. Be it for an overview, for categorization or just for a better handling. Instead of splitting and simply pointing to a module (or in YAML to a template) is similar but as @sebader already said, modules are more for reusability, scaling and containibility of complexity.

For me root ARM templates linking other child ARM template is almost the same pattern like Terraform root modules (main.tf) referencing child modules.

To be honest, splitting and branching files is a part I don't really like in Terraform but that's just my opinion. But it's also a part of the reason why everyone thinks that JSON ARM files are too big and complex because everything is in a file that has 1000 lines. But let me ask the question differently, what is better, endless switching between folders and subfolders like Terraform or just switching between lines in a file?

sebader commented 4 years ago

But let me ask the question differently, what is better, endless switching between folders and subfolders like Terraform or just switching between lines in a file?

Different people have different preferences - and that's ok! If we would offer the possibility to split files, nobody would be required to do that (just as in Terraform) - but you could if that's what you (and your team) prefers. If we as Microsoft should then recommend one way or the other, that's a different discussion I think.

jikuja commented 4 years ago

Some use cases I would use splitting:

JayDoubleu commented 4 years ago

Splitting and loading bicep files would be very useful feature. As well as functions to load external files and preparing payloads using the bicep language. Similar to terraform:

Also it would allow for modularity.

takekazuomi commented 4 years ago

Sure, merging local files is a good feature. Take it one step further and support remote git files. That way we can get versioning too. Versioning is a must if you use the bicep file like a module.

beneshed commented 3 years ago

Seconding this and also liking to add that this would be nice with modules.

For readability it would be nice to seperate a module into a folder with

resource.bicep params.bicep variables.bicep outputs.bicep

sebbrochet commented 3 years ago

It's a bit unfortunate, ARM JSON files interpreters don't support natively JSON Pointer (RFC 6901) (while we could probably imagine a pre-processor addind it!).

I had recently to compose a lot of JSON "definition" files (of my own) into a single object structure before loading them in memory. And JSON Pointer definitely helped me managing complexity while being able to check consistency as part of my unit tests.

BTW I was already toying with ARM JSON files generation a few years ago leveraging Jinja2 :) But as it's only "syntactic macros", a lot of semantic issues are not detected as they should and are with something like Bicep...

jfe7 commented 2 years ago

This would be great if we could split out Bicep files like that!

Any news on this?

TazzyMan commented 2 years ago

Like I said in issue #7726 I would then also like to add parameters and expressions (to do some string manipulation if needed) to add re-use value (predefined template files for several resources with all the properties that are always the same in your organization)

enbridgeint commented 1 year ago

Good Ask....For me I want parameters in a file and remaining code in another file. is it possible?

I have n number of resources to create, so it will be good and traceable if we have different file param and different file for resources/modules

SPSamL commented 1 year ago

When using Terraform, this template was the initial setup of other organizations', or tenants', spoke subscription. It deployed a core set of resources to integrate with the common services/hub subscription. They're split mostly by resource type plus Data Sources (Existing resources in Bicep), outputs, providers, and variables (Bicep Parameters). It was deployed by the same team every time. Modules are overkill for the resource types with multiple instances because they had different requirements for configurations such as 3 different Key Vaults: 1 for Customer Managed Keys, 1 for Certificates, and another for Secrets. They each had a specific set of access for the service account creating them and their secrets/keys/certs and different network restrictions. I simplified it down to a handful of variables/parameters that were required for each to basically just the name and location. The *_permissions were the same for each tenant.

It's also easier for the team, which I've left, to maintain or update than as a single file which would be around 2000 lines of code.

image

Lddeiva commented 1 year ago

@alex-frankel Is this still being considered? One of our customers is hitting the limit and wants to know if there are any solutions.

alex-frankel commented 1 year ago

@lddeiva - it's not being actively considered. Having said that, I don't think if we implemented this it would address the limit you are talking about. I am assuming you are talking about the 4MB template size limit? We have a separate work item to try to get that limit raised.