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

Terraform 0.15 General Availability

hashicorp.com

Post reply on HN
Print view View original

161–170 of 239 posts

Re: Terraform 0.15 General Availability

#161

Post by pm90 »

kstrauser wrote: post #82
moufestaphio wrote: post #42

Earlier quoted context omitted.

> we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform In my opinion if you're doing manual fixes you're doing it wrong. Let's say you do your manual fix in your Dev environment. Do you remember to do it in Prod/whatever other environments you have? Are you sure you did the EXACT same thing? Did you change 5 other things trying to fix it first? You end up with s…

I think there's a middle ground if you're not sure how to fix a mistake in Terraform but you know how to do it in the console: * Make your changes by hand * Right afterward, run "terraform plan" to see how Terraform would undo your changes * Edit your Terraform config to reflect those changes, and run "terraform plan" again to make sure you caught everything. Repeat until it's a no-op. Now you've got a log of what yo…

This. I’m surprised at how many folks don’t realize you can do this and capture your changes in terraform by looking at the plan and making tf code changes until the plan doesn’t show a diff

Re: Terraform 0.15 General Availability

#162

Post by pm90 »

matwood wrote: post #106
kstrauser wrote: post #32

Earlier quoted context omitted.

"I just spent a couple of hours standing up a specific resource, which was kind of a pain in the neck. Oh, now I need 23 more of them! That'll take another 30 seconds to generate the configuration and create the new resources." That's why I like Terraform. Edit: "Also, I created a thing 2 years ago and now I need another one. Oh, here it is in Terraform." It's incredibly nice not to have to re-learn how to make that…

> "Also, I created a thing 2 years ago and now I need another one." Let me add, this thing was changed 2 years ago to add an option...why? Git blame to the rescue... I probably use git history more in my tf code than in my regular programming.

Absolutely invaluable to have this, especially for infrastructure changes which often involve ugly hacks to get around limitations but which may just not be clear at first.

Re: Terraform 0.15 General Availability

#163

Post by takeda »

dxxvi wrote: post #18

My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform

Well... I'm puzzled about it on AWS. I don't know about Azure, but on GCP I tried their equivalent of CloudFormation and it was absolutely POS. Reported a bug in their repo, and got response acknowledging the bug, but it's in specific component's API that is owned by another team (within Google of course) and there's not much they can do about it.

Like WTF? Do they think I have better chance reaching them than them? Tried then TF and it was much simpler and everything worked as expected.

On AWS though, seriously, TF is inferior.

Re: Terraform 0.15 General Availability

#164

Post by ygouzerh »

cmclaughlin wrote: post #25

On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk

Thanks for the share, didn't heard about it before, I see the advantage in a use-case that we have :

We have are actually working on : "How to manage Terraform resources". We ended up having a conflict dev ops where dev teams are messaging the terraform guys to create resources. For example, to create a database, it will take only 1 hour writing HCL, but 2 weeks of emails to align on the specs.

We are currently building something on top, to have resources that can be created in a self-service mode by the devs themselves. (Behind the scenes, it uses Terraform modules to generate resources that will comply with the company policies).

For the moment, it's a bunch of Jenkins pipelines. Having a CDK can actually help us a lot there. (Can plug it to a CMDB database, have a UI on top, etc)

Re: Terraform 0.15 General Availability

#165

Post by takeda »

dasil003 wrote: post #39
dxxvi wrote: post #18

My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform

Have you ever set something up manually via AWS console, then 6 months later totally forgot the steps you took and end up wasting a lot of time reverse engineering what you did in order to make a comparatively small change? After that perhaps you vowed to take better notes, so the next time you do it that way, but then 6 months later you find that you missed some detail, or there was some changes in between that were…

I'm not parent poster, but I believe (when he mentioned looking at TF and AWS documentation) he most likely meant to use TF instead of CloudFormation. And frankly I think CF is far more robust.

