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

Terraform 0.12

hashicorp.com

Post reply on HN
Print view View original

131–140 of 167 posts

Re: Terraform 0.12

#131

Post by mirceal »

tptacek wrote: post #60
mirceal wrote: post #51

Earlier quoted context omitted.

this is short-sighted. Terraform and CloudFormation are not even in the same league. One of them works and actually can be used for Infrastructure as Code, the other one does not roll back in the face of failure - it effectively craps for reasons ranging from network failure, process crash, even normal operation. One is heavy kool-aid with bugs that go unresolved for years, the other behaves as advertised. Sorry, but…

I mean, this is harsh, but there's a running joke that the big feature terraform is missing is a -twice flag so that it'll re-run itself on failure, since that's what you end up having to do anyways. Also, the terraform language, HCL? It's, I guess there's no better way to put this: not good. Am I misunderstanding the complexity of what Terraform is trying to do? To me, it looks like a bunch of tiny API clients tied…

the complexity of Terraform does not come from the happy path. It comes from when things go wrong and now you have to understand what went wrong and how to correct it. Now you’re in a world of pain since TF just throws its hands in the air and you’re left holding the bag. i have hear several people referring to terraform as Terrafail. I have also observed good dev/devops people struggling to make it work when shit hits the fan.

Re: Terraform 0.12

#132

Post by mirceal »

ReidZB wrote: post #67
tptacek wrote: post #60

Earlier quoted context omitted.

I mean, this is harsh, but there's a running joke that the big feature terraform is missing is a -twice flag so that it'll re-run itself on failure, since that's what you end up having to do anyways. Also, the terraform language, HCL? It's, I guess there's no better way to put this: not good. Am I misunderstanding the complexity of what Terraform is trying to do? To me, it looks like a bunch of tiny API clients tied…

Yeah, HCL's limitations have been an enormous thorn in my side for a long time. HCL2 (Terraform 0.12) is a big step forward, but even still I pine for a proper programming language, even if it has foot-guns. I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of reso…

detecting resources that are already there may be useful in a limited set of scenarios (prototypes / retrofitting) but definitely should not be the way you build things. thinking through what your cloud infra is doing and expressing it is the way to go.

there is also a way to do this for cloudformation. look up cloudformer.

Re: Terraform 0.12

#133

Post by hedwall »

rurounijones wrote: post #88
IloveHN84 wrote: post #81

Earlier quoted context omitted.

Before stable version x.y.z, if x is 0, then y means major

I am astounded that after all this time it is still 0.y.z I mean, it has been around for like 5+ years... I am even more astounded that people are happy to use a product that by its own definition is not stable. Same happen in ruby a lot. You find a Gem that claims to follow semantic versioning and it is still in 0.y.z after years of being used in production which flies in the face of https://semver.org/#how-do-i-kno…

Where does Terraform claim to follow semver?

Re: Terraform 0.12

#134

Post by ReidZB »

guitarbill wrote: post #89
ReidZB wrote: post #67

Earlier quoted context omitted.

Yeah, HCL's limitations have been an enormous thorn in my side for a long time. HCL2 (Terraform 0.12) is a big step forward, but even still I pine for a proper programming language, even if it has foot-guns. I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of reso…

> can detect configuration drift, but not correct it if by "correct it" you mean update the current template to match what's there, that'd be good, as AFAIK there's no easy way to do this at the moment. if by "correct it" you mean revert or change resources, no thanks. that sounds like a production accident waiting to happen, and you can un-drift (?) resources manually already.

I do mean revert or change resources. Making manual changes outside the context of an IaC tool is largely madness, in my opinion, although sometimes the situation warrants it.

Auditability and controls are one of the many facets of IaC. We require code changes to be approved by another developer, and similarly we require infrastructure changes to be approved by another developer. Regularly working outside the IaC tool would be in violation of that policy.

It's in this approval step that the change-set (CFN) or plan (Terraform) should be carefully reviewed by a human. If someone's made manual changes, reversion of them should appear here, and those should be unusual and eyebrow-raising. At that point, it's either fix the IaC definition of the infrastructure, manually un-drift it as you say, or do some workaround to ignore specific changes.

(To reiterate, IMO no one should ever run CFN/Terraform unattended on prod infrastructure, and there should always be a step to review the change-set/plan.)

I'll also say that the sword cuts both ways when it comes to prod outages and manual changes. Not so long ago, I ran into a prod-impacting issue when turning on multi-AZ for an RDS instance. In the other regions that had multi-AZ enabled, someone had manually added an extra parameter to the RDS parameter group, one that was required for certain app functionality to work. No one ever added it back to CloudFormation and that knowledge was eventually lost. When we enabled multi-AZ in a different region, we expected no problems at all, but instead we ended up with a whole section of app functionality breaking.

