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

191–200 of 315 posts

Re: Terraform 1.0

#191

Post by polynomial »

kevincox wrote: post #52
throwaway894345 wrote: post #31

Earlier quoted context omitted.

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 resource…

What are some of the tools that do this? The only ones I know of are Scalr and Pulumi.

Re: Terraform 1.0

#192

Post by jen20 »

sverhagen wrote: post #184
jen20 wrote: post #175

Earlier quoted context omitted.

The specific tool recommended here is simply not very good - despite the language server efforts, the IntelliJ HCL plugin is worlds apart from the VS Code tooling (and has been for years). Unfortunately it's not open source - if it were it would mean the availability of an open source implementation of a production quality HCL2 parser for the JVM ecosystem, which would be very useful.

I have really liked the Terraform support in IntelliJ, but the "HashiCorp Terraform / HCL language support" plugin seems to have had its most-recent release on July 17, 2020[1]. And it clearly does not support a bunch of the newer constructs and properties. And that's just very unfortunate. [1] https://plugins.jetbrains.com/plugin/7808-hashicorp-terrafor...

Any examples of things that aren't supported? It doesn't need to embed the metadata per-resource anymore.

Re: Terraform 1.0

#193

Post by joombaga »

etxm wrote: post #114

People tend to complain about HCL a lot, I think it’s a great language for infrastructure. I don’t want a “real programming language” for provisioning infrastructure. I feel like every time I’ve seen someone “need” a real programming language, that there is a _better_ way to do the task at hand with HCL. That being said, there are some ugly bits. 1. Remote state as a data source means your infra is broken, you just d…

I'm not sure I understand #1.

Your points would still apply if a resource (e.g. aws_instance.foo) is created in one module and then referenced as a data source (e.g. data.aws_instance.foo) in another module. Are you suggesting remote state is different? Or would you also advise against referencing data source attributes from resources created in other modules?

Re: Terraform 1.0

#194

Post by rantwasp »

Thaxll wrote: post #167
rantwasp wrote: post #35

Earlier quoted context omitted.

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.

> roll it back in case of failure Until it doesn't. How many times I've seen stack being in error because could not rollback. CF can't do trivial things like creating a resources in account A that is needed for account B.

lol. Terraform cannot do basic things like rollback the deployment in case of failure. Also, I have yet to see CF losing track of its resources.

Here is a challenge for you: Deploy a moderate to complex infra with Terraform and after that try to clean up all the resources it created. 50$ says Terraform cannot do it and you need some sort of manual/script intervention. The future is bright.

Re: Terraform 1.0

#196

Post by rantwasp »

zubnix wrote: post #57
rantwasp wrote: post #35

Earlier quoted context omitted.

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.

to be fair to Terraform, this is hard. It's hard when you are dealing with multiple cloud providers since you have to keep state somewhere. Network failures or underlying cloud failures are gonna impair TF in the head every time.

If there is one thing TF needs to learn to do is handle failure. Right now it has that rosy yolo approach leaving you to pick up the pieces when it fails.

Re: Terraform 1.0

#197

Post by thayne »

acdha wrote: post #190
stevehawk wrote: post #179

Earlier quoted context omitted.

it took 5 years to get that useful for_each for modules though so I'd imagine some people waited long enough that they moved on to better tools.

What better tools do you have in mind? Most of the people I know in the space have been moving _to_ Terraform, although CDK has improved enough over CF to be appealing for people who are all in on Amazon.

"better" is subjective. But Pulumi fixes a lot of the pain points of terraform for me.

Re: Terraform 1.0

#198

Post by asenchi »

stevehawk wrote: post #179
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…

it took 5 years to get that useful for_each for modules though so I'd imagine some people waited long enough that they moved on to better tools.

for_each is an anti-pattern for reliable Terraform IMO. Not sure it was worth the wait and there isn't much out there that can compare with the simplicity of Terraform.

Re: Terraform 1.0

#199

Post by thayne »

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…

It's a lot better than it used to be. But there are still quite a few annoyances. For example, you still need to use count as a hack for the absence of any kind of "if". You can't make custom functions. Modules can be kind of awkward to work with. There are still some places that can't take any dynamic values such as lifecycle.ignore_changes and arguments to providers and backends.

Re: Terraform 1.0

#200

Post by devonbleak »

asenchi wrote: post #198
stevehawk wrote: post #179

Earlier quoted context omitted.

it took 5 years to get that useful for_each for modules though so I'd imagine some people waited long enough that they moved on to better tools.

for_each is an anti-pattern for reliable Terraform IMO. Not sure it was worth the wait and there isn't much out there that can compare with the simplicity of Terraform.

WAY more reliable than count which would do screwy things like rename a bunch of stuff and delete the last item if you removed an item from the middle of a list.

Complex architectures and reusable module encapsulation require a bit more complexity than HCL1 was capable of describing IMO (and apparently the O of most of the Internet). That doesn't necessarily make it less reliable.

Could I describe my infrastructure "reliably" just using raw resources with no loops? Sure but that sounds like a nightmare to both build and maintain.

Post reply on HN