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

161–167 of 167 posts

Re: Terraform 0.12

#161

Post by SlowRobotAhead »

420codebro wrote: post #154
SlowRobotAhead wrote: post #29

Earlier quoted context omitted.

>Infrastructure as code. Store it in git. Profit. Ok. But so is CloudFormation YAML files, mostly. So is the advantage of Teraform that it works beyond AWS?

My opinion? Because CloudFormation is full of shit regarding "always being able to rollback". After dealing with a 100+ failed CF rollbacks, I stopped caring about that phantom feature. That's around the same time I started using Terraform. At this point I only use CF for things I can not put in TF directly - namely ASGs. Regarding IaC "rollback" capabilities - I don't think it really exists in a way that makes it re…

That does help. I’ve never heard about CF not working as expected.

Hmm, I’ll have to look into it some more. I really like the idea of layering my application into dynamo set up, lambdas, polices, etc. and being able to update a specific layer, pull it down and put the new one up.

Last thing I want is more headache.

Re: Terraform 0.12

#162

Post by rurounijones »

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?

I never said it did. I said rubygems did and often fail at following that.

However I know of no common versioning scheme where 0.y.z is considered production ready.

Re: Terraform 0.12

#163

Post by techntoke »

james_s_tayler wrote: post #22
techntoke wrote: post #19

I moved away from Terraform a long time ago. Ansible was way more powerful, handled errors and issues with state changes. Terraform was super picky about how you had to operate, slow and HCL was a terrible markup language. I wasn't really a huge fan of Ansible either though and more recently have been doing things in regular shell/Bash scripts. Now with Kubernetes and service brokers, there is no need for Terraform.

What about setting up and tearing down EKS clusters? I haven't used terraform but I learned about it through looking at this: https://learn.hashicorp.com/terraform/aws/eks-intro So, I'd say Kubernetes itself does more heavy lifting but not all of it?

Spinning up an EKS cluster is something you usually do once, and if you need multiple EKS clusters then you can bootstrap others from an initial cluster that you deploy with eksctl or AWS CLI.

Re: Terraform 0.12

#164

Post by the_duke »

zbentley wrote: post #126
the_duke wrote: post #104

Earlier quoted context omitted.

The nice thing about Terraform (and Ansible) imo is that they don't require a daemon but just run locally (or on CI), with some shared state in a object store.

Neither does Puppet. Many people run it in a masterless "one-shot" configuration.

What would be your comparison between the solutions? As in, why would I pick Puppet over Ansible or Terraform for a masterless use-case?

Re: Terraform 0.12

#165

Post by pensatoio »

nineteen999 wrote: post #38
pensatoio wrote: post #16

Earlier quoted context omitted.

As others have said, no exporting is involved. You write roughly-json-esque code which you then apply to a cloud provider. The state of the infrastructure is stored, ideally, in the cloud. You apply your code during which terraform identifies which changes need to be made by comparing the current state with your local changes and executes those changes as you watch. The end result is well-defined, testable, repeatabl…

Where do you store your state files? The only project I've worked on that used Terraform stored state in a git repo, which seemed like a nightmare with multiple people doing deploys to the same environment. Others have suggested it would be better stored on a network accessible share.

Personally, my team uses S3 to store state paired with DynamoDB to manage state locks. Translation, when someone applies a layer a remote lock is created for the duration of their interaction. It’s a fantastic system.

I imagine using git to store state would be mightily inconvenient.

Re: Terraform 0.12

#166

Post by jjeaff »

kraig wrote: post #151
cs02rm0 wrote: post #65

Earlier quoted context omitted.

I'm so tempted to do abandon CloudFormation for a Makefile with AWS cli commands. If there wasn't a chip on my shoulder telling me I had to use what the next person would expect else as a contractor I risk being seen as unprofessional I'd do it in a heartbeat. I've never used Terraform but CloudFormation just seems to suck, the documentation is poor and relatively few people are sharing their stack files. I've lost c…

IMO both of you guys should take a look at Pulumi. You could still use a makefile but using their TS clients to access the APIs is much more intuitive and easier to diagnose than shell scripts.

I can't see paying an ongoing monthly fee unless I was dealing with really big and ever changing architecture. Most of the time, I am writing everything into a log because I will want the ability to rebuild everything in the event something goes down.

Re: Terraform 0.12

#167

Post by Thaxll »

mirceal wrote: post #51
_t0du wrote: post #15

I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After using it for a very short period of time I was shocked developers continued to struggle through CF templates and the fragility the whole process entailed.

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…

CF doesn't rollback either, the rollback is not done by the client but by CF backend, very different story.
Post reply on HN