A Comprehensive Guide to Terraform
A series of posts that will teach you best practices for using Terraform in the real world
Update, November 17, 2016: We took this blog post series, expanded it, and turned it into a book called Terraform: Up & Running!
Update, July 8, 2019: We’ve updated this blog post series for Terraform 0.12 and released the 2nd edition of Terraform: Up & Running!
Update, Sep 28, 2022: We’ve updated this blog post series for Terraform 1.2 and released the 3rd edition of Terraform: Up & Running!
Today, we are kicking off a series of blog posts on how to define and manage infrastructure-as-code in the real world using Terraform. If you haven’t used it before, Terraform is an open source tool that allows you to define infrastructure for a variety of cloud providers (e.g. AWS, Azure, Google Cloud, DigitalOcean, etc) using a simple, declarative programming language and to deploy and manage that infrastructure using a few CLI commands.
At Gruntwork, we use Terraform as one of our primary infrastructure-as-code tools in the Infrastructure as Code Library, which is a collection of over 300,000 lines of reusable, battle-tested, commercially-supported, production-grade infrastructure code for AWS, GCP, and Azure that’s used in production by hundreds of companies. In this intro post, we’ll discuss why we believe every software company should be using infrastructure-as-code. In the rest of this series, we will cover the following topics:
- Why we use Terraform and not Chef, Puppet, Ansible, Pulumi, or CloudFormation
- An introduction to Terraform
- How to manage Terraform state
- How to create reusable infrastructure with Terraform modules
- Terraform tips & tricks: loops, if-statements, and pitfalls
- How to use Terraform as a team
So, without further ado, let’s jump into it and discuss why every software company should define its infrastructure-as-code.
Why infrastructure-as-code?
A long time ago, in a data center far, far away, an ancient group of powerful beings known as sysadmins used to deploy infrastructure manually. Every server, every route table entry, every database configuration, and every load balancer was created and managed by hand. It was a dark and fearful age: fear of downtime, fear of accidental misconfiguration, fear of slow and fragile deployments, and fear of what would happen if the sysadmins fell to the dark side (i.e. took a vacation). The good news is that thanks to the DevOps Rebel Alliance, we now have a better way to do things: Infrastructure-as-Code (IAC).
Instead of clicking around a web UI or SSHing to a server and manually executing commands, the idea behind IAC is to write code to define, provision, and manage your infrastructure. This has a number of benefits:
- You can automate your entire provisioning and deployment process, which makes it much faster and more reliable than any manual process.
- You can represent the state of your infrastructure in source files that anyone can read rather than in a sysadmin’s head.
- You can store those source files in version control, which means the entire history of your infrastructure is now captured in the commit log, which you can use to debug problems, and if necessary, roll back to older versions.
- You can validate each infrastructure change through code reviews and automated tests.
- You can create (or buy) a library of reusable, documented, battle-tested infrastructure code that makes it easier to scale and evolve your infrastructure.
There is one other very important, and often overlooked, reason for why you should use IAC: it makes developers happy. Deploying code is a repetitive and tedious task. A computer can do that sort of thing quickly and reliably, but a human will be slow and error prone. Moreover, a developer will resent that type of work, as it involves no creativity, no challenge, and no recognition. You could deploy code perfectly for months, and no one will take notice — until that one day where you mess it up.
That creates a stressful and unpleasant environment. IAC offers a better alternative that allows computers to do what they do best (automation) and developers to do what they do best (coding).
Why Terraform?
There are many ways to do IAC, from something as simple as a hand-crafted shell script all the way up to a managed service such as Puppet Enterprise. Why did we pick Terraform as our IAC tool of choice? To find out, head over to Part 1 of our series, Why we use Terraform and not Chef, Puppet, Ansible, Pulumi, or CloudFormation.
For an expanded version of this blog post series, pick up a copy of the book Terraform: Up & Running (3rd edition available now!). If you need help with Terraform, DevOps practices, or AWS at your company, feel free to reach out to us at Gruntwork.
