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

231–239 of 239 posts

Re: Terraform 0.15 General Availability

#231

Post by pizza234 »

sciurus wrote: post #65
pizza234 wrote: post #52

Earlier quoted context omitted.

While it's not possible to make an apple-to-apple comparison (Terraform-to-?), if we compare to something based on an imperative language, say Puppet or Chef, there is a huge difference. In my opinion, Terraform's big issue is that it was born as a declarative tool for managing infrastructure. Large configurations (IMO) necessarily ossify, because you don't have an imperative language that makes small progressive cha…

> compare to something based on an imperative language, say Puppet or Chef I'm puzzled by this comparison. I consider both of these to be primarily declarative languages. You declare the state you want puppet or chef to enforce, not how they get there. E.G. https://puppet.com/blog/puppets-declarative-language-modelin...

I've indeed stretched the concept by equating Chef and Puppet (I guess the latter is closer to TF).

To be more accurate, I'd say that Chef has a declarative structure supported by the imperative constructs of the underlying language, and this is what makes for me a big difference.

Consider the for loop as example. By the time it was added (v0.12), there was a (200 pages) commercial book available. And there are people in this discussion stuck at v0.11.

The difference in the declarative vs. imperative nature, as I see it now that the for loop is implemented in TF, is that it's embedded inside resources, that is, it fits strictly a declarative approach, and has limits. In Chef, you can place a for loop wherever you prefer.

Object instances is also another significant difference. It took a while for TF to be able to move (if I remember correctly) module instances around (that is, to promote them to "more" first class citizens), which made a big difference. In an imperative language, accessing/moving instances around is a core part of the language. In Chef, pretty much everything is global - both in the good and in the bad. But certainly the good part is that refactoring is way more flexible.

I think TF has always been plagued by repetition; in my view, this is inherent in the "more" declarative approach (since they're trying to embed imperative constructs in the language).

Re: Terraform 0.15 General Availability

#232

Post by pizza234 »

tilolebo wrote: post #73
Thaxll wrote: post #55

Earlier quoted context omitted.

I have really bad memories of the change between puppet 2 and 3 for example.

Same. I went through a puppet 2->3 migration and also through a terraform 0.11->0.12 update. The puppet migration was definitely more painful, because of the entangled code.

It's not clear if it was entangled because it was written in the specific framework or because it was just badly written code. In the latter case, this hasn't really anything to do with the framework. Additionally: did you make the v0.12 a migration just work, or did you change the codebase to take advantage of the new features (and remove inherent duplication)?

There are inherent problems in the TF framework and the migraitons. 0.12 introduced for loops, and 0.13 added modules support to them. So a proper migration should convert deduplicate resources into lists of resources. This is painful for big models, since one needs to write scripts in order to convert resource associations in the statefile. And hope not to miss anything!

Due to the strictly declarative nature, it's also difficult to slowly move duplicated resources into lists, and handle both of them at the same time.

At this time, our time is stuck with a certain TF version, and can't move without spending considerable resources.

Re: Terraform 0.15 General Availability

#233

Post by AtNightWeCode »

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…

I think in larger companies you separate infrastructure from teams. Teams are provided with tools or ways to set up new resources at a higher level.

Re: Terraform 0.15 General Availability

#234

Post by takeda »

leetrout wrote: post #195
takeda wrote: post #170

Earlier quoted context omitted.

CF gives you both behaviors, you have option to select which one you prefer.

How would you do that with `sam deploy` https://docs.aws.amazon.com/serverless-application-model/lat...

I don't use it, so don't know if it is a missing feature then request it.

We are talking here about CF and CF gives you control over it.

Re: Terraform 0.15 General Availability

#235

Post by takeda »

encryptluks2 wrote: post #202
takeda wrote: post #169

Earlier quoted context omitted.

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.

It isn't left broken per say, in fact you should be able to version the state and rollback to the previous state and have it remove whatever new resources were created when you re-apply. I just take another approach which is if something doesn't work, then I'm able to quickly blow it away and re-deploy without affecting the end service by having the apply only target specific environments.

If it is half deployed it is broken, maybe in some cases service continues running, but in other will be broken.

The solution you mentioned relies on other tools and some manual work you need to do. Also with how TF works by default you might never be able to restore to exact same state as it was before.

CF when needs to replace a resource it first creates a new copy, and applies all changes if everything succeeds then it removes old resource, if it fails it rolls changes back.

You have an option that allows you to do that with a resource, but it's done individually per resource and it still isn't exactly the same thing.

Re: Terraform 0.15 General Availability

#236

Post by darthrupert »

aprdm wrote: post #219
darthrupert wrote: post #152

Earlier quoted context omitted.

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.

Well I guess I beg to differ. Been creating and managing 10ks of hosts across multiple on prems datacenters and clouds for some time now.

Perhaps we have a different view of what infrastructure means? Managing hosts isn't it by my view.

Re: Terraform 0.15 General Availability

#237

Post by throwaway823882 »

darkr wrote: post #187
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…

There was a good talk at Hashiconf a few years back, can't find a link now. I can't say that this is the "right" way to do it, but it scales OK for our org (100+ engineers, 200+ services per environment, many third party and in-house providers). A single team owns the codebase, though all backend engineers expected to write and maintain their own infra code. Some highlights: * Monorepo with ~ 700 terraform modules, >…

If you don't have a CI/CD system that already allows you to deploy 100 changes a day, you can't do large scale monorepos, or you'll get caught up in continuous integration hell.

In that case, the best choice is lots of remote states / data sources, independent modules in independent repos that reuse other modules, and strict adherence to internal conventions, including branching/naming/versioning standards running the gamut from your VCS, to the module, to the code, to the data structures, to the "terraformcontrol" repos, etc. Basically, standardize every single possible thing. If anyone ever needs something to work differently, update the standard before the individual module.

How and when to separate remote states is still a bit of black magic. In general, you can make a new state for each complete unit of deployment. Assuming a deployment has stages, you can separate terraform state into those different stages, so that you can step through them applying as you go and stopping if you detect a problem. The biggest mishap is when you're trying to apply 100 changes and your apply fails half way, and you have to stop the world to manually fix it, or revert, which may not even work. It's much easier to manage a change that affects a few resources than lots of them.

Re: Terraform 0.15 General Availability

#238

Post by aprdm »

darthrupert wrote: post #236
aprdm wrote: post #219

Earlier quoted context omitted.

Well I guess I beg to differ. Been creating and managing 10ks of hosts across multiple on prems datacenters and clouds for some time now.

Perhaps we have a different view of what infrastructure means? Managing hosts isn't it by my view.

Possibly! Care to share your view?

Re: Terraform 0.15 General Availability

#239

Post by apple4ever »

aprdm wrote: post #219
darthrupert wrote: post #152

Earlier quoted context omitted.

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.

Well I guess I beg to differ. Been creating and managing 10ks of hosts across multiple on prems datacenters and clouds for some time now.

How do you deal with this with Ansible instead of Terraform?

I'd love to have a single tool, but Ansible's style seems like a poor fit especially compared to Terraform.

Post reply on HN