Live data from Hacker News

Terraform 0.15 General Availability

hashicorp.com

151–160 of 239 posts

Re: Terraform 0.15 General Availability

#151
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

You are not supposed to do anything manually ever in a cloud environment managed by a declarative tool. That's not just for terraform but for all of them.

Re: Terraform 0.15 General Availability

#152
post #99

Earlier quoted context omitted.

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…

The jump from what you mentioned in paragraph 2 to 3 is not necessarily Terraform. You can use other tools, like Ansible, that IMO have a much better framework than Terraform. I use Terraform for extremely simple stuff that is easy to destroy/recreate. Projects of bigger scale IMO are better served with Ansible and friends.

No, Ansible is not good for this. It's good for maintaining clusters of hosts, but its stateless nature makes it close to worthless for infrastructure.

Re: Terraform 0.15 General Availability

#153
So much hate ITT for such a great tool. Terraform is definitely not perfect but it's still one of my favorite tools, solely because of the amount of efficiency gained from learning it. Yes HCL is not perfect, but it is definitely adequate for a lot of applications. IMO, Hashicorp makes some of the most well thought out tools and I am grateful of their attitude towards open source.

Re: Terraform 0.15 General Availability

#154
post #68

Earlier quoted context omitted.

Terraform allows us to implement development practices into our sysadmin lives. Such as code reviews, etc. For example, at my work this is what i do to apply changes to our AWS setup: 1. Fetch the latest version of our git repo. 2. Create a new git branch named after the Jira ticket im working on. 3. Solve the jira ticket by modifying the terraform code accordingly. 4. Submit a pull request and assign one of my colle…

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 environment using Terraform) and scheduling work on a cluster (using kubectl)

Re: Terraform 0.15 General Availability

#155
post #135

Hijacking a bit, but does anyone have any good resources/guides around managing terraform state in larger organizations? Terraform enterprise seems to address this but I was wondering if there's workflows that allowed subsections of infrastructure (think teams or systems) and didn't rely on a re-evaluation of the entire organization's assets. So far the only approach I've seen is having protected high level (VPC, sub…

We decided to go for Terraform Cloud in our company, it works really great.

You can setup a workspace per subfolder, setup to automatic planning or not at each new commit, and put a team on it.

Main features I see : store the state and take care about the durability and the encryption + can create teams + cicd pipeline + manage variables.

There is a free tier until 5 active users also, good for experimenting it / showcase the advantages to stakeholders

Re: Terraform 0.15 General Availability

#156
I have been using terraform professionally at my current workplace for a while now and I would not recommend it to anyone when building and maintaining non-trivial infrastructure.

- state management is a sad joke. Which would be fine if it wouldn't end up being an expensive joke sometimes. And by sometimes I mean right when you need to change production. Try destroying your stack with an AWS KMS key. Then create it again. Try killing apply and then try re-applying it. I have witnessed hours of developer time going down the drain to figure out what terraform was able to do, import resources, convince terraform that resources are added, write scripts to delete stuff.. A complete nightmare. Oh yeah, but just run apply twice, that usually fixes it. There is no such thing as a rollback in the world of terraform. We only roll forward!

- bUt ItS cLouD AgNoSTic. No, it's not. You're writing separate stacks with their separate own custom resources and their separate requirements and separate policies. Just use cloudformation, gdm or whatever your cloud uses and automate these using a script if you're doing crosscloud crap.

- but I want to avoid vendor lock-in. See above, odds are that you're already locked-in but still in denial.

- HCL. I get it. Declarative, nice and clean. HAHAHA, who am I kidding. It sucks, it's stupid and pointless. Awful to write, awful to read, inconsistent, no proper tooling or editor support. Good luck maintaining dependencies or comprehending a complex stack. Why didn't they just build a DSL over a language people already know? Good luck 'refactoring' your resource definitions. Oh, and you also want to test it somehow without affecting a remote environment? Again, good luck, sucker. Because 'the plan' is a lie. And error messages seem to be written by someone waging war against their customers.

In conclusion, I do not recommend terraform. In my opinion it is an overhyped piece of technology on which I would not bet my company/money on.

Re: Terraform 0.15 General Availability

#157
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

You can definitely manually fix something and then just have to update the terraform code and it should be fine. But it depends on what kind of manual fix you are doing as some changes are inplace while some require recreation.

Re: Terraform 0.15 General Availability

#158

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

>"On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL." Out of curiosity what is it that people generally don't like about HCL?

Yet one more thing to learn. No types (hints in IDEs).

Re: Terraform 0.15 General Availability

#160

Earlier quoted context omitted.

Our teams have something like 100,000 LOC in Terraform 0.12, and it's not all in one big monorepo. At that scale there is no such thing as a relatively minor version upgrade. We want to upgrade to get away from some persistent 0.12 bugs, but we literally don't have the time. We have to change all of the code, and then test every single project that uses that code in non-prod, and pray that the testing finds most of t…

Tangential, but curious how did you get to 100k lines of TF? I’d imagine most things within your company would follow very similar patterns and therefor be extracted into modules, and the per app/team code would be relatively small and focused on how to compose these modules together.

Modules are useful only up-to a point. Creating complex modules with a ton of moving parts makes it difficult to make changes, to upgrade etc. The best recipe that I’ve found is to use modules to enhance some core functional component and then compose these modules to build infrastructure, rather than defining your entire stack in a single module.
Post reply on HN