Terraform Scripting Concepts | Hacker News Reader

Terraform Scripting Concepts

serdigital64.github.io

39 pointsserdigital6422 comments

“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.

Comprehension, like list comprehension, might be a better term

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.

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

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

model

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

nope.

What do you think of Pulumi?

My understanding is that this essentially uses TF as a backend

This = Pulumi?

It doesn't use TF as a backend. It builds on top of Terraform providers in many cases.

Your understanding is wrong. The CRUD logic of some commonly used providers is based upon that in Terraform providers, but the TF engine is not used by Pulumi.

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.

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/

I wasn't aware of this and I'm glad to see they're doing it. But my guess is this is a relatively recent offering in response to the AWS version and the issues I was mentioning.

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.

terraform actually has `local-exec` which is doing the scripting part, calling terraform scripting is very wrong.

I suppose one could use terraform with local-exec provisioners and lifecycle blocks to mimic a make. I don’t think it’s a good idea though.

Maybe "desired state configuration" ... Terraform DSC ... Like PowerShell DSC

Reply on news.ycombinator.com