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

141–150 of 239 posts

Re: Terraform 0.15 General Availability

#141

Post by ec109685 »

0xbadcafebee wrote: post #21
mitchellh wrote: post #11

Earlier quoted context omitted.

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 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.

Re: Terraform 0.15 General Availability

#142

Post by apple4ever »

mr_C wrote: post #45
solatic wrote: post #31

Earlier quoted context omitted.

Because the state exists regardless. When you write code that interfaces with AWS, there's always something that exists on the other side of the AWS API. The question you have is, how do you programmatically keep a copy of that state on your side of the API? The naive approach that tries to do this without state in code goes something like: a) invoke the remote API to look for something that should exist b) if it doe…

Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the exist…

How do you ensure you have say 2 web servers created and connected to a load balancer? Is that part of your custom module?

Re: Terraform 0.15 General Availability

#143

Post by solatic »

mr_C wrote: post #56
diroussel wrote: post #51

Earlier quoted context omitted.

If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whe…

Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.

Part of the benefit of Terraform is the ability to set up ephemeral resources and tear everything down afterwards with "terraform destroy", which is useful for setting up one-off experiments and tests. That kind of cleanup is completely impossible with Ansible.

Re: Terraform 0.15 General Availability

#144

Post by cmclaughlin »

theopsguy wrote: post #62
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

If you like CDK, then i highly recommend pulumi

I tried Pulumi with Python and kept running into show stopper bugs.

Re: Terraform 0.15 General Availability

#146

Post by saberience »

ghjnut wrote: 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 use Spacelift at our company, pretty new tool, but I prefer it to Terraform Enterprise and the migration was way easier.

Re: Terraform 0.15 General Availability

#147

Post by cmclaughlin »

ben0x539 wrote: post #133
diroussel wrote: post #46

Earlier quoted context omitted.

Basically you create the desired state DAG in procedural code, rather than the TF DSL. Blithe diffing and applying are the same.

Can you inspect inputs from terraform resource attributes or data sources in the procedural evaluation?

> Can you inspect inputs from terraform resource attributes or data sources in the procedural evaluation?

No... the high level programming language really just serves as a bridge or translation layer to a Terraform compatible JSON file. Those sorts of evaluations don’t happen to the actually plan/apply. However, you may find it useful to make direct API calls to your cloud provider in cdktf stacks. For instance, I mostly use data lookups but if I want to perform string operations on that sort of data I would use boto3 instead.

Re: Terraform 0.15 General Availability

#148

Post by ofrzeta »

satya71 wrote: post #84
theopsguy wrote: post #62

Earlier quoted context omitted.

If you like CDK, then i highly recommend pulumi

Can second that. Pulumi with Typescript is just absolutely awesome.

It's probably good when you are already using Typescripts in other parts of your day job. While I like the idea of using a real programming language in place of a declarative DSL you trade in the awkward parts of the latter with the idiosyncrasies of async programming and promises.

Re: Terraform 0.15 General Availability

#149

Post by ezrast »

mr_C wrote: post #56
diroussel wrote: post #51

Earlier quoted context omitted.

If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whe…

Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.

> In practice you could just set state:absent to whatever you are trying to remove

If you do this, or in fact anything with Ansible, be REAL careful about double-checking what your tags actually match before committing. Since it doesn't track state, anything in your cloud environment is fair game.

I was not careful once, and that was a bad week for me.

Re: Terraform 0.15 General Availability

#150

Post by Guthur »

viraptor wrote: post #127
Guthur wrote: post #123

Earlier quoted context omitted.

Why "practitioner"? it really does not feel like the correct term.

It's a philosophy not a title https://www.visualscript.com/devops/devops-is-not-a-title-it...

But that still does not align with the use of the word practitioner, it's usually a formal profession with licensing such as medicine or law.
Post reply on HN