Terraform : AWS : Terraform on AWS with SRE & IaC DevOps | Section 3 : Terraform Settings | Providers and Resources

 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


17. Step-01: Introduction to Terraform Settings, Providers and Resources :

Terraform Fundamental blocks .


The above is called the Basic / Fundamental Block of terraform . Before 0.14 version we didn't have this terraform block . In terraform you are going to have a root module and a child module. 

Terraform Block : is a special block that is used to configure some behaviors in terraform 

  • What is the required terraform version that we are suppose to use. 


Provider configuration belong to root module. In terraform you are going to have something called the root module and a child module. We will also see the child module concept which are nothing but re-usable code that you are going to call and provision to your infrastructure . 

You can create post resource post creation actions using provisioners

18. Step-02: Terraform Settings Block Introduction

 



 

You can call it by three names . You can call it terraform settings block . 

Within a Terraform Block only constant variable can be used. 





If you do not define the backend block for terraform.tfstate file will be stored in the local directory 


Every terraform project will have its state information.  You can call it terrform.tsstate file or the terraform configuration information whatever is stored inside that file . This is nothing but whatever live information that you have provisioned using terraform. And this file - where it needs to be located is stated in Backend. If nothing is defined in the Backend block it will be stored in the root directory 

And there are many experimental language that we don't need to worry about. 


We will go to the GitHub and shall set up the configuration block. 

~> 0.14

Any changes to the right most update happens 


 

This means that whatever version terraform CLI version you have installed on your system. by explicitly mentioning the version you are locking the terraform version and of you do not have the same version in your respective system then it is not going to provision resources . update or destroy your infrastructure.

This means you are doing a version locking for your terraform. 

 Yo

 

 


Visual Studio Ctrl + Space  and you will have all the top level blocks

The terraform block .

We will see the version control.





required_providers

aws is an argument inside the required_provider 

 

Change the name to aws
 


We need to under the difference between Block and the Argument .

19. Step-03: Part-1: Understand and Implement Terraform Provider Block

Whenever you say terraform init it will download the provide that you have defined here in the block .

$ terraform init


Every resource type is implemented by a Provider . That's is the reason it is called the heart of Terraform . With out provider there is no terraform at all. 

if you go to terraform registry you can download your respective terraform provider it will communicate to the AWS APIs and it will perform the respective action that you specified through the terraform configuration file .

https://registry.terraform.io/browse/providers

 




root module is where you define your providers and child module is where you use and re-use your code .


Important thing - which type of providers we are suppose to use. You need to decide your provider based on the "Provider Badges" . Whether they are official or archived or YAML Templates


For us AWS is provided by official providers .

In addition to registry you need to know something about modules.


And whenever you use Module you will have official and verified can be used .

By using this re-usable modules our things will get simplified . But if you are going to take a one that bugs , in production then you might encounter production issues .

Whereever you find modules that are not official and verified modified by Harshycorp then do not use them in production .

20. Step-04: Part-2: Implement Provider Block


In order for the AWS provider connectivity you have to authenticate your self . You can either provide a static key as below. 


$ terraform init 

This initialize the backend which is nothing but your local backend , Then it initializes the provider plugin  and then it has downloaded the plugins .

You will notice a new folder .terraform folder

In order to connect to aws console in order to communicate with the AWS you can use a static key .



Go to IAM go to that respective user , go to security credentials and provide the access key static key . Though this is not the right way for storing the stuff  .

The other way by installing the AWS CLI and provide our secret access key and then secret key , both of them

 



If you have created a terraform user then you will give that profile here, if it is default profile you will give the default profile. 

If you are not using a default profile and if you have created an IAM user example : terraform-user , mention it here to use that particular credentials.

default it automatically taken .

21. Step-05: Part-1: Create EC2 Instance Resource in Terraform

These are top level blocks, you can also have blocks inside blocks . Provisioner is an example of block inside block .

  • for resource we have two block label. 
  • for variable we have one block label.

 The first label is called the "resource_type" . 


This should be unique in the entire module


We are going to install a sample webserver by passing the user data for this instance ,

22. Step-06: Part-2: Create EC2 Instance Resource in Terraform

 Before updating instance with

 https://github.com/stacksimplify/terraform-on-aws-ec2/blob/main/05-Terraform-Loops-MetaArguments-SplatOperator/05-02-MetaArgument-for_each/terraform-manifests/app1-install.sh

Let see what is there is app1.install.sh which will be added to "User Data"

