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

101–110 of 315 posts

Re: Terraform 1.0

#101

Post by lowercase1 »

kevincox wrote: post #60
cube2222 wrote: post #14

Earlier quoted context omitted.

> 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.

Yeah. I have a poor view of terraform since my first interaction was trying to a few one line changes to avoid repetition but couldn't find why it didn't work without setting up connection to the AWS S3 bucket.

Re: Terraform 1.0

#102

Post by throwaway894345 »

nuker wrote: post #97
oneplane wrote: post #94

Earlier quoted context omitted.

Problem with CloudFormation is that it doesn't work with Cloudflare, Azure, GCP, Big-IP, Palo Alto, NetBox etc..

Its a problem only if you use these vendors, you don't have to.

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.

Re: Terraform 1.0

#103

Post by throwaway894345 »

Hasnep wrote: post #73
appleflaxen wrote: post #56

Earlier quoted context omitted.

> 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.

"without DRY" in this case means "with repetitions" i.e. in a verbose way. GP wants to be able to generate this verbose, machine readable syntax with DRY, human readable syntax.

Yes, this. Thanks for clarifying for me, apologies to the parent for my lack of clarity.

Re: Terraform 1.0

#104

Post by StopHammoTime »

gouggoug wrote: post #87
nrmitchi wrote: post #34

Earlier quoted context omitted.

I'd love to see an example of this actually working, because I have had the opposite experience (explicitly with the Kubernetes and Helm providers); I've had to do applies in multiple steps.

This should work (as in, it will create the cluster and only then add the k8s resource to it, in the same plan/apply). Here the module creates an EKS cluster, but this would work for any module that creates a k8s cluster. module "my_cluster" { source = "terraform-aws-modules/eks/aws" version = "17.0.2" cluster_name = "my-cluster" cluster_version = "1.18" } # Queries for Kubernetes authentication # this data query dep…

I literally implemented this not a month ago. I don't understand the complaint at all. Terraform is easily able to orchestrate a cluster then use it's data to configure the provider. The provider details does not need to be available until resources are created using the provider, which won't occur until the EKS cluster is available.

Re: Terraform 1.0

#105

Post by oxplot »

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…

> for example you can't create a kubernetes cluster then add a resource to it

Of course you can! DM me if you want details.

Re: Terraform 1.0

#106

Post by StopHammoTime »

himinlomax wrote: post #69
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 tool is ok, but developing plugins for it shows how inadequate Golang is for the job. There's so much repetition and boilerplate required. I wrote a FreeIPA plugin a few years back, it handled just registering a host and the executable weighed over 100 MB! WTF? Haven't looked at that side of things lately, I wonder if it's different nowadays.

Definitely agree with this, Go is so verbose for the application. When I wrote a provider, I had the same problem. What made it even more worse is that I was connecting into an API that made use of dynamic json generation. So many interfaces and other hacks to get the json documents to parse correctly.

Re: Terraform 1.0

#107

Post by throwaway894345 »

MadVikingGod wrote: post #84
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…

Dang, your solution sound so much like kubernetes I'm not sure if you are joking or not.

Kubernetes is one conceivable incarnation, but it operates differently than other infra-as-code tools. Terraform, for example, builds a dependency graph of your resources and initializes them in order. Kubernetes doesn't care about dependencies, and it just keeps trying to create resources and things will fail until their dependencies come online.

Further, Kubernetes manifests are the verbose "assembly language" layer, so you still need something for humans that is DRYer.

We use Terraform to manage Kubernetes resources (as well as cloud provider resources) at the moment, but I think you can equally use cloud provider operators for Kubernetes and manage everything with Kubernetes--I haven't tried this yet so I can't comment. In the latter case, you would still need something to DRY up your Kubernetes manifests. Also, if you aren't running on Kubernetes and you just want infra-as-code, k8s is an expensive solution (in terms of operations).

What I was picturing was a more conventional infra-as-code diffing engine (like Terraform's) but with a more verbose interface similar to Kubernetes YAML.

Re: Terraform 1.0

#108

Post by oxplot »

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…

> Two years ago I looked into it and rather then having an abstraction from cloud providers

This is a misrepresentation I've seen multiple times and I don't know how it's come to be.

Terraform doesn't abstract resources. It simply supports all cloud providers and lets you intermix resources from different clouds inside a single project. Resources can depend on each other and use each other's attributes.

As an example, you can bring up a load balancer in AWS and create a DNS record for it on Cloudflare in a same Terraform project and maintain them together.

Re: Terraform 1.0

#109

Post by gouggoug »

oxplot wrote: post #105
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…

> for example you can't create a kubernetes cluster then add a resource to it Of course you can! DM me if you want details.

Yes you can, see https://news.ycombinator.com/item?id=27435269
Post reply on HN