Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform 1.0

github.com

Post reply on HN
Print view View original

281–290 of 315 posts

Re: Terraform 1.0

#281

Post by zymhan »

endymi0n wrote: post #209
saurabhnanda wrote: post #208

I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…

You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!

My experience is that it was definitely a foot gun.

There are too many ways to write fancy abstractions that are unreadable or not extensible, for example.

Re: Terraform 1.0

#282

Post by PostThisTooFast »

jansan wrote: post #42

Can someone explain in a few words what this is and who may be interested in this? The name does not give any hints, also the discription tells me nothing: "Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned…

Of course you got modded down for a completely civil and rational comment.

This title, and all titles like it, are DOUCHEY. Learn it. Know it. Live it.

Re: Terraform 1.0

#283

Post by ncmncm »

solatic wrote: post #159

Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…

'Fraid you lost me at "YAML". Anything built on YAML seems like it has to indicate bad judgment at the root.

There could be reasons, but I don't know them.

Re: Terraform 1.0

#284

Post by zbentley »

throwaway894345 wrote: post #238
kortex wrote: post #181

Earlier quoted context omitted.

Ah, so like you have some process which generates your YAML/HCL, which is your "IR/assembly" layer, not meant for regular human consumption/editing, which is fed to Terraform. But it's readable/auditable, VCS-trackable, and diff-able. I do that a lot as well and in fact I'm kinda leaning towards taking that approach from the get-go. Right now I start with the YAML, but then something makes inevitably leads me to temp…

Yeah, in the Kubernetes world, the official interface is the YAML/assembler and different people have come up with different approaches for generating that. Helm for a long time (and even currently) uses text templates (e.g., jinja, mustache, etc) to render that YAML which is predictably abysmal. CloudFormation used JSON (and eventually YAML) but built on top of it language-like facilities (the ability to reference r…

That's an accurate summary of the arc of progress in this area. Also explains why so many folks are now turning to operators (versioned procedural code that runs in k8s and does arbitrary things, rather than arbitrary versioned yaml artifacts applied to k8s) to do advanced stuff rather than layering on more templating duct tape.

Re: Terraform 1.0

#285

Post by zbentley »

throwaway894345 wrote: post #107
MadVikingGod wrote: post #84

Earlier quoted context omitted.

Dang, your solution sound so much like kubernetes I'm not sure if you are joking or not.

Kubernetes is one conceivable incarnation, but it operates differently than other infra-as-code tools. Terraform, for example, builds a dependency graph of your resources and initializes them in order. Kubernetes doesn't care about dependencies, and it just keeps trying to create resources and things will fail until their dependencies come online. Further, Kubernetes manifests are the verbose "assembly language" laye…

> Kubernetes manifests are the verbose "assembly language" layer, so you still need something for humans that is DRYer.

It's a little more than that. Out-of-the-box manifests for primitives are certainly assembly-like, you're right--but CRDs allow you to operate at a higher level of abstraction while staying in the same syntax, which is powerful and unique to k8s (everything else, from Helm to Terraform to Ansible, distinguishes between pseudo-assembly "language that directly expresses changes to be made" and "language that humans can write abstractions in").

Re: Terraform 1.0

#286

Post by saurabhnanda »

zymhan wrote: post #281
endymi0n wrote: post #209

Earlier quoted context omitted.

You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!

My experience is that it was definitely a foot gun. There are too many ways to write fancy abstractions that are unreadable or not extensible, for example.

What is a foot-gun? Ansible/Terraform, or the library approach that I'm describing?

Re: Terraform 1.0

#287

Post by tehbeard »

hpoe wrote: post #245
majormajor wrote: post #231

Earlier quoted context omitted.

My problem with this approach is that it's still too much "infrastructure as data" and not "infrastructure as code." Moving infrastructure data into flat files is not a clear-cut win over having it in a database - you get easier version control with external tools like git, but you everything that makes a database a joy to work with instead of flat files, like schema validation and easy queries, etc. Things like for_…

But at the end of the day your infrastructure is essentially data not code. Your infrastructure is permanent, it exists even if it isn't being used it has inertia. At the end of the day your "infrastructure" is really just an entry in a database of a cloud provider, it is data not code. I think we are seeing things come full circle again where people are finding the limitations of declarative infrastructure tools and…

Side tangent, but I'm curious as to why you list Ansible as imperative, when it seems to be declarative in how you configure a module?

Or is this a case of scope? (At the level of a single ansible module, it's config is declarative, but runbooks/roles are imperative? Is it the variable substitution/loop mechanics that make it imperative?)

Re: Terraform 1.0

#288

Post by ranguna »

endymi0n wrote: post #209
saurabhnanda wrote: post #208

I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…

You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!

You also have terraform cdk, which is currently in beta.

Re: Terraform 1.0

#289

Post by polynomial »

jen20 wrote: post #178
lvncelot wrote: post #121

Earlier quoted context omitted.

> You can feed JSON to Terraform however this falls over if you need dependencies for output values This is what I've started doing with Jsonnet for generation, and also exactly why I've stopped doing it.

I'm not sure I follow exactly what you're missing. `${aws_instance.example.x}` as a string value creates the same dependency as it would via HCL when used with JSON.

Same here, I don't see how outputs is being treated any differently by Terraform than any other .tf file written in HCL. I'm not saying it's not possible, but I haven't experienced a failure more there yet.

Re: Terraform 1.0

#290

Post by polynomial »

ManWith2Plans wrote: post #40
tonyhb wrote: post #36

Earlier quoted context omitted.

I don't know if people have even tried Pulumi before recommending it. I've tried it, and it has buggy defaults, diff generation, etc. Each time I applied the same code, it would generate a diff based off of some internal defaults and... recreate the exact same infrastructure by _tearing it down_ and making it fresh. Not ideal. Would advise using the TF CDK specifically.

The token system is broken in TF CDK still and it's not ready for adoption. I've built two stacks with it but I'm back at terraform for now. I intend to explore pulumi though when the opportunity presents itself. I think using a Turing-complete language like typescript with mature tooling to define cloud infrastructure feels very natural and makes things much more manageable than using HCL. One thing I absolutely can…

> This is absent from terraform-cdk

Curious to know how that is, or what an example would be? I don't see how you would have to give up state management with CDK, which I understand to be extending TF, not supplanting it.

Post reply on HN