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

Terraform 1.0

github.com

Post reply on HN
Print view View original

51–60 of 315 posts

Re: Terraform 1.0

#51

Post by Thaxll »

papito wrote: post #33
nautilus12 wrote: post #29

You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.

I've used both - with having to use CF to create a particularly gnarly and sprawling environment. I constantly ran into limitations hidden behind cryptic or unrelated error messages. It was infuriating. Terraform syntax is definitely not sexy, but it's a robust piece of software, and in fact, can be used to learn better Go techniques. A total aside, but people who claim Golang is easy are full of it. It's an extremel…

It took me couple of hours to write a TF module years ago, it was that easy.

Re: Terraform 1.0

#52

Post by kevincox »

throwaway894345 wrote: post #31
kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…

100%. Terraform is half-way between a tool for generating the configuration and applying it. I think Terraform's application engine is actually quite good, but I would like to use a much better tool to generate the config. (And be able to diff that config)

You can feed JSON to Terraform however this falls over if you need dependencies for output values. This usually isn't an issue because most Cloud provider resources have predictable IDs but as soon as you have one that doesn't you are up for a lot of pain and suffering.

Re: Terraform 1.0

#54

Post by type_Ben_struct »

jansan wrote: post #42

Can someone explain in a few words what this is and who may be interested in this? The name does not give any hints, also the discription tells me nothing: "Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned…

Seems pretty clear to me based on the description. What specifically are you unsure about?

Re: Terraform 1.0

#55

Post by HatchedLake721 »

jansan wrote: post #42

Can someone explain in a few words what this is and who may be interested in this? The name does not give any hints, also the discription tells me nothing: "Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned…

This is a tool to manage your infrastructure (AWS/GCP/Azure/etc) as a code.

You write code, apply it, cloud providers spin up resources you declared, you commit your code (infrastructure) to git.

Now your infrastructure is version controlled, can be "easily" build from ground up in minutes, instead of someone doing 3124 things manually in the UI.

Re: Terraform 1.0

#56

Post by appleflaxen »

throwaway894345 wrote: post #31
kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

I strongly agree both with respect for the half-baked-ness of the language and with the "it's probably the best out there". Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. Users could use some vanilla progr…

> these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY

the last five words are a bit of a double negative; i think you mean "without the repetition" but I can't tell.

Re: Terraform 1.0

#57

Post by zubnix »

rantwasp wrote: post #35
nautilus12 wrote: post #29

You people hating on Terraform are spoiled. My company insists on using CloudFormation, which I hate with a passion.

your company sounds like they know what they are doing. Cloudformation will take your infrastructure from point A to point B or roll it back in case of failure. Terraform, not so much.

So much this. If you hate cloudformation, have a look at CDK, which allows you to programmatically define a stack in a language of your choice, instead of trying to use unreadable huge yaml to write code.

I really wish terraform will one day reach the same features and maturity as cloudformation.

Re: Terraform 1.0

#58

Post by heydonovan »

kerng wrote: post #37

Serious question. What value does Terraform provide? Two years ago I looked into it and rather then having an abstraction from cloud providers it seemed to require to still target (and code against) each one specifically. So, I was quite disappointed as I thought the value proposition was to not have to know x cloud provider specific terminologies. Any insights much appreciated. Edit: I was a little worried asking su…

I'll chime in. When I first used Terraform, it was described as this tool that would create resources in a cloud agnostic way. That's still possible, but not the main focal point.

Terraform just takes any API (called terraform providers) and applies the GitOps philosophy to it. That's it. Now you can easily recreate resources with a single command, modify whatever parameters you need, store those changes in Git, etc.

Yes, one long curl command would give you the same results but then you miss out on the concept of dependencies or API versioning or simple programming constructs like reading from a file or looping over values.

Re: Terraform 1.0

#59

Post by yunwal »

tonyhb wrote: post #36
granra wrote: post #25

Earlier quoted context omitted.

People mention pulumi but hashicorp are creating something similar with https://github.com/hashicorp/terraform-cdk . But all the existing terraform providers work with it afaik.

I don't know if people have even tried Pulumi before recommending it. I've tried it, and it has buggy defaults, diff generation, etc. Each time I applied the same code, it would generate a diff based off of some internal defaults and... recreate the exact same infrastructure by _tearing it down_ and making it fresh. Not ideal. Would advise using the TF CDK specifically.

I wouldn't recommend using cdktf either yet. Can't manage multiple stacks in a single repository, no full support for input variables, constant breaking changes. It's not production ready at all.

Stick with terraform if you need to provision non-aws resources. Otherwise, use aws-cdk.

Re: Terraform 1.0

#60

Post by kevincox »

cube2222 wrote: post #14
kevincox wrote: post #9

I hate Terraform with a passion but it is probably the best tool out there for managing cloud infrastructure so I use it at work with no plans to replace it. The biggest downsides are the awful half-baked language and the awkwardness of modules and passing values throughout your config. Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it. Th…

> The biggest feature I would like to see is the ability to dump a pure representation of your evaluated configuration. This would allow reasonable diffs in CI. There are of course complications, especially if you use `data` resources but technically it is possible to do a very good job here which would make it so much easier to make changes. The planned state, current state, and diff of them are all available as sep…

The key word is "pure" here. These things all depend on the current state of the infrastructure. The "planned state" is close to what I want, but it can be very confusing if someone has deployed a new change since you forked off.
Post reply on HN