Learn more about Terraform, an open source tool that enables you to automate and manage your infrastructure, platform, and services using a declarative language.

In my latest lightboarding video, I cover the basic Terraform work flow, show how it is pluggable, and talk a little bit about the DevOps first approach that Terraform enables.

Learn more

• What is Terraform?
• IBM Cloud Schematics
• What is DevOps?
• What is Kubernetes?
• What is a Virtual Machine (VM)?
• What is a Virtual Private Cloud (VPC)?
• View the full playlist of lightboarding videos

Video Transcript

What is Terraform?

Hello everyone, my name is Sai Vennam, and I’m with the IBM Cloud team. Today we’re going to be talking about Terraform.

Terraform is an open source tool, originally developed by Hashicorp, that enables you to automate and manage your infrastructure and platform and services, as well.

Terraform and declarative language

It does all of this using a declarative language, and that’s the first thing we’re going to focus on when we go through our example to go through Terraform.

So, I generally like to start with an example here. Say you’re driving in your car, trying to get from point A to point B. Generally, you would follow a set of instructions, right? So, going from point A to point B, say I should take a left turn, get on the highway, take this exit—you end up at your destination.

Now that’s kind of an imperative approach to automation. The way Terraform does it—imagine you called a taxi or a rideshare service and told them exactly where you wanted to go—point B. The car or the driver then takes care of the rest. You don’t have to worry about every step of the way to get there, and that’s the approach Terraform takes. That’s why it’s so effective at managing your infrastructure.

Example: Three different resources to spin up

Today, we’ll start with an example say you’ve got three different resources that you’re trying to spin up as part of your infrastructure.

We’ll say you’ve got a VM, will also say you’ve got a Kubernetes cluster, and say that they’re networked together using a VPC, or virtual private cloud.

So, current state—nothing’s there; desired state is this set up infrastructure. So, in Terraform, there’s going to be three major phases and we’ll go step-by-step.

Phase 1: Code

The first phase you actually have to create the Terraform file. So, we’ll start with that where you actually write or code up that Terraform file.

Now in this Terraform file, we’re going to have three major resources, right? We’ll start with the VM and a set of arguments to support that. Things like the name, networking, data center—that kind of thing.

We’ll have the Kubernetes cluster and a set of arguments for that. 

And then, finally, we’ve also got the VPC. It’s probably going to refer to some of the network settings of the VM and the Kubernetes cluster, but it’s going to network those together, and so it has arguments to support that.

So, that’s your coding phase say you’ve got a Terraform file—TF—file with these things defined.

Phase 2: Plan

Next up, we’ve got the Plan phase. 

Now, this is an actual Terraform command. So in the TF CLI (or command-line interface), you can run Terraform Plan, and what it’s going to do is it’s going to compare the desired state to what actually exists.

So, you know, on Day 0, it’ll notice that you have none of these resources, so it’ll say “Hey, you have to create all of them.” So, create the VM, create the cluster, as well as create the VPC.

So it has a plan, and it tells you (the user) that this is what it’s going to do. 

Phase 3: Apply

Next, if everything looks good, you’ll do the Apply phase.

This is another Terraform CLI command, and in the Apply phase, you can actually take those resources and spin them up.

So that’s exactly what’s going to happen. Terraform is going to work against the cloud providers using real APIs—your API token—to spin up these infrastructure resources, and it’s going to output some interesting or auto-generated variables along the way. So, for example maybe the Kubernetes dashboard URL, or maybe even a URL to access your application. But, regardless, it’s going to output a number of these output variables. 

So, that’s generally how the Terraform workflow goes to get you from point A to point B in a situation where you had nothing, and now you have something. So, that’s what I wanted to start with.

Terraform has a strong open community and is pluggable by design

Next, I want to go into the fact that Terraform has a strong open community, and it’s pluggable by design. 

So by pluggable, essentially what I mean here is the fact that it’s made up of modules and resources where you put in input variables and output comes out, as well as the community is out there and cloud providers are out there building and supporting things called cloud providers (or providers in the Terraform world) to enable you to connect up to any cloud and automate infrastructure there.

So, in this process, we actually made something called a Terraform module. A Terraform module is a way of grouping together some Terraform automation. So, we’ve got a Terraform module here—it actually takes a set of input and also creates some output.

Providers

And as part of every module—well you can define this, but generally, when you’re working with cloud providers and using Terraform, you’ll also define what’s called a provider.

Now a provider can be a number of things, but in our case, we were using it as a cloud provider to connect up to a given cloud.

So that’s the first thing that a provider can do—connect you up to IaaS providers (IBM Cloud or AWS or Azure). It enables you to connect up to some infrastructure provider, spin up things like VMs or that kind of thing, maybe bare metal.

You can also use a provider (in the Terraform sense) to spin up platforms (Paas) as well. So it enables you to manage, for example, Cloud Foundry running in the cloud.

Finally, you can even manage SaaS offerings—things like CloudFlare or other software services can actually be managed by Terraform.

Although Terraform is considered to be an infrastructure automation tool, it’s expanded its role to support other types of providers as well.

So, essentially, we’ve got our flow here, our module, inputs, and outputs—and so we’ve got a kind of pipeline to be able to spin up resources.

DevOps first

The last advantage I want to mention here with Terraform is the fact that it enables you to have the best practices for DevOps. So we’ll say “DevOps first.” 

Now, let’s take an example for this. In our example here, we did a Day 1 kind of deployment—nothing to something. But, let’s say we’re going back and iterating on this. 

So we’ve got our VPC, we’ve got our VM, as well as Kubernetes.

Now let’s say we’re iterating on this, and we want to create something new on top of this infrastructure. Let’s say we want a load balancer. 

That’s our desired state. So, we’ll do our three phases.

Start with the Code phase. We’ll say here that we want a load balancer, and we’ll have set of arguments to support that. 

When we get to the Plan phase, Terraform is going to realize, hey we actually already have the VM, Kubernetes, and VPC—it checks the current state of the world and realizes all we need is that new load balancer. 

So it’ll say “hey, let’s just add the load balancer this time around.” 

And as a user, you’ll confirm that make sure it looks good, go to the Apply phase, go ahead and apply it, maybe some more config variables will come out for this new capability that you added.

So essentially with Terraform, you have a DevOps-first approach. One of the key advantages to this is it enables you to avoid potential config drift, that’s when the configuration that defines your infrastructure actually doesn’t match what’s actually there.

So as long as all changes to your infrastructure go through the Terraform file and Terraform pipeline, you can essentially eliminate the risk of configuration drift.

In addition, since we’ve set up a module where we can take input variables and have a final state, what we can essentially do is recreate this—maybe switch up the environment variables a bit—and then create a whole other environment that looks just like this, but this time we can make one for test. And maybe this one was dev. 

And we can do that again for, maybe, prod. It’s another advantage of taking a Terraform approach to infrastructure automation—it enables you to put DevOps first.