Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Terraform 0.15 General Availability

hashicorp.com

Post reply on HN
Print view View original

71–80 of 239 posts

Re: Terraform 0.15 General Availability

#71

Post by xyzzy123 »

k__ wrote: post #64
theopsguy wrote: post #62

Earlier quoted context omitted.

If you like CDK, then i highly recommend pulumi

How do they differ?

So regular CDK is basically a program-driven CFN generator.

Pulumi has a similar model where you build a resource graph at runtime BUT it's also got the execution engine built-in to the tool.

What this means in practice is that you can create resources (like a kube cluster) and then use them as providers (e.g provision state tracked resources with kube api) all in the same operation.

You can also (in your infracode or an importable module) define "dynamic providers", meaning you can easily extend the execution engine to do custom things related to your workload.

As an example, imagine you want to create a cluster, deploy an app, then provision (state tracked) some app resources like an admin user and group via the app's REST API. You can do that without too much fuss.

Neither terraform nor CDK can really do those things very well. TF is not powerful enough language-wise, and in CDK the execution phase is locked away from you.

Re: Terraform 0.15 General Availability

#72

Post by erik_seaberg »

hrktb wrote: post #68
Chilinot wrote: post #28

Earlier quoted context omitted.

Terraform allows us to implement development practices into our sysadmin lives. Such as code reviews, etc. For example, at my work this is what i do to apply changes to our AWS setup: 1. Fetch the latest version of our git repo. 2. Create a new git branch named after the Jira ticket im working on. 3. Solve the jira ticket by modifying the terraform code accordingly. 4. Submit a pull request and assign one of my colle…

Reading the sister comments, I kind of understand the appeal of terraform for huge/multi cloud infra systems. Now, managing changes in code doesn’t look too far from dealing with kubernetes’ json/yml config and applying them to the current cluster, provided it would be trickier when expanding to multiple cluster or doing complex orchestrating. I guess TF makes a lot more sense for on-premise, bare metal VMs ?

Also cloud hosted services. E.g., terraform knows how to manage hundreds of AWS resource types (IAM roles, DynamoDB tables, S3 buckets), sometimes even before CloudFormation does.

There seems to be some kind of https://github.com/aws-controllers-k8s/community in early beta, but I don’t know how much it supports so far or whether it can diff a resource and modify it in-place.

Re: Terraform 0.15 General Availability

#73

Post by tilolebo »

Thaxll wrote: post #55
pizza234 wrote: post #52

Earlier quoted context omitted.

While it's not possible to make an apple-to-apple comparison (Terraform-to-?), if we compare to something based on an imperative language, say Puppet or Chef, there is a huge difference. In my opinion, Terraform's big issue is that it was born as a declarative tool for managing infrastructure. Large configurations (IMO) necessarily ossify, because you don't have an imperative language that makes small progressive cha…

I have really bad memories of the change between puppet 2 and 3 for example.

Same. I went through a puppet 2->3 migration and also through a terraform 0.11->0.12 update.

The puppet migration was definitely more painful, because of the entangled code.

Re: Terraform 0.15 General Availability

#74

Post by erik_seaberg »

cmclaughlin wrote: post #25

On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL. I've really enjoyed modeling my AWS environments with Python using Terraform only as the engine. More info here: https://github.com/hashicorp/terraform-cdk

I really wish CDK supported writing a Terraform plugin in any of those languages.

Re: Terraform 0.15 General Availability

#76

Post by timdev2 »

llbeansandrice wrote: post #50
mr_C wrote: post #45

Earlier quoted context omitted.

Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the exist…

I haven't used Ansible so maybe I'm incorrect here but aren't tf and Ansible solving slightly different problems? Terraform feels like infrastructure management to me. We use it to provision underlying resources: Networking, Clusters, Nodes, Alerts, etc. All of the actual code deployments are entirely separate. Ansible is more of a configuration management right?

Right. And you can use something like terraform-inventory[0] as a dynamic inventory source in Ansible. So TF manages all the bits and bobs floating around in AWS, and then ansible takes over to manage configuration on whatever EC2 instances are involved.

[0]: https://github.com/adammck/terraform-inventory

Re: Terraform 0.15 General Availability

#77

Post by ncallaway »

mr_C wrote: post #56
diroussel wrote: post #51

Earlier quoted context omitted.

If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whe…

Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.

> Who cares if there is a dangling dns records somewhere or an extra allocated floating ip

What if instead of a dangling dns record, its 15 large EC2 instances?

Yes, you can come up with examples of trivial dangling resources, but it's just as easy for me to come up with non-trivial examples of dangling resources.

Re: Terraform 0.15 General Availability

#78

Post by throwdbaaway »

llbeansandrice wrote: post #50
mr_C wrote: post #45

Earlier quoted context omitted.

Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the exist…

I haven't used Ansible so maybe I'm incorrect here but aren't tf and Ansible solving slightly different problems? Terraform feels like infrastructure management to me. We use it to provision underlying resources: Networking, Clusters, Nodes, Alerts, etc. All of the actual code deployments are entirely separate. Ansible is more of a configuration management right?

Not really. In terms of functionalities, I consider ansible as a superset of terraform, without all the state management stuffs. Distributed systems are hard, and I will just let my cloud providers to be the single source of truth of all the states.

Here's a comment from the author of ansible when terraform was first released: https://news.ycombinator.com/item?id=8100036

> One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.

Re: Terraform 0.15 General Availability

#79

Post by [deleted] »

wooly_bully wrote: post #61
dastx wrote: post #60

Earlier quoted context omitted.

> What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can use where I can abstract away some of the difficulties of learning to use Terraform natively for simple use cases (i.e. deploy an S3-based frontend host). Maybe not node/python, but I'm pretty sure you can use terraform as a package in go. If not, there is always the "make temp d…

That's good to know at least; will give the go API a look. The latter option you're recommending is essentially what I went with (Node bin script that shells out to run cdktf commands).

[deleted]

Re: Terraform 0.15 General Availability

#80

Post by throwdbaaway »

2ion wrote: post #27
dxxvi wrote: post #18

My tiny brain still don't get why people like terraform. Do people need to look at both terraform docs and aws/azure/gcp docs when writing a .tf file? The fact that terraform saves/remembers the resource states is like a double-edged sword: we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform

What else to use? All other tools operate at the same level as terraform, be it cloudformation or anything else. It's just drivers for the cloud API in question, each with their own drawbacks, idiocracies, limitations and workarounds. In a sense, these are all equal effort for the user.

Ansible? Compared to terraform, it should require less effort from the user, without having to worry about states. Compared to aws cloudformation or gcp cloud deployment manager, it should require less effort as well, without having to learn the different idiosyncrasies of these proprietary tools.

> It's just drivers for the cloud API in question

Exactly, and if you are on gcp, both the ansible modules and the terraform modules are even generated from one code base: https://github.com/GoogleCloudPlatform/magic-modules

Post reply on HN