Hacker News Reader

Comment by kristopolous | Hacker News Reader

Can someone explain concretely and specifically what this thing does?

It's a Hashicorp Terraform fork.

Hashicorp started playing license games. So a bunch of the people and orgs that depend on Terraform took out insurance against future license changes by forking and instituting an open license version that no one can close (or, for that matter, ensure no one pulls a Unity).

"HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share." [1]

[1] https://developer.hashicorp.com/terraform/intro

Maybe I'm missing something but I feel like I've heard pitches for many similar products, is this just the industry leader or is it genuinely a unique player?

It's pretty much an industry leader, it was one of the earliest ones on the scene. And many people write terraform providers for different kinds of targets. So whether good or bad, it has a lot of mind share and lots of lines of code written for it.

Alternatives do exist now and they're all good in their own ways.

Terraform is very popular, far more then older systems of this style. Im not sure if the feature set is totally unique.

When deploying infrastructure at scale, nobody clicks around in vSphere or AWS.

They create parameterized "infrastructure as code" definitions that can repeatably create resources.

Terraform is by far the most popular tool for this.

It's a configuration file parser and task dependency engine that tries to guarantee idempotent updates by keeping a record of the current state of your deployment and only running update tasks if your configuration doesn't match the deployed state. The dependency engine also does some topological sorting to automatically run tasks in dependency order, in parallel where possible, without you having to imperatively specify any kind of ordering.

The configuration files themselves are intended to be written in HCL or the Hashicorp Configuration Language, which was created for Terraform and offers some built-in functions and types, but it will also accept json, which is intended more for when you programmatically generate your configuration. They recently began supporting writing your configuration as Python or TypeScript as well, addressing complaints that HCL is close enough to a real programming language that you often wish you had a real programming language.

The state is tracked either in a local file or a remote file, and the file is json. If remote, you can add authorization and locking depending on the remote storage provider.

The meat of the work is not really done by Terraform itself, but by providers, which are plugins either written by Hashicorp, by infrastructure vendors, or by the user community. The configuration files define resources that consist of variables that end up getting passed to these plugins that then construct API calls to request the real infrastructure providers do the provisioning. You also get "data" resources that just query the infrastructure provider rather than asking it to provision anything.

As for why you want Infrastructure as Code, effectively the same reason you want anything as code. Why write software when you can get a computer to do just about anything with shell commands? Because you can reuse, share, make far better reliability and consistency guarantees, and the code itself provides somewhat of an audit trail or record that should reflect the behavior of your resources. As long as your administrators actually use it, you have a clear, readable record of how everything you own was deployed. It can be put to code review before changing anything. You can use your regular peer review/pull request process to implement separation of duties.

Terraform is somewhat of an industry leader. Hashicorp is the company that started out with Vagrant and also makes Packer, Vault, Consul, Nomad, and some other things, but all of their products are pretty widely used and have a lot of developer mindshare. They're not the only game in town, but as far as Infrastructure as Code tools that aren't locked to a single cloud provider, there's really only Terraform and Pulumi that I'm aware of and have seen actually used in the wild.

This is a fork of Terraform after Hashicorp changed the license

Thanks. That's easily discoverable. Can you explain concretely and specifically what terraform does.

"infrastructure as code tool that enables you to safely and predictably provision and manage infrastructure in any cloud"

Doesn't tell me anything. Is this a markup language for describing networks? Is it some web interface where you drag and drop server icons and then draw lines between them? Is it a simulation tool? Is it some provisioning thing like chef with a database for different machines?

Terraform is a tool and module ecosystem for provisioning cloud resources from a declarative language, called Hashicorp Language (HCL). The idea is to specify your cloud resources in a file, commit that to git, and then run the tool on sets of these resources. The underlying engine will look at what you want this time, compare that to what is in the cloud, and make the appropriate changes, doing some nice graph walking to handle dependencies and work in parallel when it can.

For those interested, there is a small package that is the core of the specialized graph data structure that powers this: https://github.com/opentofu/opentofu/blob/main/internal/dag/... (link to the most interesting comment block in the package)

Amazingly well done. Super clear. Thanks

Infrastructure as code. You define your infra in a couple of files, then terraform builds it against eg: aws.

Through what? The aws cli tool?

Why would I need to encode something like that? Are you talking about maybe having identical setups in different parts of the world?

You would encode it for the same reason we use source control - confidence that what is deployed matches some kind of record of it.

In development we don't send archives of code to each other (OK, some people do I guess) and in infrastructure we don't click around in AWS to make changes

I'm still not convinced on this use case.

The click around technique could have logs and audit trails just the same. Someone could also just type up what they did.

If you're doing 100 of something I'm sold but the record argument I find unconvincing. A preference sure, but a simplifier, no.

Have you ever worked in a regulated environment? One where you can't just SSH into production and change things? Logs and audit trails provide attribution, not prevention. How do you prevent unwanted changes to production? How do you block changes to production with quality gates? How do you ensure that modules conform to specific specifications before they are launched? How do you do an equivalent to code review? What happens when AWS rolls out a new feature like blocking public access and you have to roll it out to all of your buckets immediately? All of this is much, much more tedious in an interactive system.

Some great points from a sibling comment, and the one I'd add is:

You don't need 100 instances of something to make managing it programmatically worthwhile. Different environments, for example: Terraform makes it very easy to ensure _all_ of the cloud config in prod matches staging (or the inverse), and to set up and bring down ephemeral development environments, using parameterised Terraform modules so you can be confident changes will propagate appropriately.

Reply on news.ycombinator.com