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

161–170 of 315 posts

Re: Terraform 1.0

#161

Post by BigGreenTurtle »

polskibus wrote: post #128

Does anyone use terraform for onpremise clusters? If so, what is your setup, what hypervisor do you use it with? Are you happy with it? Or maybe you would rather replace it with a set of ansible roles?

We use it for provisioning vsphere VMs with all of the provisioning done through cloud-init. Can't say I like cloud-init but our onprem stuff is pretty simple and almost all of the VMs can be rebuilt if a change is needed so it works well enough but I'd probably use ansible if I were starting new.

Re: Terraform 1.0

#162

Post by mhitza »

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…

For me it's less about HCL annoyance nowadays, but more about discoverability. Using Pulumi I no longer have to memorize resource properties because I get IDE autocompletion.

Re: Terraform 1.0

#163

Post by Pet_Ant »

throwawaygo wrote: post #81
cube2222 wrote: post #2

An interesting document is also what is actually covered by the 1.0.0 compatibility guarantee: https://www.terraform.io/docs/language/v1-compatibility-prom...

The v1 guarantee is they will break your code at anytime just like before v1.

That is an unfair characterisation of the policy in the link. It is not quite clear which subsets they are talking about at times, and it's definitely not complete but there is an effort there and it looks like most cases (by volume of usage) will be unaffected;

> The Terraform v1.x series will be actively maintained for at least 18 months after v1.0.

Re: Terraform 1.0

#164

Post by basilgohar »

u678u wrote: post #154

One afternoon with Terraform and you'll want to give up cloud and get your own datacenter again.

I have a highly fuzzy result in my sarcasm detection here.

It's because I can understand this to mean either that:

1. Terraform is so difficult managing cloud services that you'll give it all up and run for the hills of bare metal once again.

- or -

2. it's so good you'll want to swear off the cloud providers and switch to running your own infra using Terraform and not the cloud services own tools.

Given other comments I can easily see this going both ways.

Re: Terraform 1.0

#166

Post by ciisforsuckas »

samsquire wrote: post #38

There is a dupe Terraform post on Hacker news frontpage. I'll post my comment here too :-) I recommend breaking out your terraform code into separate folders and calling them "components". Write a wrapper around the terraform script to pass in -var-file which uses an argument called ENVIRONMENT that you pass to the wrapper. I think the built in support for modules is less useful for what you actually want to do becau…

I've been using Terragrunt to keep my Terraform DRYU in a similar manner. It's a bit of a rethink in how you structure things but I've been happy so far.

https://terragrunt.gruntwork.io/

Re: Terraform 1.0

#167

Post by Thaxll »

rantwasp wrote: post #35
nautilus12 wrote: post #29

You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.

your company sounds like they know what they are doing. Cloudformation will take your infrastructure from point A to point B or roll it back in case of failure. Terraform, not so much.

> roll it back in case of failure

Until it doesn't. How many times I've seen stack being in error because could not rollback.

CF can't do trivial things like creating a resources in account A that is needed for account B.

Re: Terraform 1.0

#168

Post by nprateem »

ekimekim wrote: post #126
kevincox wrote: post #52

Earlier quoted context omitted.

100%. Terraform is half-way between a tool for generating the configuration and applying it. I think Terraform's application engine is actually quite good, but I would like to use a much better tool to generate the config. (And be able to diff that config) You can feed JSON to Terraform however this falls over if you need dependencies for output values. This usually isn't an issue because most Cloud provider resource…

You may be interested in Pulumi: https://www.pulumi.com/ Basically it's Terraform but instead of declaring your resources in HCL, you declare them in a real programming language. You're still producing a declarative config that the engine then diffs, applies etc. In fact, it's compatible with existing terraform providers, so it has a surprisingly large selection of things you can use it for. Note their docs will try…

Not with that licensing thanks

Re: Terraform 1.0

#170

Post by ethbr0 »

kevincox wrote: post #52
throwaway894345 wrote: post #31

Earlier quoted context omitted.

I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…

100%. Terraform is half-way between a tool for generating the configuration and applying it. I think Terraform's application engine is actually quite good, but I would like to use a much better tool to generate the config. (And be able to diff that config) You can feed JSON to Terraform however this falls over if you need dependencies for output values. This usually isn't an issue because most Cloud provider resource…

> application engine [vs] tool to generate the config

I get it from HashiCorp's perspective though.

A robust application engine with a suboptimal config generator is a viable product.

A suboptimal application engine with a brilliant config generator is not.

So given limited resources, former gets the dev grease.

Post reply on HN