Terraform 1.0 • Hacker News Board

Re: Terraform 1.0

#271

Post by haolez » Wed, Jun 09, 2021, 1:53 AM UTC

saurabhnanda wrote: post #212

endymi0n wrote: post #209

Earlier quoted context omitted.

You‘re pretty much describing the idea behind Pulumi which got a lot of traction lately. Personally, I‘m still undecided on whether the unlimited freedom of a fully fledged programming language is a good or a bad idea in terms of footgun potential. I‘m also still a bit unsure whether to play early adopter for an extremely hyped VC open core project even though it feels tempting. Experiences appreciated!

Pulumi sounds interesting. Spent 10 mins with their marketing website and I'm not very clear whether it is a standalone set of libraries, or do they only work in conjunction with their cloud services. Do you know?

I've been using Pulumi for a new project after using Terraform for a long time. It's a little weird at first, but then it clicks and actually feels quite nice. The Input/Output logic with its async behavior is the weird part, but it works fine when you understand how it works.

The only (minor) problem that I've seen in it is that the JavaScript/TypeScript support seems more mature and featureful than the other backends. So, I'll simply use that.

Re: Terraform 1.0

#272

Post by throwdbaaway » Wed, Jun 09, 2021, 2:00 AM UTC

akvadrako wrote: post #136

xorcist wrote: post #130

Earlier quoted context omitted.

Why not use something like Ansible instead? It too is declarative. It too can be easily extended. It's also something a lot of people already know. I used to use Ansible or Puppet for these things before Terraform was all the rage. It was a lot more stable than trying to distributing those state files, which is a strange design to pick. There are plenty of existing modules but it's also dead simple to write your own.

Ansible is not really made for managing cloud resources and it shows - the modules are not production ready.

For GCP, both ansible modules and terraform modules are actually generated from https://github.com/GoogleCloudPlatform/magic-modules, so their "production readiness" are the same.

I understand that mitchellh himself personally created a bunch of cloud modules for terraform at the beginning, and those were likely of higher quality than whatever created by some internal developers assigned by Google/Microsoft, and might be slightly better than the AWS modules maintained by community.

Anyway, when it comes to ansible versus terraform, we shall move the discourse to states management instead. With ansible, you don't have to deal with states, but will need to clean up the cloud resources separately. With terraform, you can use the tool to clean up the cloud resources easily, but then you also have the headache of managing states. Plus, whenever you change something, there is always the nagging feeling that it will do a destroy/recreate instead of an in-place update.

Re: Terraform 1.0

#273

Post by takeda » Wed, Jun 09, 2021, 2:05 AM UTC

solatic wrote: post #159

Terraform is such an underappreciated tool. It seems like so much of the hate surrounds HCL1 (back in Terraform before 0.12) and doesn't reflect modern Terraform. For example, after introducing `for_each` and dynamic blocks, it's possible to nearly entirely ditch variables files and local modules, and just add more infrastructure by editing a local YAML file. The only variables your Terraform code should have should…

> Terraform is such an underappreciated tool

Are you kidding? It's the go to tool even for people who are brand new to IaaC.

If anything I would say CloudFormation is underappreciated a lot of reasons why TF was created were fixed almost a decade ago. TF users are still citing those things as the reason why they use TF without ever using it.

Re: Terraform 1.0

#274

Post by lmm » Wed, Jun 09, 2021, 2:13 AM UTC

throwaway894345 wrote: post #144

smaddox wrote: post #133

Earlier quoted context omitted.

This would be great. Perhaps it could be based on https://dhall-lang.org/

I absolutely think a statically typed language is the right way to go (from experience using a Python->CloudFormation generator even with Mypy), but Dhall is going to be really unfamiliar for most people and it's hard to sell people on new languages that are syntactically unfamiliar. As an aside, I think functional concepts could have made their way into mainstream programming much earlier if the FP people would have…

