Book Image

Getting Started with Terraform - Second Edition

By : Kirill Shirinkin
1 (1)
Book Image

Getting Started with Terraform - Second Edition

1 (1)
By: Kirill Shirinkin

Overview of this book

Terraform is a tool used to efficiently build, configure, and improve the production infrastructure. It can manage the existing infrastructure as well as create custom in-house solutions. This book shows you when and how to implement infrastructure as a code practices with Terraform. It covers everything necessary to set up the complete management of infrastructure with Terraform, starting with the basics of using providers and resources. It is a comprehensive guide that begins with very small infrastructure templates and takes you all the way to managing complex systems, all using concrete examples that evolve over the course of the book. The book ends with the complete workflow of managing a production infrastructure as code—this is achieved with the help of version control and continuous integration. The readers will also learn how to combine multiple providers in a single template and manage different code bases with many complex modules. It focuses on how to set up continuous integration for the infrastructure code. The readers will be able to use Terraform to build, change, and combine infrastructure safely and efficiently.
Table of Contents (15 chapters)
Title Page
About the Author
About the Reviewer
Customer Feedback

Requirements for infrastructure provisioner

Before proceeding to the existing solutions, let's lay out a list of the most important requirements for a tool such as this, so we are able to choose one wisely.

Supports a wide variety of services

AWS alone already has dozens of entities to take care of. Other players (DigitalOcean, Google Cloud, Microsoft Azure, and so on) increase this number significantly. And if you want to add smaller SaaS providers to the game, you get hundreds of resources to manage.


The same as with a single-server configuration, reapplying an infrastructure template should not do the job twice. If you have a template defining 50 different resources, from EC2 instances to S3 buckets, then you do not want to duplicate or recreate all of them every time you apply the template. You want only missing parts to be created, existing ones to be in the desired state, and the ones which have become obsolete to be destroyed.

Dependency resolution

It is important to be able not just to define 2 app servers, 1 DB server, and 2 security groups, but to also point them to each other using lookup mechanism. Especially when creating a complete environment from scratch, you want to ensure the correct order of creation to achieve the flawless bootstrap of each component.


Here, and further in the book, the term environment will mean a complete set of resources that an infrastructure consists of. It includes a network setup, all servers, and all related resources.

Robust integration with existing tools

Even though it is pretty awesome to have all infrastructures in one beautiful template, you still need to take care of what is happening on each particular server: applications need to be deployed, databases need to be configured, and so on. This is not the job for an infrastructure provisioning tool. But, certainly, a tool like this should easily integrate with other tools such as Chef, which solves this problem already.

Platform agnosticism

Ideally, templates should be platform agnostic. This means that if I define a template for 2 app servers, 1 db server, all talk to each other, I should be able to easily switch from AWS to local Vagrant without rewriting the template. Platform agnosticism is difficult to obtain, while at the same time, might not really be needed that often. Completely changing the underlying platform is a rather rare event that happens perhaps once or twice in a product's lifetime.

Smart update management

This is a tricky one, and at the moment of writing, no tool can do it flawlessly in every case (and, honestly, it is unlikely one will ever). What happens when I change a type of three EC2 instances from m3.medium to c4.xlarge? Will my m3.medium instances shut down and be replaced one by one by new ones? Will they be instantly destroyed leading to a few minutes of downtime? Or will the tool, just ignore the updated instance type? Or will it not and then just override old nodes and I will end up with three new nodes and three old EC2 instances that I have to remove manually? Solutions to this problem differ from platform to platform, which makes it more complicated for the tool to be platform agnostic.

Ease of extension

The last requirement is of particular importance: there must be an easy way to extend this tool to support other resources. For example, if a tool lacks support for AWS Kinesis or a particular feature or property of already supported service, and there is no plan to support it officially, then there has to be a way to implement it yourself quickly.