-
Notifications
You must be signed in to change notification settings - Fork 759
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support to split template into multiple files? #363
Comments
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? |
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 :) Modules on the other hand, are really more about re-using. |
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? |
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. |
Some use cases I would use splitting:
|
Splitting and loading bicep files would be very useful feature.
Also it would allow for modularity. |
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. |
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 |
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. BTW I was already toying with ARM JSON files generation a few years ago leveraging Jinja2 :) |
This would be great if we could split out Bicep files like that! Any news on this? |
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) |
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 |
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. |
@alex-frankel Is this still being considered? One of our customers is hitting the limit and wants to know if there are any solutions. |
@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. |
Would be very nice to split up NSG rules, Sentinel rules or Firewall rules (1 rule = 1 file). Also Azure workbooks, as already mentioned. |
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:
The text was updated successfully, but these errors were encountered: