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

151–160 of 315 posts

Re: Terraform 1.0

#151

Post by throwaway894345 »

gjhr wrote: post #143
throwaway894345 wrote: post #117

Earlier quoted context omitted.

> 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. Not quite the same, but in vanilla Terraform if you simply rename a resource it will tear it down and recreate it even though the resource itself hasn't changed. Makes refactoring really painful. I think you can work around…

terraform state mv [old name] [new name] I'd much rather explicitly state when real resources are renamed than have terraform diffing my code and guessing whether I wanted to rename it or I am actually trying to recreate something. I can only imagine the headaches that would happen with a tool trying to track changes to infra as well as changes to code without explicitly tying infra state to version control somehow.…

> I'd much rather explicitly state when real resources are renamed than have terraform diffing my code and guessing whether I wanted to rename it or I am actually trying to recreate something.

But you're not renaming real resources, you're just renaming the Terraform identifier that corresponds to them. There's no reason that changing this identifier should destroy and recreate the resource it corresponds to. If you explicitly want to destroy and recreate it, you can change an attribute that forces a recreation (typically a "name" field or whatever identifier the resource's provider cares about).

Re: Terraform 1.0

#152

Post by ciisforsuckas »

borplk wrote: post #141

I recently had to do a piece of AWS work that required cross-account resources (create certificate in one account with ACM, set DNS entries on Route53 in another account). Not sure about pulumi, but AWS CDK and CloudFormation can't handle that as one step (there are some horrific hacks). With Terraform it's absolutely trivial. I was liking CDK up to that point, but that limitation is a complete deal breaker for me. H…

There are dozens of these examples. I switched a few years back after AWS released the automataic HTTP to HTTPS redirect functionality in ALBs and 6 months after release it still wasn't supported in CF. Terraform isn't perfect and it still has a ton of isues but it's rate of innovation is way a head of CF.

Re: Terraform 1.0

#153

Post by solatic »

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…

Writing infrastructure as code is quite often an exercise in:

a) define what I want b) write an API call to find out whether what I want already exists c) write an API call to create it if it doesn't exist d) Sometimes people do stuff manually and your code should tolerate working around these manual changes (i.e. update in place when possible, tear down and recreate when not possible) e) To be efficient, your code should run things in parallel when possible

Terraform allows you to write (a) and outsource the rest to a provider (b,c) usually maintained by the API provider themselves or Terraform itself (d,e)

Re: Terraform 1.0

#155

Post by himinlomax »

tornato7 wrote: post #138
himinlomax wrote: post #69

Earlier quoted context omitted.

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.

Is it a Go problem or a new-to-Go problem? I haven't written terraform plugins specifically but I have been writing Go for years and never find myself needing to write an excessive amount of boilerplate. There can definitely be some frustrations in dealing with dynamic JSON though. JSON-to-Go converters are your friend.

I was not using anything special, I had implemented my own client for IPA. Te equivalent functionality in Python (ended up using Ansible to do my thing) uses just a few kB ...

Re: Terraform 1.0

#156

Post by chousuke »

polskibus wrote: post #128

Does anyone use terraform for onpremise clusters? If so, what is your setup, what hypervisor do you use it with? Are you happy with it? Or maybe you would rather replace it with a set of ansible roles?

I set up Terraform with libvirt for my local VM host; I think it's much better suited for managing infrastructure components than Ansible is.

Outside personal stuff, I've done a few environments where the (mostly unchanging) infrastructure is set up with Terraform and then configuration and operations (like upgrades) are orchestrated with Ansible, and it works well.

Now, I bet someone might be tempted to claim you should never even need to upgrade VM instances and immutable infrastructure solves everything, but sometimes it's just ridiculously simpler to do in-place upgrades; orchestrating image building, testing and deployment is not easier than running an Ansible playbook to do in-place upgrades unless you already have infrastructure that does it for you.

If the software you're installing is properly written and provided via OS package managenment, often you just don't gain enough benefit from immutable systems considering the overhead.

Re: Terraform 1.0

#157

Post by Xophmeister »

polskibus wrote: post #128

Does anyone use terraform for onpremise clusters? If so, what is your setup, what hypervisor do you use it with? Are you happy with it? Or maybe you would rather replace it with a set of ansible roles?

We have an on-site OpenStack cluster and use Terraform in an ad hoc way for managing (some) infrastructure. It's by far the easiest way to do so, opposed to OpenStack's API and SDK (the latter of which is so poorly documented it beggar's belief!). Ansible is usually used in tandem with Terraform, to decouple the infrastructure and configuration management.

Re: Terraform 1.0

#158

Post by throwaway894345 »

cormacrelf wrote: post #125
kevincox wrote: post #52

Earlier quoted context omitted.

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…

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.

I don't even understand why the state needs to know the identifiers that the high level language uses for various resources. If the high level language has a binding "foo_bucket" for an AWS S3 bucket resource with a single property `name = "foo"`, then why should the state need to know that the high level language refers to that bucket with the name "foo_bucket"? Instead, the state should look something like this (obviously simplified):

    {
        "resources": [
            {
                "type": "aws_s3_bucket",
                "properties": {"name": "foo"}
            }
        ]
    }
Note that there is no reference to "foo_bucket".

Re: Terraform 1.0

#159

Post by solatic »

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 be credentials / other secrets that are not loaded from environment variables by providers. A great public example of this usage pattern is supplied by https://github.com/concourse/governance to manage their GitHub repositories.

Re: Terraform 1.0

#160

Post by kubanczyk »

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…

> having an abstraction from cloud providers

I kinda expected to see many examples of this in this thread (whether they use Terraform or not). So, to ask explicitly: are there usable abstractions of the type "use-case-achievable-with-3-top-public-clouds"? Even something extremely simple like a bunch of linuxes behind a regional load balancer. I don't mean the lowest common denominator of all the clouds, but just a few popular ones, with an obvious intention to reduce vendor lock-in.

These would be probably very basic scenarios, but still the whole multi-cloud hype could have produced something decent-ish by now?

Post reply on HN