
Terraform 0.9 - based2
https://www.hashicorp.com/blog/terraform-0-9/
======
dkarapetyan
I was initially a huge fan but now I hate it. It re-invents so many
unnecessary wheels that it is downright obnoxious. There are no loops, if
statements, variables. Things that have been in programming languages since
day 1. It re-invents modules, badly. Has weird hacks like null resources and
external data providers to get around shortcomings in their "declarative"
model. And a few other things I'm forgetting. Oh, now they're adding
"environments". That's just dandy because they got everything else so right.

Every place I've seen Terraform used invariably runs into these shortcomings
and the workarounds range from using Erb and Jinja templates to generate
Terraform templates to just ditching it entirely and using home-grown
solutions. Terraform should have been a library in an actual programming
language instead of a gimped external DSL that re-invents the wheel.

~~~
harlowja
It also seems pretty much the same as ansible (which suffers the same problems
as you mentioned).

I pretty much agree with you, they should of provided 2 entrypoints IMHO, they
can make there DSL and all that and make it (eventually) turing complete and
at the same time they should just provide composeable objects in <some>
language as well.

I've never quite figured out who the target audience is for these kind of
DSL(s), is it people that can't program, or people that can't program well/at
all (without adult supervision)?

~~~
hubert123
Apparently these people think it makes it "simpler". Well I'm sorry but me
looking up how to format things with yaml and no autoformat and no
intellisense just isnt good and doesnt make things simple. Even xml with a
backing xsd would be better than that, but that's apparently not cool enough
anymore.

~~~
dkarapetyan
I forgot about the lack of auto-complete and the horrible error messages. At
least with a library when I have a syntax error or something blows up I have a
debugger and the actual language at my disposal to figure stuff out. No such
things are remotely available with all these external DSLs. If even there is
any semblance of error reporting.

Several human centuries of effort have been spent on improving these things
(syntax highlighting, auto-complete, stack traces, error messages, interactive
debuggers, etc.) and then all these DSL authors decide to just chuck it all
out. Boggles the mind.

More than a few times Terraform has wrapped an error message from AWS in the
hopes of being helpful while hiding all the details of the actual error
message and no hints how to rectify things in the DSL.

~~~
apatap
Syntax highlighting and auto complete is available for HCL (The language used
by Terraform)

e.g.

