Introduction:
In this blog, we will see how to manage resources using Terraform. we will create an AWS instance, examine a state file, and then manipulate resources to observe how vital the state is to your Terraform operations.
Terraform stores information about your infrastructure in a state file. This state file keeps track of resources created by your configuration and maps them to real-world resources.
Task 1:
Create a Terraform configuration file to define a resource of the AWS EC2 instance
To define resources in terraform we will use resource with resource type and resource name.
In this example, we are defining an AWS ec2 instance with resource type aws_instance with the name my_instance. Ami and instance_type are also required for the configuration of the 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.
Step 1: terraform init
Terraform init command initializes a Terraform working directory by downloading and installing any required plugins and dependencies. It should be run before any other Terraform commands.
Step 2: terraform plan
This command shows you an execution plan for the infrastructure changes.
Step 3: terraform apply
Terraform apply command applies the changes defined in the configuration to your infrastructure. It creates or updates the resources according to the configuration, and it also prompts you to confirm the changes before applying them.
Step 4: terraform destroy
Terraform destroy command will destroy all the resources created by Terraform in the current working directory. It is a useful command for tearing down your infrastructure when you no longer need it.
Step 5 : terraform validate
The validate command performs precisely what its name implies. It ensures that the code is internally coherent and examines it for syntax mistakes. Only the configuration files (*.tf) in the active working directory are examined.
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.
Provisioners in Terraform are used to execute scripts or other actions on a local or remote machine as part of the resource creation or destruction process. Here's an example of using a terra_prov provisioner to run a script on an AWS EC2 instance:
Provisioning mainly deals with configuration activities that happen after the resource is created. It may involve some file operations, executing CLI commands, or even executing the script. Once the resource is successfully initialized, it is ready to accept connections.
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.
Lifecycle arguments help control the flow of your Terraform operations by creating custom rules for resource creation and destruction.
Controlling the flow of Terraform operations is possible using the lifecycle meta-argument. This is useful in scenarios when you need to protect items from getting changed or destroyed.
There are several attributes available for use with the lifecycle meta-argument:
create_before_destroy:
When Terraform determines it needs to destroy an object and recreate it, the normal behaviour will create the new object after the existing one is destroyed. Using this attribute will create the new object first and then destroy the old one. This can help reduce downtime.
prevent_destroy
This lifecycle option prevents Terraform from accidentally removing critical resources. This is useful to avoid downtime when a change would result in the destruction and recreation of resource. This block should be used only when necessary as it will make certain configuration changes impossible.
ignore_changes:
This lifecycle option can be useful when attributes of a resource are updated outside of Terraform, for example, when an Aws Policy automatically applies tags.
replace_triggered_by:
Lastly, this option forces the replacement of the resource when the specified resource is changed. This may be useful when the resource references another resource and needs to be replaced when this happens, for example, when a resource id changes.
Thank you for reading!!!!!!!!