Nah, the syntax is superficial. Scala has offered better-than-Rust FP in a traditional syntax for over a decade, but if anything the tension between imperative and functional people is worse there.

Re: Terraform 1.0

#275

Post by abriosi » Wed, Jun 09, 2021, 2:17 AM UTC

I have a love & hate relationship with terraform.

It's so frustrating when you can't create a behavior.

But the joy of orchestrating infrastructure at scale with code is overwhelming <3

Re: Terraform 1.0

#276

Post by fierro » Wed, Jun 09, 2021, 2:58 AM UTC

throwaway894345 wrote: post #256

hpoe wrote: post #245

Earlier quoted context omitted.

But at the end of the day your infrastructure is essentially data not code. Your infrastructure is permanent, it exists even if it isn't being used it has inertia. At the end of the day your "infrastructure" is really just an entry in a database of a cloud provider, it is data not code. I think we are seeing things come full circle again where people are finding the limitations of declarative infrastructure tools and…

> But at the end of the day your infrastructure is essentially data not code. Your infrastructure is permanent, it exists even if it isn't being used it has inertia. At the end of the day your "infrastructure" is really just an entry in a database of a cloud provider, it is data not code. That may well be true, but it doesn't solve the problem (note also that HTML is just data , but we don't typically expect people t…

excellent summary of the problem.

Re: Terraform 1.0

#277

Post by PostThisTooFast » Wed, Jun 09, 2021, 3:08 AM UTC

Try saying WTF it is in the title.

Obscurity isn't cool, but it sure is trendy on this site. It's douchey.

Re: Terraform 1.0

#278

Post by jamesmishra » Wed, Jun 09, 2021, 3:36 AM UTC

I believe in the Terraform way of doing things. A lot of other people dislike the Terraform language, and then they use Pulumi because it allows them to write infrastructure in Python or JavaScript.

But I specifically DO NOT WANT my company's infrastructure to be written in a Turing-complete dynamically-typed language. I believe the Terraform language is safer.

However, one thing I don't like about Terraform is that it provides a lot of low-level APIs for cloud providers that can take a lot of glue code to string together into a real PaaS.

I solved this at my company by writing https://provose.com -- a Terraform module that a high-level API for configuring containers, buckets, databases, and distributed filesystems. Provose understands what you want to deploy and automatically figures out the needed VPC settings, security groups, IAM roles/policies/etc, Route 53 records, ACM certificates, and load balancer settings.

Apologies for the self promotion, but if you decide to try Provose, I'd be happy to help you through any issues you face :)

Re: Terraform 1.0

#279

Post by cmclaughlin » Wed, Jun 09, 2021, 3:42 AM UTC

yunwal wrote: post #59

tonyhb wrote: post #36

Earlier quoted context omitted.

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.

Support for multiple stacks in a single file was added to cdktf recently. I’ve been managing dozens of production stacks in a single repo for a while now and highly recommended it.

Re: Terraform 1.0

#280

Post by cormacrelf » Wed, Jun 09, 2021, 3:54 AM UTC

kevincox wrote: post #139

cormacrelf wrote: post #125

Earlier quoted context omitted.

It’s pretty wild that the object identity via name thing is still a problem. Can they not add a transitional name feature where an object is known by multiple aliases for a while and then when you have finished putting though a change, you can delete the original name? Is this not very basic SQL migration practice? Like column aliases until no longer needed.

Yeah, moving objects around the config is common if you want to keep it organized and requires manual actions that require essentially a global lock on the stack (and Terraform has no built-in feature to actually take this lock). It makes it basically impossible to implement a fully automated production change pipeline with Terraform.

Moreover I can never, ever, remember the syntax for moving objects around the config. It's really painful.

Edit: the aliases would have to handle moving as well as renaming. You could just have aliases in a global namespace, which means adding `alias = "portable-elb"` and doing one `terraform apply` means you can pick up that config, drop it anywhere else, and it will move it for you. It wouldn't even need to do a full `apply`, just a local JSON manipulation.