Table of Contents
What is Infrastructure as Code(IAC)
Iaac Advantages
Day 1
Configure Aws and Terraform on your machine.
Launch an EC2 instance using terraform
Go to your terminal
aws configure
AWS Access Key ID [****************ZK66]: ABAA****************
AWS Secret Access Key [****************Uz5B]: 7/rSOSPL*************
Default region name [eu-central-1]:
Default output format [None]: json
Enter your access key Id from the IAM user from AWS account.
Alternatively you can create an IAM user specially for Terraform
I will now proceed with ec2 instance creation
Overview of steps
Create a directory for your Terraform project and create a Terraform configuration file (usually named main.tf) in that directory. In this file, you define the AWS provider and resources you want to create. Here's a basic example:
provider "aws" {
region = "us-east-1" # Set your desired AWS region
}
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0" # Specify an appropriate AMI ID
instance_type = "t2.micro"
}
Initialize Terraform**
In your terminal, navigate to the directory containing your Terraform configuration files and run:
terraform init
This command initializes the Terraform working directory, downloading any necessary provider plugins.
Apply the Configuration
Run the following command to create the AWS resources defined in your Terraform configuration:
terraform apply
Terraform will display a plan of the changes it's going to make. Review the plan and type "yes" when prompted to apply it.
Verify Resources
After Terraform completes the provisioning process, you can verify the resources created in the AWS Management Console or by using AWS CLI commands.
Destroy Resources
If you want to remove the resources created by Terraform, you can use the following command:
terraform destroy
Be cautious when using terraform destroy as it will delete resources as specified in your Terraform configuration.
terraform plan
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Error: Retrieving AWS account details: validating provider credentials: retrieving caller identity from STS: operation error STS: GetCallerIdentity, https response error StatusCode: 403, RequestID: 49a569f9-f1e1-4145-b20f-2785f971d4b7, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
│
│ with provider["registry.terraform.io/hashicorp/aws"],
│ on main.tf line 1, in provider "aws":
│ 1: provider "aws" {
To solve this, Check the files config and credentials at the following path
cd ~/.aws
Check the default access key and the one you tried to configure your project with.
In my case I deleted the files and created a new key in the AWS Console. Once the key was created in AWS re-executed the aws configure command with the new key
Continuing with the terraform apply command
This time I got the issue with VPC does not exist. This is because I deleted my Default VPC accidentally while cleaning the resources on my aws console.
The steps that I took to check for the VPC are as follows:
- Check which Availability Zone you have selected in the terraform file. 2: check the default VPC for the AZ. By Default a default VPC is always created by AWS for each of the AZs. 3: Make sure the availability zones match.
In my case I had to create a default VPC in my current AZ.
Coming back to the terraform console. I re-executed the terraform apply.
This time it was successful. I logged on the my AWS console and checked the status of the instance creation and health of the instance.
Day 02 - Providers, Multi Region, Multi Cloud, Variables & Conditions
Providers
A Terraform provider is a plugin that acts as an interface between Terraform and an external API, enabling Terraform to manage resources on a wide range of platforms—including cloud providers, SaaS products, and other infrastructure services.
Providers act as the bridge between Terraform's declarative configuration language and the actual infrastructure services you want to manage.
How Providers Work
When you run Terraform commands, the process typically follows this flow:
The Terraform core reads your configuration files and identifies which providers are needed based on the resource types you've declared.
During the initialization phase (terraform init), Terraform downloads the required provider plugins from the Terraform Registry or other configured sources. These plugins are executable binaries that implement a standardized interface for communicating with Terraform core.
During planning and execution, Terraform core communicates with provider plugins through a well-defined protocol. The provider receives requests from Terraform core, translates them into appropriate API calls for the target service, and returns the results back to Terraform core.
Types of Providers
Official Providers are maintained by HashiCorp and cover major cloud platforms like AWS, Azure, Google Cloud, and foundational services like random number generation or local file management. These providers receive regular updates and are thoroughly tested.
Partner Providers are maintained by technology partners in collaboration with HashiCorp. These cover popular services like Datadog, New Relic, or PagerDuty, and are verified for quality and compatibility.
Community Providers are developed and maintained by the broader Terraform community. These can range from niche services to experimental integrations, and their quality and maintenance levels vary.
Private Providers can be developed internally by organizations for their proprietary systems or specialized infrastructure needs.
Note: Consider using the Private providers when you are actively contributing to them. Otherwise, it is recommended to use the official ones
Provider Configuration
Providers typically require configuration to authenticate and connect to their respective services. This configuration is usually specified in a provider block within your Terraform files:
provider "aws" {
region = "us-west-2"
access_key = var.aws_access_key
secret_key = var.aws_secret_key
}
Many providers support multiple authentication methods, environment variables, and configuration options to accommodate different deployment scenarios and security requirements.
I have the access keys configured for AWS and I am using aws cli for terraform. Therefore I omitted typing the access key and secret in my main.tf file.
Here is an example of how to use the aws provider in a Terraform configuration:
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
In this example, I have first defined the aws provider with the specified region as us-east-1. In the next line I have defined the aws_instance resource with the required AMI ID and the instance type.
When Terraform runs, it will first install the aws provider. Then, it will use the aws provider to create the virtual machine.
Different ways to configure providers in terraform
In the root module
This is the most common way to configure providers. The provider configuration block is placed in the root module of the Terraform configuration. This makes the provider configuration available to all the resources in the configuration.
provider "aws" {
region = "us-east-1"
}
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
In a child module
module "aws_vpc" {
source = "./aws_vpc"
providers = {
aws = aws.us-west-2
}
}
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
depends_on = [module.aws_vpc]
}
In the required_providers block
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
# Configure the AWS Provider
provider "aws" {
region = "us-east-1"
}
# Create an ec2 Instance
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
Considerations - when to use which provider configuration
If you are only using a single provider, then configuring it in the root module is the simplest option.
If you are using multiple providers, or if you want to reuse the same provider configuration in multiple resources, then configuring it in a child module is a good option.
If you want to make sure that a specific provider version is used, then configuring it in the required_providers block is the best option.
Top comments (0)