Terraform - IAC Tool

DZone 's Guide to

Terraform - IAC Tool

See why Terraform's declarative approach to automation makes it a competitive tool for automating the creation of your infrastructure.

· DevOps Zone ·
Free Resource

Gone are the days where we waited for weeks or months to provision a bare metal server for our application. It can take time to configure and get them up and running. There is simply no time to wait in this fast-moving world. Companies want to succeed sooner by implementing cutting-edge solutions in this competitive world. We need to have a configuration management tool to automate the creation of our infrastructure.

What if we can configure an immutable infrastructure with less of a learning curve?

In this intelligent virtual and cloud-obsessed world, all companies use infrastructure as code (IAC) to spin up servers/instances, be it in AWS, GCP, or OpenStack. The popular tools available are

  • Chef

  • Ansible

  • Puppet

  • CloudFormation

  • Terraform

The million dollar question that comes to your mind: with a plethora of tools available, which tool to choose to provision or configure my infrastructure? Undoubtedly, you need the right one, which minimizes risks, avoids human error... I hope my thoughts on the process of using Terraform for infrastructure configuration will help you get rid of the confusion.

Image titleWhy Terraform?

Here are our reasons to choose Terraform over other tools:

  • Terraform is an "orchestration" tool, not an "automation tool:" Automation is a task completed without human intervention, while Orchestration means, taking a task and creating a workflow, or running several automated tasks called as processes. For example, orchestration is a way of combining multiple automation tasks to create IP or creating a security group
  • Terraform is "Declarative" not "Procedural/Imperative:" These are contrasting programming patterns. Declarative programming does not control the flow of the program, you just say what you want and not say how to do it. Procedural programming, on the other hand, you define the whole process and provide the steps how to do it.

For example, if you want to deploy five OpenStack instances to run an app, here is the sample code Ansible template using a procedural approach:

- name: launch a compute instance
  hosts: localhost
    - name: launch an OS instance
        state: present
        region_name: region-b.geo-1
        image: CentOS-7.0
        image_exclude: deprecated
        flavor_ram: 4096
        count: 5

And below is the another example using Terraform's declarative approach:

resource "openstack_compute_instance_v2" "basic" {
  count           = 5
  image_id        = "a12we-5ftrg"
  flavor_id       = "3"
  key_pair        = "my_key_pair_name"
  security_groups = ["default"]

Yes, the two approaches look quite similar. But only when you initially execute them with Ansible or Terraform.

Now, it's peak load for your server; consider you want to increase your instance count to 15. With Ansible code, if you just change count value to 15 and rerun, it will deploy 15 new servers and create 20 in total. Holy moly! Was that needed? Instead, if rerun the Terraform code after changing your count, it will only create an additional 10 servers, making the total count 15. This is because with declarative programming, you declare the end state you want. The declarative approach in Terraform always represents the latest state of your infrastructure. Amazing, isn't it?

  • Terraform follows Client Only Architecture, not Client/Server Architecture: Chef, Ansible all follow client/server architecture. You issue commands on a client system and it executes your commands and stores the state of your system. The server talks to agents, which must installed on every instance you want to configure. With this architecture, moving parts coming as a perk and may cause new failure modes. While Terraform uses the cloud provider API's to configure your infrastructure.
  • Terraform has Multi-Provider Support: Terraform provides convenience to switch between different cloud providers like Google, AWS, Open Stack, Azure. Terraform allows you to write code specific to each provider.
  • Terraform gives Immutable Infrastructure: This means once you instantiate your server, you do not change it. Instances are redeployed, instead of restoring from previous versions. Components are replaced rather than being updated with newer versions. This reduces the potential of Configuration Drift and uptime is improved.

In the good old days, servers were named "Venus" or "Mercury"... But in the cloud/virtualization world, servers are now sequentially numbered from "Server001" and "Server02"...to "Server100." When one server goes down, it's shot down and replaced with a new one. Well, Terraform isn't perfect, but it did fit our bill. It just came out in 2014, while CHEF/Ansible came out in 2009/2012. In the next part of this series, I will go through how we configured Terraform with OpenStack and bootstrapped with CHEF automatically.

I hope this article gave an overview on Terraform. We use it in our organization, since we do use OpenStack and we found it is working for our requirements.

automation, devops, infrastructure as code, terraform

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}