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

111–120 of 239 posts

Re: Terraform 0.15 General Availability

#111

Post by matwood »

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.

Any dangling resources may cost money and/or open up security concerns.

Re: Terraform 0.15 General Availability

#112

Post by skywhopper »

rantwasp wrote: post #88

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…

Have you never had a failure with CloudFormation? Because when that happens you can’t see what’s going on and you often can’t get out of the situation without engaging support.

More often than not with Terraform, another apply will fix the problems you are complaining about. But if it doesn’t at least you have the power to fix it unlike with CloudFormation.

But ultimately whatever tools you use you will have trouble if you are unwilling to engage with them and learn how they work.

Re: Terraform 0.15 General Availability

#113

Post by matwood »

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?

Yeah. I use packer and ansible to build/configure AMIs. Terraform manages the configuration that launches said AMIs (through things like autoscaling, etc...).

Re: Terraform 0.15 General Availability

#114

Post by skywhopper »

llbeansandrice wrote: post #2

Perhaps off-topic but how have people upgraded TF codebases to new versions? Just last year we had a big effort to upgrade a huge code-base from 0.11 to 0.12. I feel like it should be a lot smoother than a full-team full-sprint effort.

After 0.12 it has been much easier.

Re: Terraform 0.15 General Availability

#115

Post by rantwasp »

skywhopper wrote: post #112
rantwasp wrote: post #88

I do not like terraform and I believe it's a terrible tool. Here is the error you get when it fails: Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure. If that error does not give you pause, I don't know…

Have you never had a failure with CloudFormation? Because when that happens you can’t see what’s going on and you often can’t get out of the situation without engaging support. More often than not with Terraform, another apply will fix the problems you are complaining about. But if it doesn’t at least you have the power to fix it unlike with CloudFormation. But ultimately whatever tools you use you will have trouble…

I gonna share something shocking here: but I have never seen Cloudformation crap out in a manner that was not consistent and clear. Usually it will either try until it succeeds or fail in a clear and predictable manner.

(I have been using AWS since forever and both Cloudformation and Terraform(sad panda) for years. I will preach the shortcomings of terraform to everyone that listens. I have rarely seen developers using it for something non-trivial and being happy about it)

Re: Terraform 0.15 General Availability

#116

Post by lukehoban »

wooly_bully wrote: post #59
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

The 'not using HCL' bit is really the only positive I've found so far because everything else has been more difficult than just using TF directly. I think my goals were slightly off from the beginning, because this is really just replacing one CLI with another for me at this point. What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can…

> 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). Ideally, I had intended to distribute some npm-installable packages which would run this stuff.

This is actually exactly the use case we’ve designed the Pulumi Automation API (https://www.pulumi.com/blog/automation-api/) to support.

Allowing modern IaC technology (like Pulumi or Terraform) to be easily embedded into custom software solutions, instead of just being something humans work with directly, is a huge potential enabler for the next wave of cloud infrastructure management tooling.

Re: Terraform 0.15 General Availability

#117

Post by psadauskas »

rantwasp wrote: post #104
oxplot wrote: post #95

Earlier quoted context omitted.

> use whatever the cloud you are using has built it (cloudformation, deployment manager, etc). Not applicable if you're deploying infra across cloud (we do that across a dozen cloud providers!). Without terraform, it'll bring us tears. > Or about when it just loses tracks of resources. Never had this in years of using terraform. These should be qualified with how often they occur. > Terraform does not automatically r…

nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. i wish we lives in a world where we could do cloud agnostic stuff but the reality is that you have your aws terraform files, your gcp terraform files and so on. Cloudformation? Like the tool that bring you from state A to state B or if it cannot rolls back to state A? Yeah. It’s an abomination for a tool to leave infra in a consis…

We use it all the time. Not to deploy to multiple "cloud providers", but to update dnsimple domains with the cloudfront endpoint, set hirefire rules for heroku dynos, and create kapacitor alerts. It's great that they can all reference vales from other services, and it's broken up by coherent services, rather than where it's being hosted.

Re: Terraform 0.15 General Availability

#119

Post by technocratia »

rantwasp wrote: post #104
oxplot wrote: post #95

Earlier quoted context omitted.

> use whatever the cloud you are using has built it (cloudformation, deployment manager, etc). Not applicable if you're deploying infra across cloud (we do that across a dozen cloud providers!). Without terraform, it'll bring us tears. > Or about when it just loses tracks of resources. Never had this in years of using terraform. These should be qualified with how often they occur. > Terraform does not automatically r…

nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water. i wish we lives in a world where we could do cloud agnostic stuff but the reality is that you have your aws terraform files, your gcp terraform files and so on. Cloudformation? Like the tool that bring you from state A to state B or if it cannot rolls back to state A? Yeah. It’s an abomination for a tool to leave infra in a consis…

>nah. i’ve heard the cross-cloud argument multiple times and it does not hold any water.

This, I use terraform every day at my work and I really like it compared to cloudformation but I never understood the cross-cloud advertisement. If I deploy, say, RDS cluster and Kinesis streams with terraform, how on earth is it cross platform?

Re: Terraform 0.15 General Availability

#120

Post by bogomipz »

xyzzy123 wrote: post #71
k__ wrote: post #64

Earlier quoted context omitted.

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 o…

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

What is CFN here? Cloudformation?

Post reply on HN