Live data from Hacker News

Terraform 0.15 General Availability

hashicorp.com

21–30 of 239 posts

Re: Terraform 0.15 General Availability

#21

Perhaps off-topic but how have people upgraded TF codebases to new versions? Just last year we had a big effort to upgrade a huge code-base from 0.11 to 0.12. I feel like it should be a lot smoother than a full-team full-sprint effort.

I'm one of the HashiCorp founders. Terraform 0.11 to 0.12 is by far the most difficult of the versions to upgrade between. I am really sorry about that. The other upgrades should be relatively minor as long as you read and follow the upgrade guides and upgrade one minor version at a time (0.11 => .12 => .13 etc.). There are rough edges for very specific cases but most of our customers were able to upgrade from 0.12 t…

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 the problems that will appear in production. And it's all owned by different groups and used in different projects, so that makes things longer/more complex. We also have to deal with provider version changes, upgrading CI pipelines and environments to be able to switch between Terraform binaries, and conventions to switch between code branches.

I am already looking around for some way to remove Terraform from our org because it is slowly strangling our productivity. It's way too slow, there's too many footguns, it doesn't reliably predict changes, it breaks on apply like half of the time, and it's an arduous manual process to fix and clean up its broken state when it does eventually break. Not to mention just writing and testing the stuff takes forever, and the very obvious missing features like auto-generation and auto-import. I keep a channel just to rant about it. After Jenkins, Ansible and Puppet, it's one of those tools I dread but can't get away from.

Re: Terraform 0.15 General Availability

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

To answer your questions: you generally look in the Terraform docs which are well written and always updated, because autogenerated. The state forces you and especially the team to almost never touch things directly. And if you do, you feel nasty for it.

Re: Terraform 0.15 General Availability

#23
post #10

Earlier quoted context omitted.

I'm a fan of tfenv for this; it's really easy to use and makes it trivial to pin each stack to an exact version of TF.

Between rbenv, tfenv, pyenv, sdkman and so on and so forth, maybe it's time for some sort of common OS-level env-management interface...?

Maybe asdf? https://github.com/asdf-vm/asdf

Re: Terraform 0.15 General Availability

#24
Looks like Terraform is really approaching maturity and the 1.0 release already on the horizon is a deserved milestone. I really appreciated the lockfile for modules/providers added in 0.14 and 3rd party providers in the registry being promoted to 1St class citizens. It enables saner and more modular architectures in an easy enough way.

Re: Terraform 0.15 General Availability

#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

Re: Terraform 0.15 General Availability

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

There are docs for terraform which are fairly general and then provider specific docs as well (aws/gcp/azure/etc). We like it because it is easy to recreate environments and entire infrastructures. It also makes it much easier to review infrastructure changes.

>manually fix

You can if you need to. TF can ignore changes to certain aspects of resources like desired count of ECS tasks which might autoscale up and down and you can always make the change manually and then update the code to reflect the change. That's a bit of a no-no though. Like pushing code without a review.

Re: Terraform 0.15 General Availability

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

What else to use? All other tools operate at the same level as terraform, be it cloudformation or anything else. It's just drivers for the cloud API in question, each with their own drawbacks, idiocracies, limitations and workarounds. In a sense, these are all equal effort for the user.

Re: Terraform 0.15 General Availability

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

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 colleagues as reviewer.

5. They review my solution, tell me to correct some issues that there might be, or straight up approves my solution.

6. My PR is merged into master.

7. I download the latest master version and apply the codebase.

This way we always have at least two people verify any changes to our infrastructure, minimizing the risk of fuckups and ensures solutions are as good as possible.

Re: Terraform 0.15 General Availability

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

I spent a lot of time in both sets of docs for sure (along with perusing the console and creating test resources manually to see what options and switches I might be overlooking).

I think tf really shines when you start using multiple providers to manage things outside of the cloud though. In my last gig I was for example using the workspaces feature and auth0 provider to have separate auth stacks for our different envs, being able to use values created by one providers resources in another's was nifty

Re: Terraform 0.15 General Availability

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

> we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform

This is a feature, not a bug. Terraform is a tool to (reproducibly) enshrine your infrastructure in code. 'Minor manual fixes' are often left undocumented and known only to 1-2 people, and suddenly become major problems when your infrastructure comes crashing down and nobody knows why it used to work.

Post reply on HN