#! /bin/bash
# Instance Identity Metadata Reference - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-identity-documents.html
sudo yum update -y
sudo yum install -y httpd
sudo systemctl enable httpd
sudo service httpd start  
sudo echo '<h1>Welcome to StackSimplify - APP-1</h1>' | sudo tee /var/www/html/index.html
sudo mkdir /var/www/html/app1
sudo echo '<!DOCTYPE html> <html> <body style="background-color:rgb(250, 210, 210);"> <h1>Welcome to Stack Simplify - APP-1</h1> <p>Terraform Demo</p> <p>Application Version: V1</p> </body></html>' | sudo tee /var/www/html/app1/index.html
sudo curl http://169.254.169.254/latest/dynamic/instance-identity/document -o /var/www/html/app1/metadata.html

 In terraform there is a "file" function , which will allow you to read the content from a respective file.



This completes the version of  c1.versions.tf & c1.ec2.instance.tf

Argument references are input for this resource, attribute reference are output for this resource , are outputs that we are going to take from that resource and use them in another resources /or in a child module or somewhere like in another subject project configuration .

We will learn about the import commands when we are learning about the terraform state file.

 


 
If you want to run the terraform init one more time .It will create the .terraform folder and the dependency lock file .terraform.lock.hcl file.

 Lets run the second command .

$ terraform validate

Next

$ terraform plan

Next

$ terraform apply

or 

$ terraform apply -auto-approve

 

# Terraform Settings Block
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      #version = "~> 3.21" # Optional but recommended in production
    }
  }
}

# Provider Bloc
provider "aws" {
  profile = "default" # AWS Credentials Profile configured on your local desktop terminal  $HOME/.aws/credentials
  region  = "ap-south-1"
}

# Resource Block
resource "aws_instance" "ec2demo" {
  ami           = "ami-04893cdb768d0f9ee" # Amazon Linux in us-east-1, update as per your region
  instance_type = "t2.micro"
  tags = {
    "Name" = "Gorilla"
  }
}



In terraform we will have something called file function which will allow you to read the content from that respective file.

 https://www.terraform.io/language/functions/file

 

resource "aws_instance" "ec2_instance" {
    ami = "ami-04893cdb768d0f9ee"
    instance_type = "t2.micro"
    user_data = file("${path.module}/app1-install.sh")
    tags = {
      "Name" = "Gorilla"
    }
}

 file module     user_data = "file("${path.module}/app1-install.sh")"

 Sreejith Tested this out .

I tried creating to instances

resource "aws_instance" "ec2_instance" {
    ami = "ami-04893cdb768d0f9ee"
    instance_type = "t2.micro"
    user_data = file("${path.module}/app1-install.sh")
    tags = {
      "Name" = "Gorilla"
    }
}

resource "aws_instance" "ec2_instance1" {
    ami = "ami-04893cdb768d0f9ee"
    instance_type = "t2.micro"
    user_data = file("${path.module}/app1-install.sh")
    tags = {
      "Name" = "Godzilla"
    }
}

 This indeed created two EC2 instances as I wanted. 


These are the apps we have deployed through app1-install.sh through our code.

# Access index.html
http://<PUBLIC-IP>/index.html
http://<PUBLIC-IP>/app1/index.html

# Access metadata.html
http://<PUBLIC-IP>/app1/metadata.html

Open up the web browser  : And we were not able to open the site ,this was due to the network security

On Amazon Console .

security group, once the inbound rules for applied for http 80 from anywhere we were able to access the site .



The second Server was also tried out both has the default security group and one inbound configuration was enough to bring both of them .

So all the three are working 

# Access index.html
http://<PUBLIC-IP>/index.html
http://<PUBLIC-IP>/app1/index.html

# Access metadata.html
http://<PUBLIC-IP>/app1/metadata.html


You can also get the metadata of your application by typing "metadata.html at the end

 http://13.232.153.114/app1/metadata.html

 

23. Step-07: Terraform State Basics

 

Terraform.state file is nothing but the underlining database for terraform actions whatever it has performed .

Whenever you run the "terraform apply" for the first time  and when your infrastructure provisioning is successful .  Your terraformtfstate.tf file is created .

This has your real infrastructure information , whatever is present on the cloud the real infrastructure information is store in this file. if this file is deleted this will remain a non-terraformed managed infrastructure.





24. Step-08: Clean-Up


$ terrform plan -destroy    -- this will print your destroy plan

And to destroy the infrastructure

$ terraform destroy

or

$ terraform destroy -auto-approve







Comments

Popular posts from this blog

Terraform : AWS : Terraform on AWS with SRE & IaC DevOps | Section 2 : Terraform basics

Terraform : AWS : Terraform on AWS | Section 4: Terraform Input Variables and Datasources

Terraform VPC - on AWS : Three tier architecture design