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?
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.
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.
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.
Looks like an interesting project though.
In your example, Terraform would create and save the ID of the server to state before going along to create the DNS record. If the DNS record failed to create for some external reason, the next `terraform apply` you ran would simply refresh the server and go on to create the DNS record.
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.
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.
From a cursory overview, it looks like Terraform is basically LIKE a CloudFormation type abstraction. Ansible contains declarative models for lots of cloud providers as well, but does not attempt to abstract out the different clouds. We generally view wanting to show things in their natural state (figuring you will know you want to use feature X or Y, and want the knobs/buttons exposed).
But yes, we have similar features for saying "X instances of this should be running now", make it so, all that don't require use of CloudFormation.
For people that like Terraforms flavor though, I can see users using these tools together. They could declare a cloud using either ansible or terraform, and then use ansible for the final configuration and application deployment, plus full lifecycle management.
I know things like Packer like to walk people down a more imagey road, but you can also use config tools to describe the recipes that build your images, and that would include Ansible, Puppet, Chef, or even (if you so wished) bash.
I'm not a fan of bash though :)
I'm happy to see more efforts to make cloud provisioning accessible though, and like the idea that this would allow more easy migration between some cloud providers. Ansible has a lot of the same declarative thingies, but will probably appeal more to people who aren't looking for the DSL.
It doesn't look like Terraform is attempting to be a provisioner itself, so it wouldn't do the things that Ansible or other config/app deploy tools do once you have a running instance, but does some of the things various config tools do to help you GET a running instance.
One of the things shown in the Ansible examples are how to do a cloud deploy in one hop, i.e. request resources and also configure the stack all the way to the end, from one button press, and can also be used to orchestrate the rolling updates of those machines, working with the cloud load balancers and so on, throughout their entire life cycle -- all using just the one tool.
As for where the future of this tool is, I obviously can't speculate, nor should I. But I do welcome more attempts to simplify beasts like the AWS EC2 API space, because I think we both agree nobody wants to really keep all of that in their head at all times.
Just like Chef and Puppet seem to have leapt off from a solid platform started by cfengine et all, and made 'configuration as code' a thing, Ansible, Salt cloud, and Terraform seem to be kicking off the 'infrastructure as code' movement (and are adapting to many different workflows—Docker, Chef, Puppet, etc. play nicely in this sandbox).
Too many places rely on band-aids, shell scripts, and manual process for infrastructure, mostly because tools like Ansible and Terraform haven't existed until recently (or today, in Terraform's case).
One of the most valuable things has turned out to be the ability to refactor infra as a project evolves. Some task that would have required a few hands and a project manager now becomes a few edits.
I lead a CFEngine team and It never fails to amaze people when I demo end to end life cycle management "that used to take 3 guys 2 days" etc.
P.s. I use ansible at home though: https://github.com/CraigJPerry/home-network
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
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.
EDIT: There's an issue tracking adding more at https://github.com/hashicorp/terraform/issues/28
"[..] Terraform combines resources from multiple services providers: we created a DigitalOcean Droplet and then used the IP address of that droplet to add a DNS record to DNSimple. This sort of infrastructure composition from code is new and extremely powerful."
Well, "new" in the sense of "we created another thing to automate infrastructure deployment and configuration". I have worked with various amalgamated solutions that do this for the past 12 years. Of course they mention that in the software comparison section, but it doesn't take away from the fact that this isn't new by a long shot.
"Terraform has a feature that is critical for safely iterating infrastructure: execution plans. Execution plans show you what changes Terraform plans on making to your infrastructure. [..] As a result, you know exactly what Terraform will do to your infrastructure to reach your desired state, and you can feel confident that Terraform won't surprise you in unexpected ways."
So it's declarative, and it has a dry-run mode.
The thing that really bugs me is the idea that you should be creating "code" to do rote tasks such as changing resources or deploying things. You know what the single most problematic thing about infrastructure changes is? Human error. It's a simple fact of user interface design that humans are less likely to fuck up a point-and-click interface than a command line program that you have to feed a hand-edited config to. And automated config generation can arguably be more error-prone.
Automation/orchestration should not simply make things happen automatically. It should make things work more reliably, and require less expertise to do so. To be frank, any code monkey with a few weeks of free time to kill can create a tool that does exactly what this one does, and that's why there are dozens of them that all do the same thing, yet we always need a new one.... because they all stink at actually making things work better.
This comic isn't just funny, it's a truism: https://xkcd.com/1319/
I have a quick question I didn't see covered in the docs. Is there a best practise way to organise Terraform configuration files? Specifically when using it to manage different environments (e.g. staging, prod, qa). I'm thinking of some sort of folder structure like this:
Would be interested to know if you have any thoughts on this, or if there's some sort of paradigm you folks are using internally.
I would love to keep the complete codebase for our infrastructure's config in a single place, in a single language; I can see Terraform driving Puppet with variables, but there's an overlap here (declarativeness and modularity) that would benefit from being seamless.
Then again, with something like Docker you hardly need Puppet, and could simplify the recipes to the point where Terraform injected vars into a dockerfile before deploy.
Docker still fits for your problem, so does Packer. Honestly, it's super nice to not have to worry about any external resources failing, where you only have 1 thing pulled in to deploy any type of application, and that would be the image.
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
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.
On another note, Terraform appears to be great. I cannot wait to try it out.
Regardless, your software kicks ass. Thanks to you, and your team. Keep on trucking.
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.
Like Aerospike, or Uber.
(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)