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

91–100 of 315 posts

Re: Terraform 1.0

#91

Post by mwcampbell »

eKIK wrote: post #77
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…

+1 from me on the "awful half-baked language" (HCL). I just recently wrote an article about my experience, including issues and workarounds, when migrating from Terraform to Pulumi: https://blog.ekik.org/my-experience-migrating-my-infrastruct... Hope it's OK that I'm sharing it here. I think it's relevant because there seems to be quite a lot of interest around Pulumi, and how one would go about moving from Terraform…

I'm actually thinking of going the other way. I've been using Pulumi for several months now, and I'm thinking of moving to Terraform, because it has a so much larger third-party ecosystem, including more providers, and tools that can analyze HCL, like Infracost and security scanners. When will I learn to see the bigger picture and value popularity over quality?

Re: Terraform 1.0

#92

Post by tdumitrescu »

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…

Yeah, these days I try to avoid writing any HCL and instead feed Terraform with JSON generated via jsonnet (which we were already using to generate k8s YAML). Much better templating and language features while still remaining declarative, and it helps on a team to have a single source language for such configs.

Re: Terraform 1.0

#93

Post by nuker »

throwaway894345 wrote: post #80
nuker wrote: post #63

Earlier quoted context omitted.

> Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. CloudFormation ? > There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. CloudFormation.

Yeah, CloudFormation is workable in this regard (I've created a neat generator for Python), although it has lots of its own problems (e.g., if you want to create a new resource, you have to run it as its own lambda--your infra-as-code needs its own infra which needs its own infra-as-code).

>if you want to create a new resource, you have to run it as its own lambda

Please don't, lol

Re: Terraform 1.0

#94

Post by oneplane »

nuker wrote: post #63
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…

> Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. CloudFormation ? > There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. CloudFormation.

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

Re: Terraform 1.0

#95

Post by weird-eye-issue »

RamRodification wrote: post #86
Lutger wrote: post #68

Earlier quoted context omitted.

Abstracting over Cloud vendors is not a use case for Terraform itself. The value it brings is that you get to specify your infrastructure 'as code', which means you'll be able to re-create it from code, and reliably deploy changes. There's a lot more benefits, it depends on what you are comparing it against. Coming from a software development background, I'd like to compare it to a wordpress app vs webapp development…

So... is Terraform the Wordpress app or the rails app? :D

Rails.

Re: Terraform 1.0

#96

Post by eKIK »

mwcampbell wrote: post #91
eKIK wrote: post #77

Earlier quoted context omitted.

+1 from me on the "awful half-baked language" (HCL). I just recently wrote an article about my experience, including issues and workarounds, when migrating from Terraform to Pulumi: https://blog.ekik.org/my-experience-migrating-my-infrastruct... Hope it's OK that I'm sharing it here. I think it's relevant because there seems to be quite a lot of interest around Pulumi, and how one would go about moving from Terraform…

I'm actually thinking of going the other way. I've been using Pulumi for several months now, and I'm thinking of moving to Terraform, because it has a so much larger third-party ecosystem, including more providers, and tools that can analyze HCL, like Infracost and security scanners. When will I learn to see the bigger picture and value popularity over quality?

It's a very interesting point.

I've been part of managing rather large Terraform infrastructures (1000+ resources) for a couple of years, but I'm a Pulumi n00b with only about a month of experience.

The infrastructure I'm managing right now with Pulumi is much smaller, only around 130-140 different resources.

For me it ultimately came down to developer productivity. I'm much better at convincing Pulumi to do what I want compared to how it was with Terraform. This also makes me a much happier and less frustrated developer :).

My priorities might very well be different if I were to manage much larger infrastructures (infra cost would be more important for example).

Re: Terraform 1.0

#97

Post by nuker »

oneplane wrote: post #94
nuker wrote: post #63

Earlier quoted context omitted.

> Ultimately, these tools should have a static/yaml-like "assembly language" that describes the state of your infrastructure without any of the DRY. CloudFormation ? > There would be a diffing engine which would figure out what changes need to be applied and apply them accordingly. CloudFormation.

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.

Re: Terraform 1.0

#98

Post by etxm »

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…

> Also the staticness of providers are a serious pain, for example you can't create a kubernetes cluster then add a resource to it.

TF def has some rough edges, but you can certainly create a cluster and add resources in a single root module (I don’t think it’s a great practice).

In this example the EKS cluster is in a module, but it can be a ref to a resource in the same module as well.

  data "aws_eks_cluster_auth" "current" {
    name = module.eks.cluster_id
  }

  provider "kubernetes" {
    load_config_file       = false
    host                   = module.eks.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks.cluster_certificate_authority_data)
    token                  = data.aws_eks_cluster_auth.current.token
  }

Re: Terraform 1.0

#99

Post by evilduck »

kevincox wrote: post #90
gerbilly wrote: post #82

Earlier quoted context omitted.

You can totally provision using ansible too, on most cloud vendors. The reason to use ansible over a shell script is that the ansible playbook will be idempotent. That is to say you can run/rerun the playbook from any point without having to wipe any previous work, or worry about double applying your config changes.

> is that the ansible playbook will be idempotent This isn't really true. I think you are correct that most of the built-in operations are idempotent but you can also do this with a small library of functions in a shell/python script or whatever you prefer. Most things you want to do on provision are idempotent anyways (install this package, download this file) or are trivial to make so (create this directory). I wou…

I thinj that it's difficult to keep an idempotent shell script or programming language implementation as clean as Ansible over a long period. I deal with a similar thing at work and the Ansible stuff is still mostly good over the long haul with the weird bits like calling other scripts being obvious. The Bash script provisioner we have is just a mess. It's not that an individual can't write a better Bash or Python script but a team of mixed experience, opinions and skillsets coming and going over 7 years definitely cannot. Our Ansible scripts are about half as old, but I don't think the shell script saw significant decline after hitting an inflection point or anything, they just gradually crept away from pure ideals.

I personally find Ansible's value lies in what it makes difficult.

Re: Terraform 1.0

#100

Post by zymhan »

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.

Fun fact: You don't even have to use Terraform
Post reply on HN