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

291–300 of 315 posts

Re: Terraform 1.0

#291

Post by bjelly »

saurabhnanda wrote: post #208

I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…

I'm closely tracking an effort by Microsoft that aims to do a lot of what you're describing since I find myself bridging between these tools and deploying stacks that span tools and roles. [CNAB](https://cnab.io/) and the front-running implementation, [Porter](https://porter.sh/), enable one-step infra deployments, packaged as a single OCI-compatible container, with any number of steps, using the best tools for each of those steps. Think of using aws-cli for some initialization step (create or verify presence of a state bucket), applying some terraform to create infra, and finishing with a helm chart to complete deployment of app components. Each stage in a bundle packages not only the code to run it but also the execution binary of the tool that runs it. The spec and porter are still a moving target but it's a promising space and a nice adjacent evolution of the current state of tooling.

Re: Terraform 1.0

#292

Post by StreamBright »

saurabhnanda wrote: post #208

I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…

Best thing is Dhall that I am aware of. Same situation, working as a consultant, forced to use broken things.

https://github.com/dhall-lang/dhall-kubernetes

Re: Terraform 1.0

#293

Post by ManWith2Plans »

polynomial wrote: post #290
ManWith2Plans wrote: post #40

Earlier quoted context omitted.

The token system is broken in TF CDK still and it's not ready for adoption. I've built two stacks with it but I'm back at terraform for now. I intend to explore pulumi though when the opportunity presents itself. I think using a Turing-complete language like typescript with mature tooling to define cloud infrastructure feels very natural and makes things much more manageable than using HCL. One thing I absolutely can…

> This is absent from terraform-cdk Curious to know how that is, or what an example would be? I don't see how you would have to give up state management with CDK, which I understand to be extending TF, not supplanting it.

@polynomial - You have to use the state API on the generated terraform. This means that you need to understand the structure of the generated terraform, and are dealing with generated .json files that require introspection to determine what terraform resource ids are prior to managing their state. It is possible to do, but if you're writing code, you don't want to have to worry about the generated json.

Re: Terraform 1.0

#294

Post by ManWith2Plans »

cmclaughlin wrote: post #279
yunwal wrote: post #59

Earlier quoted context omitted.

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.

And yet if you try to pass values from one stack to another, it will fail spectacularly.

Re: Terraform 1.0

#295

Post by tylermenezes »

saurabhnanda wrote: post #208

I've been sitting on the fence wrt Terraform and other such tools for quite some time now. After being _forced_ to finally write massive k8s YAML files (and ansible YAML files) for a consulting gig, I've been wondering whether these tools should be developed as _libraries_, that you glue together using a full-fledged programming language, instead of shoe-horning a programming language in YAML. For example, could the…

Supposedly Terraform supports it, though I haven't tried it: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...

Re: Terraform 1.0

#296

Post by throwaway894345 »

oneplane wrote: post #219
throwaway894345 wrote: post #102

Earlier quoted context omitted.

It's a pretty tough sell to tell people they have to uproot all of their existing infrastructure and move to Amazon just to use an infra-as-code tool.

It's also unlikely that you will only use AWS, forever. At some point in time you'll have to deal with various resources (be it IT resources, time, money or people-as-a-resource), and whenever you bind your knowledge and workforce to an IaC tool that doesn't transfer or isn't portable you're going to end up with N+1 tools every time. In other words: it doesn't scale all that well. (And that doesn't mean Google-scale,…

Agreed. If you use an auth service (SaaS or self-hosted) that isn't AWS Cognito you will also find yourself wanting to integrate with your IaC tool. Having to roll this yourself with CloudFormation is a lot of effort, or at least it was last time I looked, and importing a third party "provider" wasn't really a thing.

Re: Terraform 1.0

#297

Post by [deleted] »

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…

[deleted]

Re: Terraform 1.0

#298

Post by bionhoward »

I'd love to see more pass-by-reference in Terraform because it could simplify the API substantially. Right now you gotta figure out if you need to pass an id, name, or arn. forces a lot of reading docs and tight coupling.

if one could instantiate a resource by passing other connected resources into it by reference, then provider APIs could pull info they need, and could be refactored without affecting devs

Re: Terraform 1.0

#299

Post by throwaway894345 »

verdverm wrote: post #246
throwaway894345 wrote: post #239

Earlier quoted context omitted.

I looked at Cue and I don't understand what problem it solves. It certainly doesn't (seem) to solve the problem of DRYing up verbose YAML, or at least it's missing any notion of a function. "hey, these YAML blobs are all mostly the same, but they vary based on a couple of parameters--I should write a function that takes those parameters and outputs the right YAML object" ^ This is the #1 thing that the high-level lan…

CUE's philosophy is to wrap code in data, not data in code, as learned from the major configuration systems at Google. Being a logical language, rather than telling the computer what to do, you state facts and it verifies that you are correct. It is also intentionally not Turing complete do that you cannot program in CUE. CUE is gaining traction while still being young and changing. Grafana is adopting it for validat…

> Being a logical language, rather than telling the computer what to do, you state facts and it verifies that you are correct.

Sure--it's like advanced static typing for static configuration. But that seems like a different and lesser problem than DRYing up the configuration in the first place, and moreover if you use a statically typed programming language to DRY up your configuration then you get pretty similar guarantees to Cue. You don't get Cue's "unifying many definitions" approach, but I can't honestly discern the value proposition in that.

As for turing incompleteness, that's a nice to have at best. If I had to choose between a turing incomplete declarative language like JSON and a turing complete imperative language like Lua, I'd take the latter every single time.

Re: Terraform 1.0

#300

Post by polynomial »

pram wrote: post #67
syntaxstic wrote: post #47

Earlier quoted context omitted.

How does terraform compare to ansible?

They're not competition. I use Terraform for infra provisioning, and Ansible for post-provisioning application setup. I also use Packer + Ansible playbooks to build my AMIs.

What kinds of tasks can Ansible do that Packer isn't also capable of?
Post reply on HN