Use Go Template as the template syntax for template_file data source

[russroy]

This is an enhancement request to change the template_file data source to use Go Template as its template syntax. This, of course, is familiar within HC suite for having been used within consul-template.

I believe this can help address a number of issues related to resource generation and nested looping (eg. #8573) and dynamic generation/manipulation of nested variables (map-of-maps, etc) while at the same time avoiding complexity in the TF core brought about by other proposals (such as #5278.) The template_file data source interface definition would not need to change to accommodate this. Within the template file itself one could still only have access to the variables defined in the vars section (as it is today) but have at hand the greater power of the Golang Template constructs (looping, conditionals, etc) for the actual rendering of the template.

Reference

Nested loops can be achieved with template_file as it exists today though only for simple cases. Here's one example:
https://serverfault.com/questions/833810/terraform-use-nested-loops-with-count

[apparentlymart]

Hi @russroy! Thanks for this suggestion.

We are aware of the limitations of the current template language. In fact, calling it a template language is generous, since it's really just the interpolation language from the rest of Terraform.

However, we do not plan to use the Go template language for this because it introduces a number of Go-specific ideas that are somewhat alien to Terraform, and in particular can't support Terraform's expression type system without heavy customization.

Instead, we are planning to extend the interpolation language to be a true template language as part of the currently-in-progress configuration language revamp. We decided to take this direction because it then also allows these new features to be used within interpolation strings in the main configuration too, and ensures that values will behave the same way in the main configuration and in templates. This is coming as part of the new parser that is currently code-named HCL2 (will become just "HCL" again when it's stable) and you can read about the new template syntax -- an extension of the existing interpolation syntax -- in its specification.

The work to integrate this new parser is in progress and will appear iteratively over a few different releases in the near future.

[serverhorror]

Is this the "master ticket" to follow this topic?
I'm really, really, really looking forward to be able to use conditionals, loops, ... and more rich data structures (lists, maps) in templates.
Pretty, please!

[alex-leonhardt]

@serverhorror I wrote a little thing about looping with the existing implementation - maybe this will help https://medium.com/ovni/terraform-templating-and-loops-9a88c0786c5c

also as I wasn't going to wait and actually quite like the idea of having actual go text/template at my disposal, I wrote this little gem : https://github.com/alex-leonhardt/terraform-provider-gotemplate .. hope this is useful in some way..

[apparentlymart]

Hi all!

Terraform 0.12 now includes template syntax, as I mentioned before. This extends the existing interpolation syntax to include conditionals and repetition.

The template_file data source has these new capabilities in the template provider versions 2.0.0 an later.

However, because these features are just part of the string template syntax built into the main language, you can just use them inline as part of an argument value if your "template" is relatively simple:

  user_data <<-EOT
    %{ for ip in aws_instance.example.*.private_ip ~}
    server ${ip}
    %{ endfor ~}
  EOT

For situations where a template is complex enough to warrant separating it into a separate file, Terraform 0.12 also introduces the function templatefile, which is essentially the template_file data source reworked into a built-in function. We recommend using this new function instead of the template_file data source for all new configurations targeting Terraform 0.12 or later, because that way the function call can appear closer to the context where the template will be used, and also crucially can refer to contextual values like count.index when needed.

Because the use-case represented by this issue is now met by these new features, I'm going to close this out. Thanks for starting this discussion!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.