A beginner's guide to Terraform with AWS.

Terraform allows you to deploy connected infrastructure components across a wide range of different providers. It is an open source** Infrastructure as Code** tool created by Hashicorp.

Users define and provision cloud infrastructure using a declarative configuration language known as Hashicorp Configuration Language(HCL).

A provider can be anything in the realm of Infrastructure as a service,** Platform as a Service** or** Software as Service**.

These are some examples of providers in Terraform:

Azure

Google Cloud

AWS

Github

Using configuration files called templates, you can write code which leverages the tools and resources that are specific to a particular provider.

Terraform is able to achieve this using provider plugins that are written specifically for each provider's API.

Plugins are responsible for taking terraform actions and translating these actions into API calls that create, read, update, or delete(CRUD) provider resources.

Here is an example template file:

    provider     "aws" {
            region = "us-east-1"
            version = "1.2"

     resource "aws_S3_bucket" "my_bucket" {
          bucket       = "my-bucket-us-east1"
          region        = "us-east-1"
          acl              = "private"
     }
  }

In this example, we identify and configure AWS as the provider. We also included the Terraform version. We then specify an S3 bucket resource.

As you can see above, the region where the bucket is located is also specified. Another configuration is that the bucket is private.

Terraform resources(the S3 bucket) are the components of your infrastructure and they always belong to a specific provider.

Managing resources.

You can ask Terraform to preview changes that it plans to make to your infrastructure. You will use this command :

                Terraform plan

When Terraform creates a plan it

Reads the current state of any already existing remote objects to make sure that the Terraform state is up to date.
Compare the current configuration to the prior state noting any differences.
Proposes a set of change actions that should, if applied, make remote objects match the configuration.

Terraform State

Terraform keeps track of resource states using a state file.

A state file is in Json format and is automatically created the first time you run the apply command.

Every time you issue the apply command:

Terraform refreshes the state file,

plans what actions are needed based on the refreshed state file,

and then performs those actions.

For this reason, special care needs to be taken so that no changes are made to the running system in the short window between refreshing state and performing changes.

If you are working in a team, you could keep the state file in a shared repository and take care to coordinate the rollouts so that nobody is making concurrent changes.

Fortunately, Terraform supports remote backends for state that use storage with inbuilt locking such as Azure Storage or AWS S3.

Using one of these remote backends, the state of a running system can be changed in a way that is atomic. This is when you run the apply command, either you will secure a lock-in on the state file thus ensuring that nobody else can make changes for the duration command or you won't, meaning the command will fail because someone else is making changes.

Terraform Internals

Terraform makes use of the graph theory.

Essentially, state changes are modeled as a dependency graph and a plan is a way of traversing the graph so that every node is visited.

Terraform graphs are composed of three different types of nodes:

1 . Resource nodes

A resource node represents a single resource e.g. an s3 bucket.

2 . Provider configuration node.

A provider configuration node represents a single configuration resource provider as your account or an AWS account or resource nodes belong to a provider configuration mode.

3 . Resource metanode

Resource metanodes group together multiple resource nodes of the same type this is done because it makes the result in graphs more understandable for human beings but is not strictly necessary to solve the graph.

Working with Terraform

Terraform allows modular configuration files. This reduces the amount of duplicate code necessary and thereby enables you to build a DRY infrastructure.

A module is just a collection of resources; any directory containing terraform configuration files can be considered a module.

It is a good idea to make use of modules if you have similar setups being used in different environments. It does require a little more planning, but it massively helps the maintainability of your system as things expand as your team grows.

One example where modules are useful is if you're building a deployment pipeline where the code is promoted from one environment to another.

Another example is if you're building a highly available system that duplicate the same configuration in multiple locations for instance with Azure regions.

Terraform specifies a standard structure for modules and you should follow the structure if you want to get the most benefit out of them.

Conclusion.

Now that we know what Terraform is we will be getting our hands dirty in the upcoming tutorial. We will learn how to create AWS resources in Terraform! We create EC2 instances, VPCs, S3 buckets and so much more.

Thank you for reading this article. I hope it has been a helpful read. Please leave any questions or comments below. Don't forget to like and share the article if it helps you in any way.

Happy building!!😀

Tino's Blog