SAFIA KHATOON's Blog

Day 3 : TWS Terra Week CHALLENGE

Day 3 : TWS Terra Week CHALLENGE

SAFIA KHATOON's photo
SAFIA KHATOON
·

6 min read

Task 1:

Create a Terraform configuration file to define a resource of AWS EC2 instance, Azure storage account, Google Compute Engine, etc. (anyone)

Here's an example of a Terraform configuration file that defines an AWS EC2 instance:

provider "aws" {
  access_key = "<YOUR_AWS_ACCESS_KEY>"
  secret_access_key = "<YOUR_AWS_SECRET_ACCESS_KEY>"
  region = "us-east-1"
}

resource "aws_instance" "example" {
  ami = "ami-0c94855ba95c71c99"  # Replace with your desired AMI ID
  instance_type = "t2.micro"
  key_name = "my-key-pair"
  subnet_id = "subnet-12345678"  # Replace with your desired subnet ID

  tags = {
    Name = "example-instance"
  }
}

In this example, we're using the aws provider to create an EC2 instance on AWS. Here's a breakdown of the configuration:

  1. The provider block specifies the AWS provider and requires you to replace <YOUR_AWS_ACCESS_KEY> and <YOUR_AWS_SECRET_ACCESS_KEY> with your own AWS access key and secret access key.

  2. The resource block defines an EC2 instance with the resource type aws_instance. You can name this resource whatever you like by changing example to a name of your choice.

  3. Inside the aws_instance block, you can specify various properties of the EC2 instance, such as the AMI (Amazon Machine Image), instance type, key pair, and subnet ID.

  4. The tags block allows you to add tags to the EC2 instance for better organization and identification.

Remember to have Terraform installed and run terraform init to initialize the project before using terraform apply to create the EC2 instance.

Task 2 :

Check state files before running the plan and apply commands & Use validate command to validate your tf file for errors and provide the Output generated by each command.

Certainly! Before running the plan and apply commands in Terraform, you can check the state files to ensure that the desired changes are reflected correctly. The validate command can be used to validate your Terraform configuration file for syntax errors and potential problems. Here's an example:

  1. Checking State Files:

    • To check the state files, you can use the terraform show command. This command displays the current state of the infrastructure managed by Terraform.

        terraform show

    • The output will provide information about the resources that have been created, modified, or deleted. It helps you verify that the current state matches your expectations.

  2. Using the validate command:

    • The validate command checks the syntax and configuration of your Terraform files without making any changes to your infrastructure.

        terraform validate

    • The output of the validate command will indicate whether there are any syntax errors or problems with your configuration. If everything is correct, you'll see a success message.

        Success! The configuration is valid.

      If there are errors, they will be displayed along with specific error messages, allowing you to identify and correct them.

        Error: Missing required argument

  on main.tf line 5, in resource "aws_instance" "example":
    5:   instance_type = "t2.micro"

  An argument named "instance_type" is required to be set.

It's recommended to run the validate command before executing plan or apply to catch any potential errors or misconfigurations early on. The terraform show command helps you understand the current state of your infrastructure.

Remember, it's always a good practice to regularly review and validate your Terraform configuration files to ensure their correctness and consistency.

Task 3:

Add a provisioner to the configuration file to configure the resource after it is created and use Terraform commands to apply for changes and destroy to remove resources.

Certainly! In Terraform, you can use provisioners to configure resources after they are created. Provisioners are a way to execute scripts or commands on the provisioned resources. Here's an example of adding a provisioner to the previous AWS EC2 instance configuration:

provider "aws" {
  access_key = "<YOUR_AWS_ACCESS_KEY>"
  secret_access_key = "<YOUR_AWS_SECRET_ACCESS_KEY>"
  region = "us-east-1"
}

resource "aws_instance" "example" {
  ami = "ami-0c94855ba95c71c99"  # Replace with your desired AMI ID
  instance_type = "t2.micro"
  key_name = "my-key-pair"
  subnet_id = "subnet-12345678"  # Replace with your desired subnet ID

  tags = {
    Name = "example-instance"
  }

  provisioner "remote-exec" {
    inline = [
      "echo 'Hello, World!'",
      "echo 'This is a provisioner example.'"
    ]
  }
}

In this example, we've added a provisioner of type remote-exec to the aws_instance resource. Here's a breakdown of the changes:

  1. After the tags block, we've added a provisioner block to define the provisioner.

  2. The remote-exec provisioner type executes commands remotely on the newly created EC2 instance.

  3. Inside the remote-exec block, the inline argument is used to specify the commands that will be executed on the EC2 instance. In this case, we're echoing two messages.

Once you have added the provisioner, you can use Terraform commands to manage your infrastructure:

  • terraform init: Initializes the Terraform project.

  • terraform plan: Generates an execution plan showing the proposed changes to the infrastructure.

  • terraform apply: Applies the changes defined in the Terraform configuration and provisions the resources. This includes the creation of the EC2 instance and the execution of the provisioner commands.

  • terraform destroy: Destroys all the resources created by Terraform. This will remove the EC2 instance and any associated resources.

Remember to replace <YOUR_AWS_ACCESS_KEY> and <YOUR_AWS_SECRET_ACCESS_KEY> with your own AWS access key and secret access key.

By using provisioners, you can configure resources to run additional commands or scripts after they are created, enabling you to customize and set up your infrastructure according to your requirements.

Task 4:

Add lifecycle management configurations to the configuration file to control the creation, modification, and deletion of the resource and use Terraform commands to apply the changes.

Certainly! In Terraform, you can use lifecycle management configurations to control the creation, modification, and deletion of resources. These configurations allow you to specify certain behaviors and conditions for your resources. Here's an example of adding lifecycle management configurations to the previous AWS EC2 instance configuration:

provider "aws" {
  access_key = "<YOUR_AWS_ACCESS_KEY>"
  secret_access_key = "<YOUR_AWS_SECRET_ACCESS_KEY>"
  region = "us-east-1"
}

resource "aws_instance" "example" {
  ami = "ami-0c94855ba95c71c99"  # Replace with your desired AMI ID
  instance_type = "t2.micro"
  key_name = "my-key-pair"
  subnet_id = "subnet-12345678"  # Replace with your desired subnet ID

  tags = {
    Name = "example-instance"
  }

  lifecycle {
    create_before_destroy = true
    ignore_changes = [
      tags
    ]
  }
}

In this example, we've added a lifecycle block to the aws_instance resource. Here's a breakdown of the lifecycle management configurations:

  1. The create_before_destroy parameter is set to true, which means that when changes are applied, the new resource will be created before the old resource is destroyed. This ensures that there is no downtime during the update process.

  2. The ignore_changes parameter is used to specify which attributes should be ignored during updates. In this case, we're ignoring changes to the tags attribute. This means that if the tags attribute is modified, Terraform will not recreate the resource.

Once you have added the lifecycle management configurations, you can use Terraform commands to manage your infrastructure:

  • terraform init: Initializes the Terraform project.

  • terraform plan: Generates an execution plan showing the proposed changes to the infrastructure.

  • terraform apply: Applies the changes defined in the Terraform configuration and provisions the resources. The lifecycle configurations will control the creation, modification, and deletion of the resource according to the specified behavior.

  • terraform destroy: Destroys all the resources created by Terraform. This will remove the EC2 instance and any associated resources.

Remember to replace <YOUR_AWS_ACCESS_KEY> and <YOUR_AWS_SECRET_ACCESS_KEY> with your own AWS access key and secret access key.

By using lifecycle management configurations, you can define how Terraform handles the creation, modification, and deletion of resources, allowing you to have more control over the lifecycle of your infrastructure.

In the hands of a DevOps engineer, Terraform is not just a tool; it's the brush that paints the picture of a perfectly orchestrated infrastructure, bringing harmony to the world of DevOps🎨🌟

Happy Learning🎉🚀

#TWSTerraweekchallengeTrainWithShubhamTerraform