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

41–50 of 167 posts

Re: Terraform 0.12

#41

Post by 0xEFF »

nineteen999 wrote: post #38
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…

Where do you store your state files? The only project I've worked on that used Terraform stored state in a git repo, which seemed like a nightmare with multiple people doing deploys to the same environment. Others have suggested it would be better stored on a network accessible share.

Store them in a bucket as soon as possible.

Re: Terraform 0.12

#42

Post by bbatha »

nineteen999 wrote: post #38
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…

Where do you store your state files? The only project I've worked on that used Terraform stored state in a git repo, which seemed like a nightmare with multiple people doing deploys to the same environment. Others have suggested it would be better stored on a network accessible share.

Usually your favorite S3 like service. Do most of your development in modules then have “roots” that cover a well defined subsets of your infrastructure (say db, app servers, load balancer and firewall rules for a single app) then use workspaces to manage different environments. The docs for terraform are actually quiet.

Re: Terraform 0.12

#43

Post by haney »

nineteen999 wrote: post #38
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…

Where do you store your state files? The only project I've worked on that used Terraform stored state in a git repo, which seemed like a nightmare with multiple people doing deploys to the same environment. Others have suggested it would be better stored on a network accessible share.

I use a versioned S3 bucket to store state in my project, terraform also supports "locks" to avoid race conditions/parallel execution. I've set up buildkite to run `terraform plan` and then if the output looks I can approve the next step to run `terraform apply`.

Atlantis (https://github.com/runatlantis/atlantis) is also a really cool project for managing teams working on terraform projects.

Re: Terraform 0.12

#44

Post by n42 »

techntoke wrote: post #19

I moved away from Terraform a long time ago. Ansible was way more powerful, handled errors and issues with state changes. Terraform was super picky about how you had to operate, slow and HCL was a terrible markup language. I wasn't really a huge fan of Ansible either though and more recently have been doing things in regular shell/Bash scripts. Now with Kubernetes and service brokers, there is no need for Terraform.

Ansible can very easily, and often does, end up in situations where two runs of the same playbook both have drastically different results. roles/playbooks slowly become Bash scripts written in a YAML layer parsed as a Jinja2 template.. and the project turns into a mess of many layers of indirection.

it attempts to and encourages declarative configuration, but is very hard to keep that way. it is difficult and requires determination to make Terraform do something in a non-declarative fashion.

the end result is that when I look at a Terraform configuration I can very easily tell what is going on, because the end result is exactly what I read. where with Ansible, it very much depends on understanding the current state of the server you are about to run this playbook on, and you just have to cross your fingers and hope for the best.

Re: Terraform 0.12

#45

Post by joseph »

techntoke wrote: post #21
_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.

Agreed about CF. AWS puts a huge emphasis on CloudFormation when they know it is sub-par. Ansible is pretty cool too because you can easily convert between YAML/JSON for CF, and add a lot of flexibility based on variables and other things such as error handling that you can't do with Terraform.

I don't agree it is subpar. I have a fairly long list of reasons for preferring CF over Terraform. I agree on combining CF with Ansible though. My recipe is to wrap a CF template in an Ansible role. It makes for a versioned chunk of automation that composes well with my other roles, including ones that are not CF based. Plus I can do non-CF setup tasks using any Ansible module, and even run tests, to get pretty much full end-to-end automation for a given stack. I haven't found a way to get the same degree of power and flexibility from Terraform without resorting to writing custom plugins.

Re: Terraform 0.12

#46

Post by org3432 »

oneplane wrote: post #36
argd678 wrote: post #8

Earlier quoted context omitted.

Agreed, the data model of Terraform simply doesn’t match the problem domain. You need an algorithm to codify the pattern and then data to fill in the params. Terraform doesn’t allow you to create the patterns you need in a way that’s debugable and doesn’t allow for code reuse. For simple setups it’s not apparent there’s a problem but when they get more complex it’s nearly impossible to use. Additionally you have to r…

The Terraform language extension in VSCode is very good.

It's not good, it doesn't understand the TF types and recommends values that are invalid for the context, there's no inline help (you have to go look it up on the website), refactoring a variable name doesn't fully work, and you can't set breakpoints or trace through the execution to determine what's going on... I mean it's practically in the mid-80s, although most of those things worked even back then.

The lesson here is that if you plan on making a language, even a DSL, you want to be sure you're really up for it since it's a lot of work.

Re: Terraform 0.12

#47

Post by SlowRobotAhead »

s09dfhks wrote: post #6
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?

there's no exporting. You write everything in there format to define your infrastructure, and then terraform turns it into AWS API calls

That makes sense.

Now, other than the portability of AWS to Azure to GCP, why do I want this?

Because with CloudFormation I can pull down and put up my “stacks” in layers and this isn’t necessarily the same as API calls (although on the backend maybe it is).

Re: Terraform 0.12

#48

Post by joseph »

n42 wrote: post #44
techntoke wrote: post #19

I moved away from Terraform a long time ago. Ansible was way more powerful, handled errors and issues with state changes. Terraform was super picky about how you had to operate, slow and HCL was a terrible markup language. I wasn't really a huge fan of Ansible either though and more recently have been doing things in regular shell/Bash scripts. Now with Kubernetes and service brokers, there is no need for Terraform.

Ansible can very easily, and often does, end up in situations where two runs of the same playbook both have drastically different results. roles/playbooks slowly become Bash scripts written in a YAML layer parsed as a Jinja2 template.. and the project turns into a mess of many layers of indirection. it attempts to and encourages declarative configuration, but is very hard to keep that way. it is difficult and require…

I have many Ansible roles that I trust to do the right thing over and over again. Though, I never use bash for scripting, and when I do shell out in Ansible I keep it extremely simple and always use a `when` or `creates` condition to keep it idempotent.

Re: Terraform 0.12

#49

Post by maxaf »

_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.

Viewing Terraform solely through the lens of cloud automation and in comparison with CloudFormation is a shortsighted mistake. Terraform has providers for plenty of other services that don't qualify as "cloud things" and lack proper configuration of their own. In a very general sense, Terraform is a terrific resource management tool with state versioning & locking built in. For example, there's a terraform-kafka-provider[1], which can be used to manage topics in a Kafka cluster. Could shell scripts be written to accomplish the same goal? Of course. Would those scripts inevitably develop in a haphazard, organic way to form a buggy and incomplete implementation of something like Terraform? You bet!

"Cloud" configuration may have been Terraform's proverbial toe in water, but the truly untapped potential lies in the other providers. Anything that can be packaged as a Terraform provider exposing resource abstractions can be easily managed using convenient HCL syntax. This, IMHO, is the unfortunately buried lede.

[1]: https://github.com/Mongey/terraform-provider-kafka

Re: Terraform 0.12

#50

Post by happythought »

kitotik wrote: post #25
merlincorey wrote: post #13

Earlier quoted context omitted.

That's not at all how it works. Terraform supports each of those providers, but the resources are specific to each provider. You cannot use the same Terraform configuration on AWS and Azure. Nor would you want to, per se. As far as I know, this is by design.

You can’t share provider-specific resources across providers of course, but you can absolutely share other configuration data across providers. I find it extremely useful - for example it’s fairly trivial to bounce between scaleway, AWS, DO, Vultr, etc.

You can also use the same basic cicd pipeline to manage infrastructure on different providers instead of a custom pipeline for each provider tailored to their tool.
Post reply on HN