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

171–180 of 239 posts

Re: Terraform 0.15 General Availability

#171

Post by vbsteven »

hrktb wrote: post #166
vbsteven wrote: post #154

Earlier quoted context omitted.

Use Terraform for bringing up the Kubernetes cluster and other related cloud resources (storage, load balancers, DNS, etc). Once you have a cluster up and running you can just use kubernetes yml to manage the cluster. It is possible to also use Terraform to manipulate kubernetes resources (or AWS ECS or another container platform) but I personally like a clear separation between infrastructure (bringing up the enviro…

So TF would come where you would otherwise use gcloud commands, if I get it. One part of the cluster building that caught me off-guard with GCP is that cluster options effectively change over time, as the k8s versions march forward. For instance some feature go out of beta and become the default, and trying to rebuild a cluster exactly similar to one built year ago would require specific “don’t use that new feature”…

Indeed, I see TF mostly as an automation/idempotency tool for setting up and maintaining infrastructure components like Kubernetes clusters, ECS clusters, load balancers and all that. Something you would normally do with gcloud or aws-cli or by clicking around in GCP/AWS web console.

Yes, the "provider churn" is real: defaults on cloud platforms can change and platform-specific TF providers can change as well. The way I usually deal with that is to make sure my TF repo's stays in shape by applying them regularly. If you haven't applied a TF repo in over a year chances are real that your repo has rotted. In a similar way to an old Ansible playbook that has rotted because some apt packages have new dependencies. Keep applying them regularly and manage changes in small chunks instead of once a year.

Auditing is really useful. I would recommend preventing developers from applying TF to production directly, and have it all managed by a CI pipeline.

Also with some careful planning and structuring of your TF repository. It's pretty straightforward to duplicate environments: for example: spin up an extra development environment to experiment with a newer K8s version, or to validate some infrastructure changes.

Re: Terraform 0.15 General Availability

#172

Post by te_chris »

kstrauser wrote: post #82
moufestaphio wrote: post #42

Earlier quoted context omitted.

> we cannot manually fix some minor mistakes of ours when creating resources because that'll mess up terraform In my opinion if you're doing manual fixes you're doing it wrong. Let's say you do your manual fix in your Dev environment. Do you remember to do it in Prod/whatever other environments you have? Are you sure you did the EXACT same thing? Did you change 5 other things trying to fix it first? You end up with s…

I think there's a middle ground if you're not sure how to fix a mistake in Terraform but you know how to do it in the console: * Make your changes by hand * Right afterward, run "terraform plan" to see how Terraform would undo your changes * Edit your Terraform config to reflect those changes, and run "terraform plan" again to make sure you caught everything. Repeat until it's a no-op. Now you've got a log of what yo…

You can also fetch cloud resource state with terraform, without running plan - I can’t remember the exact command. You can use this to import new resources into tf

Re: Terraform 0.15 General Availability

#173

Post by takeda »

HatchedLake721 wrote: post #167
goatinaboat wrote: post #145

Blows my mind how many people are basing business critical infrastructures on 0.something of anything

Terraform (and hashicorp) don’t follow semver. Terraform has been spinning up infrastructure for small and $100billion+ companies for years, it came out in 2014. Business critical readiness is not measured whether something has or hasn’t got a “1.0” tag on GitHub.

and in 2021 finally is able to remove the environment that was actually deployed and not the one located in your current directory.

I wouldn't call TF garbage, because real garbage is the native provisioning tool gcp has. It is just waay over-hyped tool.

Reading comments here it is clear that the biggest proponents at most maybe used CF once or not at all.

TF was great when it was released, it was superior to CF back then. HCL was much better then using JSON, but things improved dramatically. No need to worry about storing state, imports/exports where you can share values between stacks. CustomResources (where you can create a lambda function that does anything you need to), I used for example to configure AWS integration with DataDog, where it needs to create resource in AWS then make setup on DD side that create more resources. Combine that with managed stacksets and BOOM, now every account in the organization automatically sets up the integration. Imagine doing something like that with TF.

Re: Terraform 0.15 General Availability

#175

Post by sofixa »

cies wrote: post #158
bogomipz wrote: post #121

Earlier quoted context omitted.

>"On a related note, CDK for Terraform allows DevOps practitioners to use a variety of programming languages instead of HCL." Out of curiosity what is it that people generally don't like about HCL?

Yet one more thing to learn. No types (hints in IDEs).

v2 has types, and my IDE ( VS Code ) does hints

Re: Terraform 0.15 General Availability

#176

Post by jen20 »

sofixa wrote: post #175
cies wrote: post #158

Earlier quoted context omitted.

Yet one more thing to learn. No types (hints in IDEs).

v2 has types, and my IDE ( VS Code ) does hints

The IntelliJ HCL plugin has full refactoring support, auto completion etc. It’s a shame it’s not open source, since there must be a Kotlin implementation of an HCL2 parser underpinning it.

Re: Terraform 0.15 General Availability

#177

Post by mr_C »

apple4ever wrote: post #142
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…

How do you ensure you have say 2 web servers created and connected to a load balancer? Is that part of your custom module?

Using ec2_instance_info to check if the instance exists filtering by name (eg: selectattr('tags.Name', 'defined') | selectattr('tags.Name', 'equalto', server_name) ) and then standard ec2_instance module, same for lb.

Re: Terraform 0.15 General Availability

#178

Post by ksec »

sali0 wrote: post #153

So much hate ITT for such a great tool. Terraform is definitely not perfect but it's still one of my favorite tools, solely because of the amount of efficiency gained from learning it. Yes HCL is not perfect, but it is definitely adequate for a lot of applications. IMO, Hashicorp makes some of the most well thought out tools and I am grateful of their attitude towards open source.

ITT = In This Thread. ( I had to look it up )

Re: Terraform 0.15 General Availability

#179

Post by zaphirplane »

satya71 wrote: post #84
theopsguy wrote: post #62

Earlier quoted context omitted.

If you like CDK, then i highly recommend pulumi

Can second that. Pulumi with Typescript is just absolutely awesome.

I don’t get why people like scripting it, declarative is fantastically simple. I don’t want to trace through loops, if statements, functions It does from these files declare my infra to these scripts when parser thru define my infer

I get Logic in yaml/json is less ergonomic but templing makes us for it

Re: Terraform 0.15 General Availability

#180

Post by jen20 »

cies wrote: post #159

I think TF is used a lot in production for a pre-1.0 "we can break what ever we want". But then I also use it, happily :)

Terraform (core) doesn’t follow semantic versioning, so pre-1.0 does not mean that. Ever since 0.4, the number of production users made working on it rather like changing the wheels on a bus while driving down the highway full of passengers!
Post reply on HN