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

Terraform 0.12

hashicorp.com

Post reply on HN
Print view View original

151–160 of 167 posts

Re: Terraform 0.12

#151

Post by kraig »

cs02rm0 wrote: post #65
jjeaff wrote: post #61

Earlier quoted context omitted.

I used terraform with my AWS deployments because there were lots of examples and I pretty much was able to find a solution that matched my problem and copy paste. Then, I needed to launch infra in GCP and I messed around with terraform unsuccessfully for a few days before writing about 10 lines of gcloud CLI commands into a makefile. Now I just check a makefile into my project and just break things up into little she…

I'm so tempted to do abandon CloudFormation for a Makefile with AWS cli commands. If there wasn't a chip on my shoulder telling me I had to use what the next person would expect else as a contractor I risk being seen as unprofessional I'd do it in a heartbeat. I've never used Terraform but CloudFormation just seems to suck, the documentation is poor and relatively few people are sharing their stack files. I've lost c…

IMO both of you guys should take a look at Pulumi. You could still use a makefile but using their TS clients to access the APIs is much more intuitive and easier to diagnose than shell scripts.

Re: Terraform 0.12

#152

Post by NikolaeVarius »

marenkay wrote: post #142
ben0x539 wrote: post #99

Earlier quoted context omitted.

> The whole situation about state management is... lacking. Experience says the one thing no client ever wants in the cloud but always on prem is state. Hm, can you elaborate? S3 state seems perfectly serviceable, and I don't immediately see why I would want to operate on-prem resources just to maintain state.

S3 is Amazon. In some cases you want to exert control over your state without being dependent on external parties. Currently Terraform Enterprise is the only approach to solving that and its a good one but... only if you're one of the big guns and even those sometimes think twice because the infrastructure state requires much more security than that offers.

There is nothing stopping you from backing up state in s3 and git. Just have CICD to sync it up.

State really shouldn't have anything secret in it in the first place, so 3rd party having access to it shouldn't matter.

Re: Terraform 0.12

#154

Post by 420codebro »

SlowRobotAhead wrote: post #29
pensatoio wrote: post #16

Earlier quoted context omitted.

As others have said, no exporting is involved. You write roughly-json-esque code which you then apply to a cloud provider. The state of the infrastructure is stored, ideally, in the cloud. You apply your code during which terraform identifies which changes need to be made by comparing the current state with your local changes and executes those changes as you watch. The end result is well-defined, testable, repeatabl…

>Infrastructure as code. Store it in git. Profit. Ok. But so is CloudFormation YAML files, mostly. So is the advantage of Teraform that it works beyond AWS?

My opinion? Because CloudFormation is full of shit regarding "always being able to rollback". After dealing with a 100+ failed CF rollbacks, I stopped caring about that phantom feature. That's around the same time I started using Terraform. At this point I only use CF for things I can not put in TF directly - namely ASGs.

Regarding IaC "rollback" capabilities - I don't think it really exists in a way that makes it reasonable for people to depend on. The path forward is to stand up new infrastructure, canary test, etc - then steer via load-balancers the traffic to your new nodes, and then finally destroy the old ones. I loathe trying to maintain a fleet of nodes that can drift into various states of dis-repair. I love the idea of blowing everything away and having a 100% clean and predictable environment again. It makes me happy.

Hope that helps - I really have fallen in love with Terraform after having to cobble down N number of CLI tools for various cloud providers, hypervisor providers, etc. Terraform at least gives an easy to use language and abstracts me above recursive API call logic that I would otherwise need to write for basic things.

Re: Terraform 0.12

#155

Post by 420codebro »

EdwardDiego wrote: post #11
SlowRobotAhead wrote: post #5

I’m a little unclear on terraform in practice. As you supposed to download this, use it’s language and syntax which is all it’s own thing, to define you services and then export that to a YAML setup that AWS CloudFormation (for example) is expecting? I assume there are reasons I wouldn’t just define it myself in YAML directly?

Basically Terraform is cloud agnostic, so you can (theoretically) define something in Terraform and then use it on AWS, or GCP, or Azure.

