Live data from Hacker News

Terraform Scripting Concepts

serdigital64.github.io

11–20 of 23 posts

Re: Terraform Scripting Concepts

#11
post #7
post #3

“script” seems like absolutely the wrong terminology for something as die-hard-declarative as Terraform. In my circle of engineers we tend to call it “code” but this isn’t ideal either - implies a general purpose language.

My circle also just use "code" as far as I'm aware, though I tend to think of it as a definition instead. Template would also fit but you can use templates within Terraform so that could be confusing.

The official name for .tf files is a “configuration”, per the code base.

Re: Terraform Scripting Concepts

#12
post #6
post #2

I hate seeing Terraform script or scripting . Am I the only one?

What do you think of Pulumi? My understanding is that this essentially uses TF as a backend

As a long time terraform user, I've been playing with a spare time project in Pulumi. TF and Pulumi share providers, but that's the extent of it.

My quick observations:

* It's nice to write TypeScript as the configuration language

* The provider documentation is poor and lacks the examples that terraform has, I find my self reading terraform documentation to understand how to configure Pulumi.

* You're constantly fighting with "async" vs "Input" vs "apply" when using a value, basic cases are handled in Pulumi but as soon as you want to do something complex you're toast. Maybe I just am doing it wrong, but that goes back to the lack of docs.

* How it handles dev/production/staging is just a little off from my expectations, not that terraform at it's core does this well either (why terragrunt exists).

Overall it's not bad, but it's not a silver bullet either to the typical problems. And suffers from a "small" community problem where you can't google solutions to problems with the same success.

Re: Terraform Scripting Concepts

#13
post #8
post #2

I hate seeing Terraform script or scripting . Am I the only one?

No you’re not the only one. The problem with Terraform “Scripting” is in a lot of cases it takes a loooong time to find out your “runtime” errors. These are typically fat fingered strings. I think something like AWS CDK, where you find these errors at compile, time is a better approach.

This already exists. https://github.com/hashicorp/terraform-cdk/

Re: Terraform Scripting Concepts

#14
post #3

“script” seems like absolutely the wrong terminology for something as die-hard-declarative as Terraform. In my circle of engineers we tend to call it “code” but this isn’t ideal either - implies a general purpose language.

`script` is bad, but `code` is fine. In this case, it is really a DSL language for cloud configurations.

Re: Terraform Scripting Concepts

#16
post #8
post #2

I hate seeing Terraform script or scripting . Am I the only one?

No you’re not the only one. The problem with Terraform “Scripting” is in a lot of cases it takes a loooong time to find out your “runtime” errors. These are typically fat fingered strings. I think something like AWS CDK, where you find these errors at compile, time is a better approach.

terraform really needs to be run in CI/CD pipe. Even without the backend initialized you can run terraform validate which will find things like undeclared variables and messed up count and foreach references.

Re: Terraform Scripting Concepts

#17
post #11
post #7

Earlier quoted context omitted.

My circle also just use "code" as far as I'm aware, though I tend to think of it as a definition instead. Template would also fit but you can use templates within Terraform so that could be confusing.

The official name for .tf files is a “configuration”, per the code base.

Which makes sense in the context of managing "configuration as code".

Once configuration is code, i.e. Turing complete, something has gone awry.

Re: Terraform Scripting Concepts

#19
post #17
post #11

Earlier quoted context omitted.

The official name for .tf files is a “configuration”, per the code base.

Which makes sense in the context of managing "configuration as code". Once configuration is code, i.e. Turing complete, something has gone awry.

Indeed - infrastructure being defined with a declarative model makes perfect sense. One need not use a DSL to achieve that though.

Re: Terraform Scripting Concepts

#20
post #8

Earlier quoted context omitted.

No you’re not the only one. The problem with Terraform “Scripting” is in a lot of cases it takes a loooong time to find out your “runtime” errors. These are typically fat fingered strings. I think something like AWS CDK, where you find these errors at compile, time is a better approach.

terraform really needs to be run in CI/CD pipe. Even without the backend initialized you can run terraform validate which will find things like undeclared variables and messed up count and foreach references.

But it won't find resource IDs being passed instead of ARNs, and a whole lot of other things.
Post reply on HN