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

51–60 of 239 posts

Re: Terraform 0.15 General Availability

#51

Post by diroussel »

mr_C wrote: post #45
solatic wrote: post #31

Earlier quoted context omitted.

Because the state exists regardless. When you write code that interfaces with AWS, there's always something that exists on the other side of the AWS API. The question you have is, how do you programmatically keep a copy of that state on your side of the API? The naive approach that tries to do this without state in code goes something like: a) invoke the remote API to look for something that should exist b) if it doe…

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…

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. Whereas terraform is much more declarative.

Re: Terraform 0.15 General Availability

#52

Post by pizza234 »

Thaxll wrote: post #35
0xbadcafebee wrote: post #21

Earlier quoted context omitted.

Our teams have something like 100,000 LOC in Terraform 0.12, and it's not all in one big monorepo. At that scale there is no such thing as a relatively minor version upgrade. We want to upgrade to get away from some persistent 0.12 bugs, but we literally don't have the time. We have to change all of the code, and then test every single project that uses that code in non-prod, and pray that the testing finds most of t…

There is no solution where 100k loc is not going to be challenging to keep over time.

While it's not possible to make an apple-to-apple comparison (Terraform-to-?), if we compare to something based on an imperative language, say Puppet or Chef, there is a huge difference.

In my opinion, Terraform's big issue is that it was born as a declarative tool for managing infrastructure. Large configurations (IMO) necessarily ossify, because you don't have an imperative language that makes small progressive changes toleratable - it's a giant interrelated lump.

What's worse, when it grows, one needs to split it in different configurations, and one loses referential safety (resources will needed to be linked dynamically).

A, say, Chef project of equivalent size, can be changed with more ease, even if it's in a way, even less safe, because you have the flexibilty of a programming language (of course, configuration management frameworks like that have of different set of problems).

I'm really puzzled by the design choice of a declarative language. Having experience with configuration management, it's obvious to me that a declarative language is insufficient and destined to implode (and make projects implode). Look at the iterative constructs, for example, or the fact that some entities like modules have taken a long time to be more first class citizens (for example, we're stuck with old-style modules that are hard to migrate).

Re: Terraform 0.15 General Availability

#53

Post by 0xbadcafebee »

toyg wrote: post #10
yjftsjthsd-h wrote: post #8

Earlier quoted context omitted.

I'm a fan of tfenv for this; it's really easy to use and makes it trivial to pin each stack to an exact version of TF.

Between rbenv, tfenv, pyenv, sdkman and so on and so forth, maybe it's time for some sort of common OS-level env-management interface...?

You can whip up something pretty quickly as a shell wrapper and add to it as you need. I just threw this together: https://gist.github.com/peterwwillis/755002d6d3849af5bbc6cb8...

  $ cliv
  
  Usage: /home/vagrant/bin/cliv [OPTS]
         /home/vagrant/bin/cliv [-i] VERSION [CMD [ARGS ..]]
  Opts:
          -l              List versions
          -h              This screen
          -n              Create a new /home/vagrant/.cliv/VERSION
          -i              Clear current environment
  
  $ cliv -n tf012
  $ cliv -n tf013
  $ cliv -l
  tf012
  tf013
  $ cp terraform-v12 ~/.cliv/tf012/bin/terraform
  $ cp terraform-v13 ~/.cliv/tf013/bin/terraform
  $ cliv tf012 terraform
  Terraform v0.12.29
  $ cliv tf013 terraform
  Terraform v0.13.3
  $ cliv -i tf012
  PATH=/home/vagrant/.cliv/tf012/bin:/home/vagrant/bin:/usr/local/sbin:/usr/local/bin:
  /usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
  PWD=/home/vagrant

Re: Terraform 0.15 General Availability

#55

Post by Thaxll »

pizza234 wrote: post #52
Thaxll wrote: post #35

Earlier quoted context omitted.

There is no solution where 100k loc is not going to be challenging to keep over time.

While it's not possible to make an apple-to-apple comparison (Terraform-to-?), if we compare to something based on an imperative language, say Puppet or Chef, there is a huge difference. In my opinion, Terraform's big issue is that it was born as a declarative tool for managing infrastructure. Large configurations (IMO) necessarily ossify, because you don't have an imperative language that makes small progressive cha…

I have really bad memories of the change between puppet 2 and 3 for example.

Re: Terraform 0.15 General Availability

#56

Post by mr_C »

diroussel wrote: post #51
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…

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.

Re: Terraform 0.15 General Availability

#57

Post by erik_seaberg »

dastx wrote: post #19
mohsen0 wrote: post #5

Earlier quoted context omitted.

It becomes much easier between other versions. Though upgrading 0.12 to 0.13 I remember, i had to pull the state and change the provider field manually to avoid recreation of some resources.

> i had to pull the state and change the provider field manually to avoid recreation of some resources. Terraform CLI introduced an upgrade command (can't remember what it's called) that automatically does this for you.

In 0.14 that is no longer available.

Re: Terraform 0.15 General Availability

#58

Post by dang »

0xbadcafebee wrote: post #53
toyg wrote: post #10

Earlier quoted context omitted.

Between rbenv, tfenv, pyenv, sdkman and so on and so forth, maybe it's time for some sort of common OS-level env-management interface...?

You can whip up something pretty quickly as a shell wrapper and add to it as you need. I just threw this together: https://gist.github.com/peterwwillis/755002d6d3849af5bbc6cb8... $ cliv Usage: /home/vagrant/bin/cliv [OPTS] /home/vagrant/bin/cliv [-i] VERSION [CMD [ARGS ..]] Opts: -l List versions -h This screen -n Create a new /home/vagrant/.cliv/VERSION -i Clear current environment $ cliv -n tf012 $ cliv -n tf013 $…

I had to put a newline in your PATH because the unbroken string was borking the page layout. Sorry, it's our bug. Someday someone will show me how to fix it. Some people have come close.

Re: Terraform 0.15 General Availability

#59

Post by wooly_bully »

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

Re: Terraform 0.15 General Availability

#60

Post by dastx »

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

Maybe not node/python, but I'm pretty sure you can use terraform as a package in go. If not, there is always the "make temp dir, write/download files necessary tf files, run terraform apply"

Post reply on HN