I funded the Reading Rainbow Kickstarter. I was shocked and dismayed to learn that no portion of the funding would be used to teach rainbows how to read.
It's the new thing. Pick a noun or verb that's only marginally-related (or sometimes not even remotely related) to your product and take ownership of it.
To be fair, Uber was originally UberCab, but dropped "Cab" from the name after the MTA in San Francisco charged Uber with running an unlicensed taxi service.
At least Uber connotes that it's better than the competition. I was shocked to find out the other day about a CSS framework called Inuit. The mascot is a little inuit guy in a parka. Terraform seems much better in comparison.
McDonald's was at least started by two guys with the surname McDonald. It is/was their company so they named it after themselves. That's no different than "Frank's Burger Stand", which is again completely different than writing a clone of GCC in javascript and then calling it Patriot or something.
It reads like you can use any provisioning software, use any server provider supported, use any DNS provider supported, you just need to write a bunch of configuration.
> The ~ before the Droplet means that Terraform will update the resource in-place, instead of destroying or recreating. Terraform is the first tool to have this feature of the tools which can be considered similar to Terraform
While not multi-platform, AWS's Cloud Formation does just this, it takes as its input a stateless JSON description of a set of AWS resources and their dependencies. Given a change in the desired state, it will do its best to update resources rather than creating them from scratch when possible.
Yes, but CloudFormation doesn't have Terraform's concept of an "execution plan"[1], which tells you what Terraform will do, before it does it. It is very easy with CloudFormation (especially as they get larger and more complex) to run into cases where CloudFormation unexpectedly destroys and recreates a resource, something that would never happen in Terraform because you would see it before it happened in the plan.
That's sounds like a great feature; you are correct, one of the biggest pain points with Cloud Formation is the need to devine which actions will be taken in response to changes.
This is a very nice feature, and I'm going to take a close look at Terraform. If you are already using cloudformation, I'd recommend applying stack policies that deny permission to "Update:Replace" or "Update:Delete" any resources. When you need to, you can use a one-time policy that lets you blow away specific resources, by name or type.
Or to anything that is "kind of a biggie" (not just deletes) in VPC networking:
- AttachInternetGateway / DeleteInternetGateway / DeleteCustomerGateway
- AssociateRouteTable / DeleteRoute / DeleteRouteTable / CreateRoute / DisassociateRouteTable
- ReplaceNetworkAclAssociation
- And all the "Delete"s
Agreed, having to dig through the AWS documentation to see what whether updating a particular value requires replacing the resource it applies to is tedious and error prone.
Another things that excites me about separating the plan from the execution is that I can periodically run `terraform plan` to check for configuration drift without risking making a change. I've been bitten by the following:
1) Someone creates an ASG with the desired number of instances set to 1 via CloudFormation
2) Later, they increase the desired number of instances, e.g. to 5, via the EC2 console or API rather than CloudFormation
3) I come along and apply an update to the stack via CloudFormation. This resets their ASG to 1 instance, terminating the other 4.
If anyone from AWS is reading this, please steal this feature for CloudFormation!
I'm surprised that the CloudFormation team hasn't added a --dry-run option yet. It would make CF sooooo much more usable for a production stack. (I have a policy now to never update a stack once it's taking production traffic.)
This would help, but its not enough. `--dry-run` tells you what it would do at a point-in-time, but isn't a guarantee that by the time you update a stack that that is what would actually happen.
Terraform's execution plans, on the other hand, can be saved and applied. This tells Terraform that it can _only_ apply what is in the plan. It _must not_ do anything else.
To match TF here, CloudFormation would really need "staged changes and applied changes" as separate steps.
If any terraform folks are watching this, I have a little feedback on the home page. When I first got there, it wasn't apparent that I could scroll, and I thought I had to sit through the flashy animation before I could see anything. Was a little bit off-putting.
Also the skew/unskew on the #demo and #feature seems to cause font to render poorly on some browsers/OS combinations. Works fine in Firefox in Ubuntu. Chrome in Windows 7 is the worst with Chrome in Ubuntu being marginally better but still not rendering correctly. IE11 seemed to work fine in Windows 7.
Top image is fixed and bottom image is what I get when I first visit the site.
What is weird is that as soon as I remove the skew on the first feature bar (feature-auto) it clears up everything below it (all of the text within skewed elements looks weird). But if you re-enable the skew it distorts again. Also if remove the skew from the 2nd feature it will fix everything below it but not the stuff above and so on for the 3rd or the #demo.
I have been developing a tool that is almost the same called 'ozone.io'.. It leverages CMT tools such as puppet, ansible, chef. Not by writing plugins, but rather have users write or extend scripts called 'runners' that install and execute the CMT tool per node. You can checkout a prototype chef-solo runner at https://github.com/ozone-io/runner-chef-solo.
Parallel deployment of multiple clusters is also covered. It too is handled by a directed acyclic graph based on dependencies on other clusters. I am on my own and I am writing it for my thesis which will come out pretty soon.
The whole thing works declaratively, so it converges your infrastructure to the desired state. By increasing the nodes for 'smallweb' it will undergo the steps defined in the cluster lifecycle. It will then also update the configuration of the nginx load balancer.
As you can see each cluster is pinned to a provider/instanceprofile, and one of the things I am adding are affinity rules so the cluster deploys to multiple locations/providers.
It is not ready to be opensourced but if any wants to see, contribute or see more I can give view access.
Actually, I've been reading and I might have jumped the gun.. Its programmer panic, sorry.
You are right, it looks like a different type of system.
I actually support all the providers Jclouds provides: Openstack Nova, rackspace, EC2, AWS-ec2.. more.
Whats more ozone does not store any state, rather it stores it in a zookeeper/etcd cluster so you are in control of your meta-data.
I don't have any issues with the colors, but I find the slight blurriness (aliasing?) to be a bit painful to read.That said, I love the design of the site otherwise.
On another note, Terraform appears to be great. I cannot wait to try it out.
I don't see the point of downvotes here... I have several production deployments of NixOS, and can't imagine using any other OS / package manager (supplemental utilities are fine, of course).
I'm just starting off working with nixops. quite nice IMO, although not getting into the meat of it yet (i.e., trying real deployments). Nix solves the dependency problem really nicely, and I can spin up machines from scratch really fast. Also curious about comparisons here. If this is a tight implementation of something like nixops I am stoked.
Mitchell, do you even sleep? Every time I see one of your tools, I feel like I need to pay you a hefty sum to teach me how to start coding productively, cuz Hashicorp output seems ferocious. Keep up the good work.
Well this will seem silly, but my bad. After looking at all your tools, I never looked at the HashiCorp site. I had no idea it was not a one man shop. I saw your last name and the branding on the project pages and I made a judgement a few years back. Should I have check my facts.
Regardless, your software kicks ass. Thanks to you, and your team. Keep on trucking.
I don't think it seems silly... VentureBeat [1] seems to think the same thing:
Mitchell Hashimoto, the guy who created the popular
Vagrant tool for setting up development environments, has
gone and built another useful tool for developers working
on public-cloud platforms.
Everytime HashiCorp releases one of these tools, I can't help but think I should beg you for a job, I mean they're even being created in Go, which is great!
It looks like Terraform is launching with decent coverage of AWS resources. Thinking of my own usage, the main ones missing are ElastiCache and CloudWatch. I'm not sure how you can setup a useful autoscaling group without the latter.
One of the main strengths of something like cloudformation, is that we can use libraries in languages we're comfortable with to build a programmable DSL.
This gives me the full power of python, so I can build abstractions, use inheritance and encapsulation to specialize certain things.
We've done a lot of work to automate our infrastructure provisioning, but I'm interested in the abstraction layer Terraform provides -- especially for multiple providers.
How can we bridge the gap that is left by Terraform from having a fully complete programming language to define infrastructure (which has downsides but in my opinion, more upsides)?
Sweet, thanks Mitchell. I'm always impressed at the level of polish your products have. I'll take this for a spin and I'll report back any results. Is there a mailing list or just #hashicorp on Freenode?
I've tried to use Troposphere, but found it a redundant layer on top of the Python dicts. I ended up building my own Macro language that compiles to raw CloudFormation JSON. What's funny is that I wanted to call this Macro language exactly Terraform. I'll definitely look into Terraform, it looks to have a lot of the features that I implement although most of mine were tailored exactly toward CFN and it may not be practical to switch. Maybe I'll finally convince my employer to open-source it.
Bummer, Terraform is also the engine that powers Harp & the Harp Platform. It doesn't appear this was very well researched before choosing a name. Confusion seem inevitable.
I use HashiCorp tools and I recommend them wherever I go. The reason I do that is because the tools are built with very specific use cases and are grounded in actual practices and backed by solid theory. None of their tools are something that was hacked up over the weekend. Looking forward to Terraform taking over the provisioning/deployment landscape.
Does it really provide most of the features? All I can find in it's documentation is using salt to creating and destroying instances and volumes on various cloud providers. That just scratches the surface of what Terraform does.
Yes, it really does. Saltstack (with Salt Cloud) does cloud orchestration, configuration management, provisioning, works with containers, works with cloud providers
Provisioning and configuration management seem out of scope for Terraform, it calls other tools to perform them. What I was wondering is if Saltstack's infrastructure management capabilities were comparable to Terraform's.
Offtopic but i guess you, hashicorp guys, would like to know; there is a typo on the geometric animation. It says "Build, Combine, and Launch Infrastucture_", should be Infrastructure.
This is pretty awesome. My question is how well does this integrate with and already setup infrastructure? Or would I have to recreate the system to get going with Terraform?
This is a really important question and I'm glad you brought it up.
We're actively working on a way to bring existing infrastructure under Terraform management without having to recreate it from scratch. The process will actually be really easy (but is vaporware at the moment): Terraform only needs the TYPE of a resource and ID of that resource. From there, it can "refresh" the rest of the metadata in.
Our idea is that you'll be able to say "I have an `aws_instance`, it's ID is `i-1234567`, and it satisfies the 'foo' resource" and it'll attach it.
Point being: we're thinking about this, and it is an important aspect of Terraform.
Another point is that you don't need to convert 100% of your infrastructure to Terraform to extract value from it. You can start by putting only specific services under management, and grow from there.
Hi, I think declarative resource management like this is the definitive future (or present as of now).
I was wondering what happens when you increase the amount of nodes of a particular instance? I assume a new machine is started. But what happens if you remove the entire resource altogether, does it terminate the whole cluster? Similarly how does a scaling in a node work? And how would it affect dependencies?
How does this consolidate with elasticity of a particular cluster. I.e. if an amazon load balancing group destroys an instance or takes one up, do I simply refresh and it would detect that this new instance is part of the defined cluster in terraform?
Glad to hear you are thinking on how existing infrastructure could be integrated to Terraform.
I think this is specially important with elastic IPs that have been whitelisted somewhere, e.g. a VPN of a 3rd party service provider. So a way to say, take EIP x.x.x.x, don't ever release it and then indicate what instance to associate it to is great.
Another example of this feature is starting from an existing VPC and build from there, or even actually inherit information from the current state and convert it to an "auto generated plan" to build from. Thanks again Hashicorp for all the great software.
Is there a way to encrypt variables and provide a password to decrypt when executing a plan, so that I can commit my API keys, passwords, etc to source control without fear? I'm thinking something similar to Ansible and its 'vault' concept for variables (sure Chef, Puppet, etc have something similar).
There isn't at the moment, but it is definitely something we need to think through. We didn't want to ship anything broken though (illusion of security), so we deferred this feature until we can think it through more carefully.
I'd suggest looking into OpenPGP and see if one of its apps won't work for you (they implement ssh-agent protocol support, and have a couple other apps for doing on-demand crypto)
Off-topic: it is interesting to me how different companies seem to dominate a space for a few years, and then recede. It's a common pattern. I can remember in 2009 when it seemed like RightScale www.rightscale.com was the dominant force creating tools to take advantage of AWS, but nowadays I never hear of them, never see anything interesting come from them. All the interesting stuff is happening elsewhere.
I think it's easy for dominant players to sit back and let revenue stream in when there's no much in the way of real competition, which can lead to devs leaving for greener pastures (where green is either more interesting or pays better because dev is de-prioritized at the current company). Then some real competition shows up and the company is woefully unprepared. I think it's an important lesson, just because your competition doesn't appear to be forcing you to innovate and expand, doesn't mean there isn't someone silently lurking ready to upend your world.
Razor is for private cloud, the biggest problems it solves are bare-metal provisioning as well as OS-specific mass-install tools. One of use-case for Razor: pop-in a new server into the rack, get provision ESXi with Razor and then provision a number of CentOS and Debian VMs without having to care how different is Kickstart from Preseed. It's a great too, but it's mostly for private cloud and Teraform is for public cloud and is therefore at a higher level.
Anyone know if an API is planned? If I want to manage infrastructure from code I would love Terraform to be an option.
As a (predominantly) Node.js developer, I'd probably use pkgcloud for this sort of thing. Terraform supports a great range of providers and has some more advanced features, so I'd love to play with it as an alternative to pkgcloud.
114 comments
[ 3.2 ms ] story [ 157 ms ] threadLike Aerospike, or Uber.
McDonald's was at least started by two guys with the surname McDonald. It is/was their company so they named it after themselves. That's no different than "Frank's Burger Stand", which is again completely different than writing a clone of GCC in javascript and then calling it Patriot or something.
(this isn't to say it shouldn't have had a better title - but just to explain why a lot of people weren't bothered by it)
It reads like you can use any provisioning software, use any server provider supported, use any DNS provider supported, you just need to write a bunch of configuration.
I think I like this, but it sounds complex :D
While not multi-platform, AWS's Cloud Formation does just this, it takes as its input a stateless JSON description of a set of AWS resources and their dependencies. Given a change in the desired state, it will do its best to update resources rather than creating them from scratch when possible.
There are more comparisons to CF here: http://www.terraform.io/intro/vs/cloudformation.html
[1]: http://www.terraform.io/docs/commands/plan.html
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuid...
Another things that excites me about separating the plan from the execution is that I can periodically run `terraform plan` to check for configuration drift without risking making a change. I've been bitten by the following:
1) Someone creates an ASG with the desired number of instances set to 1 via CloudFormation 2) Later, they increase the desired number of instances, e.g. to 5, via the EC2 console or API rather than CloudFormation 3) I come along and apply an update to the stack via CloudFormation. This resets their ASG to 1 instance, terminating the other 4.
If anyone from AWS is reading this, please steal this feature for CloudFormation!
(I also was confused by the original wording. Thanks for clarifying.)
Terraform's execution plans, on the other hand, can be saved and applied. This tells Terraform that it can _only_ apply what is in the plan. It _must not_ do anything else.
To match TF here, CloudFormation would really need "staged changes and applied changes" as separate steps.
I'm reading through the TF docs now... It looks like it doesn't support enough AWS resources for me to replace CF with it yet, but I'd sure love to.
Homepage - http://www.terraform.io/
Introduction - http://www.terraform.io/intro/index.html
Documentation - http://www.terraform.io/docs/index.html
Sourcecode - https://github.com/hashicorp/terraform
-
Seems usable and I'm excited to try it out. I like the idea of "execution plans" and the declerative way of setting up the architecture.
http://imgur.com/a/Wz87U
Top image is fixed and bottom image is what I get when I first visit the site.
What is weird is that as soon as I remove the skew on the first feature bar (feature-auto) it clears up everything below it (all of the text within skewed elements looks weird). But if you re-enable the skew it distorts again. Also if remove the skew from the 2nd feature it will fix everything below it but not the stuff above and so on for the 3rd or the #demo.
Parallel deployment of multiple clusters is also covered. It too is handled by a directed acyclic graph based on dependencies on other clusters. I am on my own and I am writing it for my thesis which will come out pretty soon.
It is created as an engine that expects cluster state. A sample input file can be seen here which is the only state you need to launch something. https://gist.github.com/wernerb/35a06e08a4d4e6cb02aa
The whole thing works declaratively, so it converges your infrastructure to the desired state. By increasing the nodes for 'smallweb' it will undergo the steps defined in the cluster lifecycle. It will then also update the configuration of the nginx load balancer.
As you can see each cluster is pinned to a provider/instanceprofile, and one of the things I am adding are affinity rules so the cluster deploys to multiple locations/providers.
It is not ready to be opensourced but if any wants to see, contribute or see more I can give view access.
What do you think?
Whats more ozone does not store any state, rather it stores it in a zookeeper/etcd cluster so you are in control of your meta-data.
https://www.dropbox.com/s/0ki0m7967x5tvn6/Screenshot%202014-...
On another note, Terraform appears to be great. I cannot wait to try it out.
It sounds like it would be possible to plug nix-based provisioning into Terraform, and use it to manage the high-level cluster structure.
Edit: downvotes? whatever for?
Regardless, your software kicks ass. Thanks to you, and your team. Keep on trucking.
EDIT: There's an issue tracking adding more at https://github.com/hashicorp/terraform/issues/28
http://www.terraform.io/docs/providers/aws/r/launch_config.h...
https://github.com/hashicorp/terraform/blob/9b0ba70537a440b3...
A great tool, at least for Python, that exposes this is: https://github.com/cloudtools/troposphere.
This gives me the full power of python, so I can build abstractions, use inheritance and encapsulation to specialize certain things.
We've done a lot of work to automate our infrastructure provisioning, but I'm interested in the abstraction layer Terraform provides -- especially for multiple providers.
How can we bridge the gap that is left by Terraform from having a fully complete programming language to define infrastructure (which has downsides but in my opinion, more upsides)?
You can use that to write higher level wrappers to generate the JSON, and was indeed one of the intentions.
https://github.com/sintaxi/terraform https://github.com/sintaxi/harp
Looks like an interesting project though.
We're actively working on a way to bring existing infrastructure under Terraform management without having to recreate it from scratch. The process will actually be really easy (but is vaporware at the moment): Terraform only needs the TYPE of a resource and ID of that resource. From there, it can "refresh" the rest of the metadata in.
Our idea is that you'll be able to say "I have an `aws_instance`, it's ID is `i-1234567`, and it satisfies the 'foo' resource" and it'll attach it.
Point being: we're thinking about this, and it is an important aspect of Terraform.
Another point is that you don't need to convert 100% of your infrastructure to Terraform to extract value from it. You can start by putting only specific services under management, and grow from there.
I was wondering what happens when you increase the amount of nodes of a particular instance? I assume a new machine is started. But what happens if you remove the entire resource altogether, does it terminate the whole cluster? Similarly how does a scaling in a node work? And how would it affect dependencies?
How does this consolidate with elasticity of a particular cluster. I.e. if an amazon load balancing group destroys an instance or takes one up, do I simply refresh and it would detect that this new instance is part of the defined cluster in terraform?
Awesome work on this tool.
I think this is specially important with elastic IPs that have been whitelisted somewhere, e.g. a VPN of a 3rd party service provider. So a way to say, take EIP x.x.x.x, don't ever release it and then indicate what instance to associate it to is great.
Another example of this feature is starting from an existing VPC and build from there, or even actually inherit information from the current state and convert it to an "auto generated plan" to build from. Thanks again Hashicorp for all the great software.
https://github.com/hashicorp/terraform/blob/master/LICENSE
http://puppetlabs.com/solutions/next-generation-provisioning
As a (predominantly) Node.js developer, I'd probably use pkgcloud for this sort of thing. Terraform supports a great range of providers and has some more advanced features, so I'd love to play with it as an alternative to pkgcloud.