(This would've been before drift detection was a thing in CloudFormation, but actually I don't think RDS parameter groups are supported in CloudFormation's drift detection right now anyway. [0])

[0] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

Re: Terraform 0.12

#135

Post by pseudalopex »

SlowRobotAhead wrote: post #47
s09dfhks wrote: post #6

Earlier quoted context omitted.

there's no exporting. You write everything in there format to define your infrastructure, and then terraform turns it into AWS API calls

That makes sense. Now, other than the portability of AWS to Azure to GCP, why do I want this? Because with CloudFormation I can pull down and put up my “stacks” in layers and this isn’t necessarily the same as API calls (although on the backend maybe it is).

Terraform can manage much more than AWS, Azure, and GCP.[1]

[1] https://www.terraform.io/docs/providers/

Re: Terraform 0.12

#136

Post by ReidZB »

mirceal wrote: post #132
ReidZB wrote: post #67

Earlier quoted context omitted.

Yeah, HCL's limitations have been an enormous thorn in my side for a long time. HCL2 (Terraform 0.12) is a big step forward, but even still I pine for a proper programming language, even if it has foot-guns. I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of reso…

detecting resources that are already there may be useful in a limited set of scenarios (prototypes / retrofitting) but definitely should not be the way you build things. thinking through what your cloud infra is doing and expressing it is the way to go. there is also a way to do this for cloudformation. look up cloudformer.

I agree, importing resources is a limited use-case. However... it's one I find myself in more often than I would like. Reality is often disappointing. At least, with the companies I've work(ed) with.

That said, I don't think CloudFormer does the same thing. I haven't used it before, so please correct me if I'm wrong, but to me it looks like it takes existing resources and generates a CloudFormation template out of them. But then you're still expected to upload that template and create a new stack, with all brand-new CloudFormation managed resources—is that right?

So for example, CloudFormer for an RDS instance would probably be a no-go.

In the Terraform case, after you've imported resources, there's no need to re-create them. There's the question of if what's in the template will match what the resources actually are, but there are also tools to generate Terraform templates straight off resources.

Re: Terraform 0.12

#137

Post by ReidZB »

mirceal wrote: post #130
gnosek wrote: post #84

Earlier quoted context omitted.

Long-time user of Terraform here, never used CloudFormation. Where does CloudFormation beat Terraform?

Cloudformation will leave your infrastructure in a consistent state. Period. It will consistently drive things from point A to point B or rollback to point A if it cannot get to B. It will also correctly remember all the resources it created and allow you to properly identify them and/or delete them. These sound like tablestakes but Terraform cannot do this. Add the frustrations of HCL on top and it’s a big no go for…

I've had CloudFormation fail to roll back plenty of times, though never in a situation where it actually mattered.

I've never had Terraform "forget" resources or disallow me from deleting them (unless I requested that). Maybe those are bugs that've since been fixed?

It sounds like we've had very different experiences with these tools.

Re: Terraform 0.12

#138

Post by IloveHN84 »

rurounijones wrote: post #88
IloveHN84 wrote: post #81

Earlier quoted context omitted.

Before stable version x.y.z, if x is 0, then y means major

I am astounded that after all this time it is still 0.y.z I mean, it has been around for like 5+ years... I am even more astounded that people are happy to use a product that by its own definition is not stable. Same happen in ruby a lot. You find a Gem that claims to follow semantic versioning and it is still in 0.y.z after years of being used in production which flies in the face of https://semver.org/#how-do-i-kno…

Well we can argue about the hundreds of Apache projects that are not even stable after decades.

OpenSource projects have another pace compared to commercial solutions

Re: Terraform 0.12

#139

Post by IloveHN84 »

hedwall wrote: post #133
rurounijones wrote: post #88

Earlier quoted context omitted.

I am astounded that after all this time it is still 0.y.z I mean, it has been around for like 5+ years... I am even more astounded that people are happy to use a product that by its own definition is not stable. Same happen in ruby a lot. You find a Gem that claims to follow semantic versioning and it is still in 0.y.z after years of being used in production which flies in the face of https://semver.org/#how-do-i-kno…

Where does Terraform claim to follow semver?

Where doesn't it claim it? Using a versioning scheme like x.y.z _by default_ means semver

Re: Terraform 0.12

#140

Post by ReidZB »

gnosek wrote: post #84
ReidZB wrote: post #67

Earlier quoted context omitted.

Yeah, HCL's limitations have been an enormous thorn in my side for a long time. HCL2 (Terraform 0.12) is a big step forward, but even still I pine for a proper programming language, even if it has foot-guns. I do think you're selling Terraform short, though. Sure, the core is the toposort-create-things. But it also stores the state of its created things and (crucially) has the ability to diff the actual state of reso…

Long-time user of Terraform here, never used CloudFormation. Where does CloudFormation beat Terraform?

So, I think it does win in a few areas...

Like one sibling comment mentioned, getting support from AWS is nice. You can buy Terraform support, too, but knowing HashiCorp it'd probably cost more than most peoples' AWS bills in their entirety. (This is me being a little cheeky and unfair—HashiCorp handles community support via GitHub Issues for Terraform really well.)

CloudFormation's built straight into AWS, so there's no need to set up state file storage or locking or worry about a state file at all, really. This has its own set of drawbacks, but it's nice for getting started, and in theory it makes CloudFormation more robust out-of-the-box.

CloudFormation StackSets are really nice if you have identical resources that need to be placed in many different regions and accounts. (Example: we use it to place GuardDuty and Config, both regional services, in every region.) With Terraform, this means copy-and-paste, as far as I know, though maybe Terraform 0.12 sets up the groundwork to make this better?

The Service Catalog is basically a way to let technical end-users manage products via CloudFormation templates. Something could be built to do the same for Terraform, but I don't think there is anything like that right now.

CloudFormation does (attempt to) roll back to a known-good state if an update fails. Terraform just stops in the middle of what it was doing. I have mixed feelings about that.

I find YAML to have better tooling/editor support than HCL, though I actually prefer HCL.

There are existing CloudFormation wrappers (e.g. Troposphere) that can give you a full programming language on top of CloudFormation. To my knowledge, there isn't anything similar for Terraform.

Some things that have changed with 0.12:

CloudFormation has had `AWS::NoValue` for as long as I can remember. Terraform Terraform both sides were evaluated, which led to errors, unlike CloudFormation's !If. In Terraform 0.12, the ternary only evaluates one side.

Post reply on HN