[https://plugins.jetbrains.com/plugin/7808-hcl-language-
suppo...](https://plugins.jetbrains.com/plugin/7808-hcl-language-support)

[https://github.com/wholroyd/vscode-hcl](https://github.com/wholroyd/vscode-
hcl)

~~~
bmurphy1976
Which is great and all but like the op said our files are actually jinja2
templates because HCL just doesn't cut it.

------
nodesocket
Huge Terraform fan. The first time it creates VM's, disks, IPs, firewall rules
it is like magic. Infrastructure definition should be code, it just makes
sense.

If your looking to dive in, I wrote a short introduction blog post on getting
started with Google Compute Engine.

[https://blog.elasticbyte.net/getting-started-with-
terraform-...](https://blog.elasticbyte.net/getting-started-with-terraform-
and-google-compute-engine/)

------
oskarpearson
This is great, and solves two ongoing problems we have with TF:

\- The new 'State environment' feature should resolve the issues discussed
here: [https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-
wan...](https://charity.wtf/2016/03/30/terraform-vpc-and-why-you-want-a-
tfstate-file-per-env/)

\- The new locking feature means we don't need to use
[https://github.com/gruntwork-io/terragrunt](https://github.com/gruntwork-
io/terragrunt)

------
blaisio
I love terraform! It is one of the few tools I've found that was easy to
understand and easy to integrate with legacy stuff, and it very quickly saved
me a huge amount of time.

It only took me about 30 minutes to setup a terraform file that could bring up
and teardown an entire web stack with a single command. I was so shocked by
how straightforward it was that I brought the stack up and down a few times
just to make sure it was actually repeatable.

------
codecurve
We had a tough time with Terraform on AWS. The syntax is undeniably better
than Cloudformation and having the concept of modularity built in is a big
win.

However, when things went wrong we ended up with cryptic error messages and
often when `terraform up` failed, then `terraform destroy` would fail too,
leaving us using AWS console to jump in and start clearing up the resources.
Particularly painful because AWS has no awareness that your stack came from a
Terraform config, so you have to navigate through the subresource menus
destroying things one-by-one.

We ended up switching over to Cloudformation. The extra verbosity does suck,
but the tooling for running/updating stacks feels far safer. We can review the
changeset when we update the stack, view a realtime event log as resources are
created, deleted or updated, and best of all we can always tear the stack down
from a single point.

------
cultavix
Amazing platform. We've recently taken about 6 months to define our entire
infrastructure in Terraform. We've been using it since version 0.6 and with
version 0.9, the biggest feature to come for us is definitely the remote back-
end and the remote locking mechanism (which we use Terragrunt for atm). The
remote back-ends mean that the state will not longer be stored on the local
machine which is obviously a big plus for security as the state actually
contains all of your infrastructure information and even secrets. Anyway, huge
project and huge potential, so much so, I've made it the headline in my CV!
Thank you Hashicorp, keep it coming!

It's allowed us to do the following for our developers:

Full integration with the CI/CD process.

Open a branch, commit it to GitHub, add a special label and you will get a
completely new setup, just to test your branch. New application name in the
service discovery tool (Consul/Eureka), new RDS instances, new network, etc,
etc. Once happy, the developers can merge into dev and the branched version of
the infrastructure is destroyed.

------
jdoss
I cannot recommend Terraform enough for teams that are looking to gut their
old infrastructure deployment methods. We used Terraform ~0.7 to build out our
EU VPC on AWS. After a bit of pain understanding how to build modules we were
finally able to say we have our infrastructure truly in code. We were even
able to reproduce our exact infrastructure deployment, with a bit of tweaking,
for partner that had strict data privacy requirements. Terraform allowed us to
provision a smaller scale deployment of our production deployment on their AWS
account in about a days worth of work. We plan on redoing our US deployment
Terraform and we we are going to POC their Pro/Enterprise version very soon

If you want a great starting point for learning how to do things the right way
[https://github.com/hashicorp/best-
practices/tree/master/terr...](https://github.com/hashicorp/best-
practices/tree/master/terraform) helped us out a lot.

------
slap_shot
Can anyone compare Fugue[0] with Terraform/Terraform Enterprise.

I'm launching a venture that requires deploying and maintaining cloud
infrastructure across the three major cloud providers (AWS, GCP, Azure) and am
considering options. Most of our infrastructure is kubernetes but Fugue caught
my eye for their AWS deployments. Curious if anyone has used both.

[0] [https://fugue.co/](https://fugue.co/)

------
golovast
At lot of the debate here centers on DSLs vs programming languages and I don't
want to get into the weeds of that. I did use terraform extensively at a few
places and generally if you want to do something simple it does a fine job.
When things start getting complex and the team & infrastructure is
larger...well, let's just say some warts start coming up. You more or less end
up with some type of a wrapper around it.

But in another place we decided to use troposphere[0] and I liked it more (at
least for AWS-only shops). A lot more flexibility and you're relying on
Cloudformation to do some of the heavy lifting around states. We basically
ended up with a tool based on that library which would generate deployable CF
stacks (and some other things).

[0]
[https://github.com/cloudtools/troposphere](https://github.com/cloudtools/troposphere)

------
akurilin
How do folks feel about Terraform vs Cloudformation for AWS-only deployments
these days? Do we have a clear winner? I remember even a year back there were
certain features of AWS that were being made available through Terraform first
before you could configured them in CF, so the choice was somewhat non-
obvious.

~~~
truetuna
Terraform is great but there are certain things that I still use
Cloudformation for (simply because you can't do it right now using Terraform).
One example is rolling updates on your ASGs. Last time I checked you can't do
it via the aws_autoscaling_group resource.

~~~
webo
For this we have been creating the CloudFormation in Terraform itself. CF is a
giant mess to work with.

~~~
devonkim
A lot of people including myself have used tools to generate CF or Heat
templates in the absence of a need for cross-cloud compatibility that
Terraform offers. You can use Troposphere, Stacker, or anything else that can
intelligently generate and manage component information as a JSON or Yaml file
and get much of the power of Terraform - perhaps more given the option of a
full language rather than an external, declarative DSL. I still haven't found
an idiomatic, elegant API that can manage all those template references.

The primary advantage Cloudformation has for myself is a lack of need to
manage the state that Terraform spends so much effort upon. In fact,
Cloudformation does this fairly opaquely but was much more obvious when I
tried to deploy a CF stack when S3 was down a while ago - being able to use an
alternate state file location would have been handy then.

~~~
akurilin
In fact our very own jdreaver wrote a Haskell EDSL for generating
CloudFormation templates, this seems to be not uncommon among companies who
want to do infrastructure as code with that ecosystem:
[https://github.com/frontrowed/stratosphere](https://github.com/frontrowed/stratosphere)

------
erikrothoff
This is so cool. I literally found Terraform yesterday and I guess I found 0.9
just before the announcement. I spent the entire evening reading and trying to
get it running with Linode.

I've got to say, I always end up falling in love with products with cool
names, nice logos, great design and easy interfaces. Terraform and most of the
Hashicorps products I've seen tick all of those boxes. I'm amazed at the
quality of the tools.

However a question:

The documentation makes it really clear that Terraform is not a configuration
management tool. Do I understand this correctly that it means you need another
tool like Chef to run all base setup code, like install firewalls, set
timezone, install other packages? I've been using Ansible to install a
baseline of packages for my servers.

~~~
mylons
yes you need a configuration management tool to go with terraform. terraform
is for infrastructure.

------
davidgerard
We're getting into using this on AWS. Plus points: it's awesomely powerful and
actually useful. Minus point: the version number is not a lie, this is buggy
betaware that deprecates functionality fast without looking back, and if you
use it for real work at this stage you are _live beta testing_ both the
software and its functionality and will tear out your remaining hair. Even
given that, we're sticking with it.

------
webo
Great stuff.

We have been doing "state environments" using different var files and
different state files for a while now, while keeping the same terraform files.

------
arjie
What's the general pattern for making sharded applications where each machine
needs to be distinguishable on that count?

For instance, say you're sharding across three machines. And now you want to
up that to four. Each instance of the application is smart enough to do it
provided it knows which shard it's in.

We deploy fully baked AMIs containing an application. Do you make separate
AMIs per shard? Or do you supply configuration afterwards? Or do you template
and generate your plan file each time?

I haven't found anything on this so I'm hoping someone can tell me.

~~~
skMed
I would prefer the image to look identical. Each host is going to have a
unique name, and you're going to outsource your routing/discovery to the
Client/another service anyway right?

Generally though, if there is some custom config data that must be passed on
_BOOTSTRAPPING_ the node, you can use templated values for user-data on cloud-
init based systems, or the remote_exec provisioner. This can even include the
modified shard name (with count). If you're talking about updates _AFTER_ the
machine has been in service, I do not believe this is 'officially' supported
by Terraform but it can be done [0]. You may want to look into a proper CM
tool w/ idempotency for that sort of thing (Chef, Salt, etc.)

0: [http://stackoverflow.com/questions/37865979/terraform-how-
to...](http://stackoverflow.com/questions/37865979/terraform-how-to-run-the-
provisioner-on-existing-resources)

~~~
arjie
Oh, no, definitely the former approach. All right. That sounds perfectly all
right to me. I was wondering if there was a different way people did things.

------
Kiro
I'm running a small game on Heroku (Node.js + WebSocket) but I want to migrate
it to my own DO/Linode server. However, I know nothing about servers and I'm
terrified I will make all kind of security errors. Is this something I should
use to mitigate it?

OT but what I really want is a service where I just click a button and they
configure the server for me with automated security updates.

~~~
OJFord
> _I know nothing about servers and I 'm terrified I will make all kind of
> security errors. Is this something I should use to mitigate it?_

Not really.

What Terraform does is to allow you to put all your configuration in
(versioned) code. So you can have all your existing configuration, and then
change the relevant definitions to Digital Ocean or Linode and make the commit
'Move to DO/Linode'.

Exactly how its configured - security or otherwise - is still up to you
though.

> _OT but what I really want is a service where I just click a button and they
> configure the server for me with automated security updates._

Why are you moving from Heroku to Digital Ocean then? Heroku is much closer
to, if not exactly that.

~~~
Kiro
> Why are you moving from Heroku to Digital Ocean then? Heroku is much closer
> to, if not exactly that.

It basically comes down to the daily cycling which I have no control over and
the low memory on the hobby dynos. My game is constantly reaching the limit
and without rebuilding the whole architecture it leaves me with either
upgrading to a much more expensive dyno or migrating away.

I also miss just being able to ssh into my machine and do stuff.

------
mrmondo
Well done guys/gals, any product that helps abstract or attempts to prevent
vendor lock-in has my vote. Great work as always HC.

------
AtheistOfFail
Someone just brought this up to me, but I don't see the use if you're already
using Flynn to deploy Rails apps.

Anyone actually know where this product would fall in the development
pipeline? It sounds amazing.

Edit: Okay, got it, it's a configuration management application which only
applies if you're manually handling your AWS containers.

~~~
sethvargo
Hi there,

Terraform is a tool that captures Infrastructure as Code. Flynn appears to be
a PaaS, akin to something like Heroku with scheduling capabilities on top.
Under the hood, there is some sort of infrastructure that Flynn is deploying
to; it's providing an API on top of it to easily manage deployments and
scaling. Terraform is the tool that defines the layout and composition of
underlying infrastructure resources.

Another one of Terraform's strengths is that it supports multiple providers.
Most of this thread mentions AWS, but Terraform also supports GCP, Azure, and
DigitalOcean. But Terraform can manage anything with an API, so you can codify
things like GitHub teams and permissions, DNS configuration, PagerDuty
escalation policies, and so much more
([https://www.terraform.io/docs/providers/index.html](https://www.terraform.io/docs/providers/index.html)).

All of these definitions are captured in code. You can bring that code under
management of source control to get peer review, pull requests, or permission
models (signoffs) too.

If you are an individual developer happy with Heroku or Flynn, Terraform
probably isn't the best choice for you, especially if you do not have a
background in operations or you do not want to manage servers. However, most
medium->large scale production applications cannot be supported by such
technologies and demand a tool like Terraform to manage the complexity.

I hope that clears up the differences a bit.

Disclaimer: I work for HashiCorp, the company that makes Terraform.

~~~
hubert123
So why isn't it also a replacement for ansible? I dont understand this
artificially limited scope. You set machines up, why not also set up their
software and repos?

~~~
HeyImAlex
I don't know a lot about terraform, but it sounds like they are very different
things? Terraform talks mostly to cloud provider apis, ansible usually deals
with running code on the servers themselves.

------
zwischenzug
Wrote this recently:

[https://medium.com/@zwischenzugs/dynamic-terraform-
environme...](https://medium.com/@zwischenzugs/dynamic-terraform-environments-
eabaf01f85df#.2b9djqu48)

is there a 'proper' way to create dynamic environments?

------
skMed
Great changes! State environments is the feature that stands out the most for
me. Currently, this is done by managing different sets of TF VARs. That's not
going away, but this should allow for more nuanced modules.

------
ex3ndr
I hope they will fix their VMWare + Docker compatibility. I love terraform,
but right now i need to delete manually my VMs to avoid terraform apply crash
on trying to capture IP addresses from VSphere.

------
Vinnl
For anyone else annoyed that there's no RSS feed:
[http://feed43.com/0475703031862353.xml](http://feed43.com/0475703031862353.xml)

------
plainOldText
I'm not yet ready to jump into docker and the likes, and I've used terraform
for setting up the infrastructure for a 3-tiered project and I was extremely
pleased with this tool.

------
tvaughan
[https://gitlab.com/tvaughan/terraform-aws-
starterkit](https://gitlab.com/tvaughan/terraform-aws-starterkit)

------
whatnotests
[Serious] if I'm already happy using CloudFormation for AWS, and I don't plan
on supporting AWS + another cloud, is Terraform for me? Or is it for other
use-cases?

~~~
mitchellh
Hey there, I'm one of the creators of Terraform. Honestly, if you're happy
using CloudFormation and you're sticking with AWS, just stick with
CloudFormation. Terraform will be around when/if circumstances change and
it'll be better than ever by that time. No rush if things are working for you.

The best time to look into something like Terraform is if you begin managing
more than just AWS resources. Even so, you can choose to use CF for AWS and TF
for non-AWS. Or, if you want to start taking advantage of the higher-level
features Terraform is beginning to support.

At the end of the day though, I'm a big fan of working with what you're most
expert with until circumstances require otherwise.

~~~
whatnotests
Hey thanks for the swift response -- you have plenty other stuff to get to,
I'm sure.