Wrong. Each provider has their own parameters and dependancies.

Re: Terraform 0.12

#156

Post by goatinaboat »

_t0du wrote: post #15

I honestly love Terraform as a product. It was one of probably three tools I've used in my entire career that made me feel immediately more productive. After using it for a very short period of time I was shocked developers continued to struggle through CF templates and the fragility the whole process entailed.

My experience of TF is very much the opposite. It looks fantastic on paper (well, in the browser) and I was excited to start using it. But the shine quickly wore off. It claims to be multi-cloud but it's not as if you can take some TF from AWS and run it on Azure - it's a rewrite. And it claims to be able to import existing, running cloud configurations so migrating to it should be easy, but it doesn't work, so that's a rewrite. And it is terrible at modifying existing things, the developers of TF seem to be believe that destroying everything and rebuilding from scratch is the way to, say, add another node. Of course by the time you figure all this out you have invested so much political capital in persuading the organisation and your peers to adopt it that you're stuck with it. But the lesson is really, use whatever is native to each cloud, such as CF on AWS, beyond any trivial deployment you're locked in anyway, might as well enjoy it.

Re: Terraform 0.12

#157

Post by guitarbill »

ReidZB wrote: post #134
guitarbill wrote: post #89

Earlier quoted context omitted.

> can detect configuration drift, but not correct it if by "correct it" you mean update the current template to match what's there, that'd be good, as AFAIK there's no easy way to do this at the moment. if by "correct it" you mean revert or change resources, no thanks. that sounds like a production accident waiting to happen, and you can un-drift (?) resources manually already.

I do mean revert or change resources. Making manual changes outside the context of an IaC tool is largely madness, in my opinion, although sometimes the situation warrants it. Auditability and controls are one of the many facets of IaC. We require code changes to be approved by another developer, and similarly we require infrastructure changes to be approved by another developer. Regularly working outside the IaC too…

AWS Config proves additional guarantees/monitoring/auditing, but many people don't use it cause it costs money.

Re: Terraform 0.12

#158

Post by ReidZB »

guitarbill wrote: post #157
ReidZB wrote: post #134

Earlier quoted context omitted.

I do mean revert or change resources. Making manual changes outside the context of an IaC tool is largely madness, in my opinion, although sometimes the situation warrants it. Auditability and controls are one of the many facets of IaC. We require code changes to be approved by another developer, and similarly we require infrastructure changes to be approved by another developer. Regularly working outside the IaC too…

AWS Config proves additional guarantees/monitoring/auditing, but many people don't use it cause it costs money.

Speaking of, they recently changed the pricing model for (part of) Config. It should be much cheaper now. https://aws.amazon.com/blogs/aws/new-updated-pay-per-use-pri...

Re: Terraform 0.12

#159

Post by rglauser »

the_duke wrote: post #104
zbentley wrote: post #59

Earlier quoted context omitted.

Someday folks will rediscover the potential of Puppet for these use cases. Until then, I'm content to watch countless alternative implementations come and go.

The nice thing about Terraform (and Ansible) imo is that they don't require a daemon but just run locally (or on CI), with some shared state in a object store.

Here's how Lyft used "Masterless SaltStack at Scale" https://youtu.be/7ffHKH9H5_Q and the getting started documentation https://docs.saltstack.com/en/latest/topics/tutorials/quicks...

Re: Terraform 0.12

#160

Post by SlowRobotAhead »

dvcrn wrote: post #35
SlowRobotAhead wrote: post #29

Earlier quoted context omitted.

>Infrastructure as code. Store it in git. Profit. Ok. But so is CloudFormation YAML files, mostly. So is the advantage of Teraform that it works beyond AWS?

For me yes. I can do things like: Spinup a kubernetes cluster, add a deployment with the latest image from my docker registry, add a loadbalancer with an external IP and create a cloudflare A record for my domain with that IP - all within the same tool.

Ok, but if you are (as in my case) staying entirely in AWS dynamo, lambda, E3, and IoT Core... it seems less important.

I never leave the AWS ecosystem at all.

I’m not challenging what you do, just trying to figure out what makes sense for me.

Post reply on HN