Re: Terraform 0.15 General Availability

#166

Post by hrktb »

vbsteven wrote: post #154
hrktb wrote: post #68

Earlier quoted context omitted.

Reading the sister comments, I kind of understand the appeal of terraform for huge/multi cloud infra systems. Now, managing changes in code doesn’t look too far from dealing with kubernetes’ json/yml config and applying them to the current cluster, provided it would be trickier when expanding to multiple cluster or doing complex orchestrating. I guess TF makes a lot more sense for on-premise, bare metal VMs ?

Use Terraform for bringing up the Kubernetes cluster and other related cloud resources (storage, load balancers, DNS, etc). Once you have a cluster up and running you can just use kubernetes yml to manage the cluster. It is possible to also use Terraform to manipulate kubernetes resources (or AWS ECS or another container platform) but I personally like a clear separation between infrastructure (bringing up the enviro…

So TF would come where you would otherwise use gcloud commands, if I get it.

One part of the cluster building that caught me off-guard with GCP is that cluster options effectively change over time, as the k8s versions march forward.

For instance some feature go out of beta and become the default, and trying to rebuild a cluster exactly similar to one built year ago would require specific “don’t use that new feature” flags added to it. Or using these new features require adapting the other resources to the new configurations.

I guess TF is still useful in that it helps audit and reproduce the same infra inbetween changes, and will be nicer as an interface than bash scripts, even if it won’t save from dealing with nitty gritty of the platform.

Re: Terraform 0.15 General Availability

#167

Post by HatchedLake721 »

goatinaboat wrote: post #145

Blows my mind how many people are basing business critical infrastructures on 0.something of anything

Terraform (and hashicorp) don’t follow semver. Terraform has been spinning up infrastructure for small and $100billion+ companies for years, it came out in 2014.

Business critical readiness is not measured whether something has or hasn’t got a “1.0” tag on GitHub.

Re: Terraform 0.15 General Availability

#168

Post by takeda »

rantwasp wrote: post #108
ramoz wrote: post #94

Earlier quoted context omitted.

I love your comment,"YOLO-ing" gave me a laugh, and a laugh at myself in some previously stressful/complex deployment periods. Terraform was not a friend there. That said, I've worked on/with a team enabling some fairly advanced & streamlined capabilities across all three clouds because of Terraform. The abstraction matters, and ability to model scaled platform components and architectures as singular units is import…

is the open source community great? Look at the open bugs. Some of them are old enough to go to school. For extra lolz try killing the terraform process of pulling the network cable. Hilarity ensures and you’re gonna have a bad time recovering what it was doing. I would not recommend Terraform period.

There was a bug fixed few months ago. Until recently when you tried to destroy the infrastructure it started to undo what was actually deployed. Previously it was using the current hcl file.

Re: Terraform 0.15 General Availability

#169

Post by takeda »

encryptluks2 wrote: post #92
manishsharan wrote: post #90

Earlier quoted context omitted.

Roll back is one reason I choose AWS Cloudformation over Terraform. And also I do not see the reason for Terraform in my use case as we run only on AWS. No point in not using AWS native tools.

When using Terraform you should think of your IaC as the plans to build or rebuild your infrastructure, not an extension. I built mine in a way where I can destroy all the infrastructure in a plan and then reapply. You don't have to worry about rollbacks when you can just rebuild everything without affecting your end service.

What parent meant is that in CF if it encounters an error, by default will roll back to state before the update. TF will just leave it broken.

Re: Terraform 0.15 General Availability

#170

Post by takeda »

leetrout wrote: post #100
mwarkentin wrote: post #96

Earlier quoted context omitted.

Cloudformation rollback is not exactly bulletproof either.

Especially initial deploys that rollback and you have to delete the stack to try to deploy again. Waste of time. On the whole terraform is much faster too.

CF gives you both behaviors, you have option to select which one you prefer.
Post reply on HN