Comments (15)
This comment was originally opened by @errordeveloper as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
In one instance I have implemented a shell script that looks rather quite ugly for what it's able to do. It is being called from infra/main.tf#L44
and main.tf#L126
.
from terraform-provider-template.
This comment was originally opened by @errordeveloper as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
I should also clarify that in my use-case it's CoreOS that is being provisioned, and many other folks would probably suggest that a configuration management tool is what I want. However, I believe that this this kind of mechanism would be of use when one needs to seed the initial configuration files for their configuration management tool to run.
from terraform-provider-template.
This comment was originally opened by @apparentlymart as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
It could be nice to use the same template language as consul-template, but with access to Terraform resources and variables within the calling module rather than access to Consul concepts like services and keys.
This could then allow Terraform provisioning to do the same sorts of things consul-template does, but for configurations that only vary per-deploy, rather than those that can vary at runtime. Having the template be able to access the resources directly means being able to easily iterate over list attributes and resource wildcards, which wouldn't be so easily to achieve with the explicit variables map in the existing template implementation.
Example haproxy template fragment, based on the one for consul-template:
listen http-in
bind *:{{var "load_balancer_listen_port"}}{{range resource "aws_instance.server.*"}}
server {{.id}} {{.private_ip}}:{{var "server_instance_listen_port"}}{{end}}
Of course, to achieve this would require a rather unusual resource type whose dependencies are defined by the contents of the external template file, rather than by interpolations within the resource definition itself.
from terraform-provider-template.
This comment was originally opened by @mitchellh as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
I think we should just extend the template_file
resource to support a type
parameter that specifies the template type and we can support a variety there.
from terraform-provider-template.
This comment was originally opened by @errordeveloper as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
Yes, 👍, as long as there is a way of saying that "here is a file that needs to be processed in some way before it can be used". May be the types will have to declared somewhere, so user sees "You need tool foo to run this", instead of "foo: command not found" or something totally weird.
from terraform-provider-template.
This comment was originally opened by @progrium as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
template_file
with a way to provide types would be nice, but ideally if shell
were one of them. Or perhaps support https://github.com/gliderlabs/sigil directly? We could probably do either or both as a PR depending on what sounds right.
from terraform-provider-template.
This comment was originally opened by @7heo as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
@mitchellh 👍 that would be really great.
from terraform-provider-template.
This comment was originally opened by @ketzacoatl as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
Saltstack makes the template/rendering engine plugable, so users can pick which renderer to use - it has worked out very well in practice and I believe that would be a great addition to Terraform's template provider!
from terraform-provider-template.
This comment was originally opened by @lbernail as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
A richer templating engine would definitetly help!
👍
from terraform-provider-template.
This comment was originally opened by @errordeveloper as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
We had been using Jsonnet in Kubernetes Anywhere project, and it provides quite a few extra features for generating Terraform JSON then HCL does, it also have richer tooling for inlining plain text files, escaping JSON and rendering templates etc.
If you create a file named hello.txt
with the following content:
Hello, my name is %(name)s, I am %(age)d years old.
you can import it from hello.jsonnet
using importstr
and substitute age
and name
variables from a dictionary to create an object with a meaningful message:
{
message: (importstr "hello.txt") % {age: 25, name: "Rose"}
}
Run jsonnet hello.jsonnet
and you will get:
> jsonnet test.jsonnet
{
"message": "Hello, my name is Rose, I am 25 years old.\n"
}
There other nice methods like std.escapeStringDollars
and std.escapeStringBash
.
from terraform-provider-template.
This comment was originally opened by @errordeveloper as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
Please note, that with Jsonnet you would still make some use of Terraform interpolation, but only in case where you have to enforce dependencies. I think this is something worse documenting a bit more. Unlike some other kind of methods one could find for generating Terraform code, Jsonnet still keeps it declarative.
from terraform-provider-template.
This comment was originally opened by @flypenguin as hashicorp/terraform#1845 (comment). It was migrated here as part of the provider split. The original comment is below.
I'd also go for @apparentlymart's suggestion to use the consul templating languate. Make Hashi products consistent, and while it might not be the most intuitive one, it's "part of the family", already out there and being used.
from terraform-provider-template.
I support suggestion from @ketzacoatl to "make the template/rendering engine plugable" in terraform. This means designing for provider plugin abstraction within TF.
@apparentlymart suggests using Consul templating engine. I personally use jinja2
with saltstack (and nunjunks
with expressJS). The suggestion of a plugable provider interface facilitates everyone who has opinion on the topic, and allows users to bring their templating preference to TF.
from terraform-provider-template.
Hi all,
Since this provider uses the syntax from Terraform's existing expression interpolator, it will get more features in the release of this provider that accompanies the Terraform Core 0.12 release, including what's described in our preview article.
This doesn't mean that we can't/won't also support other template engines here, but at least the current built-in one will have support for conditionals and iteration, and will thus meet most of the use-cases we've seen.
However, on the topic of making the template engine pluggable, I expect if we were to go down that road we'd probably just say that each template engine ought to have its own Terraform provider, since that's a plugin mechanism that Terraform already supports and it seems unnecessarily confusing to have this template
provider also have its own separate level of plugins, which we'd then need to have a mechanism to find and install, etc. template_file
would then be specifically for Terraform's template engine, with other engines each having their own providers.
It's already possible to write a Terraform plugin for any template engine you like as long as there is a Go implementation available for it. A challenge is that Terraform passes data to plugins in terms of its own type system (rather than Go's type system) and so it'll probably require some marshaling effort to prepare the incoming data for what another Go-based template system is expecting. The template
provider avoids this because it's using Terraform's own language, and thus it already natively supports all of the types Terraform does in the representation Terraform uses, but such conversion is technically possible and mainly consists of just figuring out what is the most intuitive mapping for good usability.
For example, someone could in principle write a pongo2
plugin for Terraform which offers a pongo2_template
data source that renders templates using pongo2:
# not yet implemented
data "pongo2_template" "example" {
template = "${file("${path.module}/example.tmpl")}"
vars = {
foo = "bar"
}
}
Once hashicorp/terraform#15252 is implemented (design effort for which is getting underway), it would even be possible for this to be done entirely by a third-party, though that doesn't mean we wouldn't consider bringing it into the terraform-providers
set if there were enough demand once it is written.
from terraform-provider-template.
Yes, and yes, that all sounds reasonble and great. Very excited for the changes coming in 0.12 and seeing how that opens some of these doors.
from terraform-provider-template.
Related Issues (20)
- Template 2.0.0 tries to interpulate percent (%) signs followed by curly-braces {} HOT 3
- Breaking change in substitution in v2.0.0 HOT 1
- Extremely unprofessional backward incompatible release HOT 1
- The new 2.0.0 doesn't parse %${var} core HOT 6
- Make Terraform validate template_file on plan phase
- Feature request: Render variables in filenames in template_dir
- Template provider - Better error message at template parsing HOT 2
- Terraform template creating the wrong type of numbers HOT 5
- template_dir doesn't work on Terraform v0.12.4 HOT 2
- template_dir doesn't skip hidden files HOT 1
- [regression] provider-template fails rendering when template file has % in the content starting from v2.0.0 HOT 3
- go module uses invalid version HOT 4
- Passing Lists as Template Variables HOT 2
- template_dir can't handle subdirectories correctly on windows: open <filename>: The system cannot find the path specified.
- depends_on should wait for template_dir generation HOT 3
- Provider cannot be migrated to terraform-plugin-sdk as it uses `lang` pkg directly
- Terragrunt panic due to api body size. HOT 2
- Unsupported functions in template file HOT 1
- Changes from nearly a year ago not published
- Provider archived
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terraform-provider-template.