Infrastructure as Code and How Terraform Fits Into It

Illustrated image of a person with white hair wearing an orange scarf, holding a pinwheel, staring at it contemplatively, with a bubbling cauldron in the background. Illustrated image of a person with white hair wearing an orange scarf, holding a pinwheel, staring at it contemplatively, with a bubbling cauldron in the background.

Welcome to the free Terraform Lighting Course. By the end of such course, we hope you will get a good grasp of what the topic is about and how to apply the new knowledge at work.

The goal of the Terraform Lighting Course is to introduce you to the Terraform, explain which problems it solves and show you how it's used in a multi-cloud environment.

DevOps consulting: DevOps is a cultural and technological journey. We'll be thrilled to be your guides on any part of this journey. About consulting

The plan of the course is the following:

  • In this lesson, we will learn about Infrastructure as Code and few major ideas behind Terraform.
  • In the second lesson, we will start writing our first Terraform template to create the bare metal server on Packet cloud.
  • In the third lesson, we will see how to supply configuration to Terraform templates, including secrets.
  • In the fourth lesson, we will extend our templates to create DNS records in AWS Route53. This is where you will see how to use Terraform for multi-cloud environments.
  • In the fifth lesson, we will do some refactoring by using modules.
  • And in the last lesson we will learn how to install single-node Kubernetes cluster with the help of provisioners. We might also throw another provider on top to deploy the application on this cluster.

Our final Terraform configuration will be able to deploy bare-metal single-node Kubernetes clusters in minutes. Hopefully, you are excited to start learning now!

But to understand Terraform we first have to understand what Infrastructure as Code is.

Simply put, Infrastructure as Code is the idea that your infrastructure should be developed like any other software. Instead of manually configuring servers, writing configuration files and running shell commands, you are describing your infrastructure as, well, code.

Moreover, you test and deploy this code via continuous deployment pipeline, just like you would do with applications. Even though your collection of shell scripts certainly fits the definition of infrastructure as code, most often this term is associated with a bit more complex and specialized tools, like Chef, Puppet or Ansible.

The common feature of all infrastructure as code tools is the declarative approach.

Declarative approach means that instead of telling computer what to do, you are telling it what you need to have.

In case of a shell script, you would run a series of commands to first create a directory, then assign proper permissions and ownership to this directory.

In case of an infrastructure as code tools, configuration management tools in particular, you would tell the tool "the server should have a directory with write permissions and owned by developers group".

You are not telling the tool how to create the directory - it's the job of the tool to figure this out.

The first wave of such tools, like already mentioned Chef and Puppet, were focused on automating configuration of what goes inside the server or, quite often, network devices.

Those tools would not create the servers for you, their job would start after the server is already provisioned.

But then the cloud appeared and managing infrastructure became much more exciting that just configuring servers.

It first started with more and more convenient and cheaper ways to create virtual machines inside services like AWS EC2.

But then more specialized cloud services appeared - database as a service, monitoring as a service, object storage as a service and so on.

By now, Amazon Web Services alone has hundreds of different services.

Add on top other major cloud providers like Google Cloud and Azure, plus consider the specialized infrastructure service providers like DataDog for monitoring or Okta for identity management and you will get the idea how multi layered the modern cloud infrastructure might get.

Luckily, all of these services have API, or Application Programming Interface, that allows us to view, create, update and delete all the resources automatically. And this is where Terraform came into the picture.

Instead of being another tool that configures servers, Terraform focuses on primitives one layer above.

Terraform creates servers, load balancers, DNS records, monitoring rules, GitHub repositories, object storage locations and so on.

You can certainly use tools such as Chef, Puppet, Salt or Ansible to do the same task. It could be that for your particular project you even should use them.

But as we will see in the next lesson, Terraform has very smart ways around managing all of those resources that makes it stand apart from other infrastructure as code tools.

This is, first and foremost, the Terraform course, so we are not going to focus too much on the infrastructure as code best practices and concepts.

That's it for this lesson.

In the next part of the Terraform Lighting Course, we are going to learn about providers and resources, state and dependency management, and we will create our first cloud instance.

Here's the same article in video form for your convenience: