A Drift is said to have occurred when changes are made via the console, to the resources that previously set up via Terraform configuration files.
For example:
Most organizations have policies that mandatory enforce the creation of resources through terraform only. However, sometimes when a software engineer encountered an issue, and as a result, created an ec2 instances via the console. As a result, A DRIFT is experienced given that the newly created instance was not part of the terraform configuration file.
HOW DO WE RESOLVE A DRIFT?
One of the arguments that can be used to ratify the change made by the software engineer (as mentioned above) is "Terraform import".
On the part of the software engineer, the reason could be that the resources that were created via the console were critical which involve some live systems in which other integrations and users are making use of. In this situation, the engineer cannot delete and re-provision through the terraform configuration file. Should there be any deletion and re-provisioning, this could result to DOWNTIME. And to solve downtime, we leverage terraform import command.
To note: Apart from Terraform Import, another solution being worked on by Hashicorp to to solve Drift, is to allow you import the resources created in the console with actual configuration files.
For example:
By running "terraform import" The resources (causing the drift) is imported to the local environment where you're working on. This means that you do not have to write the configuration file, terraform automatically develop it.
Lets get few hands-on done on Drift:
Commands you should know.
## shows the state file in a human friendly manner
terraform show
## gives me a high level overview of what what was captured at the state file.
## It helps to show any missing resources that has been created.
Terraform state list
Terraform refresh
THE FOUR RESOURCES BEHAVIOUR IN TERRAFORM:
- Initial creation
- Update in place
- Destroy and recreate
- Destroy
STEP 1:
Establish a folder call "terraform"
STEP 2:
Within the folder, create a file "provider.tf"
terraform {
required_version = "1.3.4"
required_providers {
aws = {
source = "hashicorp/aws"
version = "4.39.0"
}
}
}
provider "aws" {
region = "us-east-1"
profile = "default"
}
STEP 3:
Create a file call "dev.tfvars"
Dev-vpc-cidr_block = "10.0.0.0/16"
Dev-vpc-instance-tenancy = "default"
Dev-subnet-1-cidr = "10.0.1.0/24"
Dev-subnet-1-availability-zone = "us-east-1a"
STEP 4:
Create a file "sg-group.tf"
resource "aws_security_group" "development-SG" {
name = "development-SG"
description = "development security Group"
vpc_id = aws_vpc.Dev-VPC.id
ingress {
description = "TLS from VPC"
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = ["::/0"]
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
ipv6_cidr_blocks = ["::/0"]
}
tags = {
Name = "allow http traffic"
}
}
STEP 5:
Create a file "variable.tf".
# dev vpc cidr block
variable "Dev-vpc-cidr_block" {
type = string
}
# dev vpc instance tenancy
variable "Dev-vpc-instance-tenancy" {
type = string
}
# dev vpc subnet1 cidr block
variable "Dev-subnet-1-cidr" {
type = string
}
# dev vpc subnet1 availability zone
variable "Dev-subnet-1-availability-zone" {
type = string
}
STEP 6:
Establish s file "Vpc-network.tf".
# Development VPC
resource "aws_vpc" "Dev-VPC" {
cidr_block = var.Dev-vpc-cidr_block
instance_tenancy = var.Dev-vpc-instance-tenancy
tags = {
Name = "Dev-VPC"
}
}
# Development Subnet 1
resource "aws_subnet" "Dev-Subnet-1" {
vpc_id = aws_vpc.Dev-VPC.id
cidr_block = var.Dev-subnet-1-cidr
availability_zone = var.Dev-subnet-1-availability-zone
tags = {
Name = "Dev-Subnet-1"
}
# Development VPC internet Gateway
resource "aws_internet_gateway" "Dev-VPC-IGW" {
vpc_id = aws_vpc.Dev-VPC.id
tags = {
Name = "Dev-VPC-IGW"
}
}
STEP 7:
"cd" into the path folder.
STEP 8:
Run the terraform commands.
-init
-validate
-plan
-Apply
STEP 9:
Run the command "terraform state list".
We "list" out resources after the command "terraform apply". Terraform list gives you an overview of what was captured in the state-file.
STEP 10:
We verified the resources that was provisioned in our console.
Below Steps indicate the changes / Drift by introducing "Tag"
Lets add "tag" to the VPC and subnet resources created in your console. At this point, we assume that the engineer literally had no idea that the resources were initially provisioned using terraform.
STEP 12:
Run "terraform plan" to detect the "drift". This tag was not specified in terraform configuration file. We have leveraged "update in place" which is a kind of terraform resource.
Terraform does not need to destroy the resources because it has the ability to go in and add the tag without changing the state of the resources.
Run "terraform refresh", lets see the action at the level of the state file. Refresh captures all the changes that were made in the console and you see that in your state file not at the level of your configuration file.
STEP 14:
Go into your "vpc-network.tf" file and pass the "env =dev" as a tag name to VPC in the configuration file.
STEP 15:
Run "terraform plan". We have added the changes in the configuration file, thats why there are no changes required.
STEP 16:
Run "terraform state" list
To destroy a specific resource run "terraform destroy --target <resources>"
We have seen how drift works !! Next slide we will deploy terraform import. Happy Learning !!! 😊
Referencing : https://www.terraform.io/
No comments:
Post a Comment