DevOps | Terraform Helloworld on Linux

Infrastructure-as-Code (IaC) is a practice used in public cloud providers, such as AWS, GCP, and Azure.

In a nutshell, it consists of managing a set of resources (computing, network, storage, etc.) using the same approach developers use to manage application code.

Photo Of Sri Lanka by Adam Marikar on Unsplash

In this tutorial, we’ll do a quick tour of Terraform, one of the most popular tools used by DevOps teams to automate infrastructure tasks. Terraform’s main appeal is that we just declare what our infrastructure should look like, and the tool will decide which actions must be taken to “materialize” that infrastructure.

Terraform can connect to many number of resources via providers which counts over 100. This sheer number of supported resources makes Terraform a tool of choice for many DevOps engineers. Also, using a single tool to manage multiple vendors is a great advantage.

Let’s try to create a file called hello.txt using Terraform.

Install

Download it from here

https://www.terraform.io/downloads.html

Make it executable and copy to user path so can run from anywhere.

chmod +x ./terraform
sudo mv ./terraform /usr/local/bin

verify

Creating First Project

Create main.tf in your working space with following content.

provider “local” { version = “~> 1.4” }
resource “local_file” “hello” {
     content = “hello, terraform”
     filename = “hello.txt”
}

Init

initialize it with the init command, Terraform scans our project files and downloads any required provider

terraform init

plan

plan command verify what actions Terraform will perform to create our resources. This step works pretty much as the “dry run” feature available in other build systems.

terraform plan

Apply

We can now proceed to actual resource creation using the apply command:

terraform apply

Verify

You will notice new file created as hello.txt

Out put is

Congratulations

We have completed the hello world.

Let’s dig in further,

configuration drift

If we try to apply the apply again terraform will iform no changes.

Let’s edit the hello.txt and check again,

echo foo > hello.txt

Now try plan again

terraform plan

This is called configuration drift, Sometimes a resource exists, but someone may have changed one of its attributes.

Let’s do a apply again

terraform apply -auto-approve

Terraform will recreate the file now. you can view the hello.txt is updated with the original.

Core Concepts

Providers: exposes a set of resource types using a common abstraction, hence it pretty much hides details of how to create, modify, and destroy a resource .

Resources: is anything that can be a target for CRUD operations.

Data Sources: Data sources work pretty much as “read-only” resources, usually used to fetch parameters needed to create other resources.

State: is a file that stores all details about resources. The primary purpose is to provide information about already existing resources, so when we modify our resource definitions, Terraform can figure out what it needs to do. they may contain sensitive information like passwords used to create a database, private keys, and so on.

Modules: Terraform modules allows us to reuse resource definitions across multiple projects or simply have a better organization in a single project. A module is a directory containing resource definition files.

Input Variables:

variable "myvar" {
  type = string
  default = "Some Value"
  description = "MyVar description"
}

Output Values: a module’s consumer has no access to any resources created within the module, so module can define output blocks that expose a subset of the created resources:

Local Variables: Local variables work like standard variables, and their scope is limited to the module where they’re declared.

Workspaces: Terraform workspaces allow us to keep multiple state files for the same project. For instance, we can have one workspace for each target environment — DEV, QA, PROD . workspaces are an excellent choice to manage multiple versions using git.

$