Terraform (Part 1) : Intro

Infrastructure as Code (IaC) has been popular for a while now. If you have tried any of the solutions out there (Terraform, Cloudformation, OpenStack Heat) I am sure you have your favorite and are now wondering how you could have lived without it. For people like me, who do not come from a SysAdmin or SysOps background, the explanation is kind of confusing which leads to questions like, “How does Terraform compare to ……”? Fill in with (Ansible, Chef, Puppet, Salt). In this first part of a three part series, I am going to try to explain the concept in a simple manner… in a way I would have liked someone to have explained it to me when I first came across it.

In a few words

So, Infrastructure as Code, how does that work? Let’s take building something with a cloud service provider for example. Most (if not all) of them have APIs you can use to setup or configure certain features. Now imagine you had a programming language that you could use to call these APIs (in the background) to do certain tasks for you. You would end up with code you would write once, but any time you run it, would build exactly what you wanted. Just like a “Hello World” script. Each time you run it you get “Hello World” 😄

The only difference here is that, since you are building an infrastructure and not just printing “Hello World” to screen, the IaC program first checks to see if “Hello World” exists, if it does not exist, it creates it. But if it exists, it does nothing. If it is “Hello my World” you want, it compares to what exists and just adds “my”. If however you wanted “Hello Earth”, again it compares to what exists, removes “World” and adds “Earth”. The added bonus is no more searching for settings in drop down menus of cloud service providers and getting lost when v.2 of their “awesome” interface gets released. Also, now you can have your “Hello World” infrastructure code, like any other code, in git so you track all your changes. This is what Infrastructure as code is all about.

Yes, the concept is that simple yet powerful …

Terraform

My intention is not to compare IaC applications and draw a conclusion as to why you should choose Terraform. We all have different needs but some of my reasons are:

• It is open source.
• It supports a wide range of cloud service providers.
• For me it had a low learning curve (as I said earlier, my background is not in SysOps).
• It has a huge community.

With the basic knowledge we have so far on IaC, let’s now see how Terraform works at a very high level. Continuing with the analogy of a generic programming language, the same way you have modules and functions, you could consider every cloud service provider a module with their respective functions. If you change cloud service provider, you change the module. But as all modules do not have the same functions or function names, the same is true for when switching cloud service providers. However, here again is one benefit of having the infrastructure as code, you can read the code and know what exact function you need to call in the new ‘module’.

Heads up

Nothing is perfect and neither is Terraform. As of this writing (March 2021), there is one thing I find would need your special attention and that is the Terraform State file. Another more general thing to think about is the security and availability of API keys needed by Terraform. Also service providers have different ways of authenticating within their ‘modules’ so there might not be a one size fits all solution for all service providers.

Terraform State file

Whenever you run terraform, it by default keeps some information locally on the state of the infrastructure it built. This JSON formatted file, terraform.tfstate contains the mapping of resources in your configuration file to what was actually built in the service provider. This is how it is able to make checks, manage or destroy resources. To ensure that multiple changes are not being made at the same time, Terraform locks the state file when it is running.

Obviously there can only be one “true” state file so when working in a team you need to think of how all users can have access to the file yet not make changes at the same time. To help resolve this, Terraform supports saving the state file remotely. Supported storage backends are not only popular options like Amazon S3, Azure Storage, Google Cloud Storage but also solutions like etcd, Postgres and even http! Since the state file can sometimes contain sensitive data in plain text, the recommendation is to ensure it is kept secure and encrypted.

What about server configuration?

You might be thinking “If we can have our infrastructure written as code, is it possible to have our server configuration written as code as well?” The answer is “Yes”. Although Terraform can configure a server when it is deploying it, this is not it’s primary purpose. This is where Ansible, Puppet, Chef and Salt come into play. After the infrastructure has been built, they go in and maintain the server configuration (add users and their SSH keys, install software, server hardening etc).

Finally

I hope my explanation of IaC was simple enough to understand yet good enough to make you interested in trying out Terraform. In the second part of this series we will be building our first infrastructure and deploying an Asterisk server.