Terraform is a binary that has no clue where or what to provision. All that it does, all its buckets, all its VPCs, all its resources, would not occur at all without a provider knowing how to communicate with a particular API.
Role of Providers (The Real Terraform Workhorse):
Aws Terraform is not a creator of resources in AWS.
It is not aware of what S3 bucket is.
It is not aware of what an EC2 instance is.
It is not even aware of what VPC is.
Those definitions as well as the way to send API calls to AWS are provided by AWS provider plugin.
There are three important things that a provider does:
Deinterprets your .tf configuration.
converts it into API calls to your cloud.
Receives API responses and writes state in Terraform.
Explorers are in between your Terracode and the AWS API.
Terraform Provider AWS APIs.
What developers are used to disregarding was pointed out:
Always never forget to go through provider documentation. Not blogs, not memory, not assumptions.Terraform evolves, AWS evolves, Resources are updated, depreciated, renamed or version-locked.
The actual block of configuration that is in use is on registry.terraform.io/providers/hashicorp/aws, not in the outdated tutorials or isolated Repos on GitHub.
I today had to practice pulling configuration blocks out of the docs as opposed to guessing. This immediately minimizes errors and version conflict.
Provider Versioning:
Providers are versioned on their own and this means:
Terraform Core can be v1.9.x
AWS provider can be v5.x, v6.x
Complete differences are allowed amongst other providers.
Unless you pin versions, your setup may you give silent failure on a later terraform init.
One can control your environment: Version constraints.
= 1.2.3 - exact version
~> 6.0 - allow patch/minor updates
= 1.2, < 2.0 - version range
In a modern day, I configured my AWS provider in the following way:
terraform {
requiredproviders {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
}
This is so that Terraform pulls only compatible plugins.
Identifying Terraform with AWS (Credential Setup):
I also used the AWS CLI and set credentials to authenticate appropriately.
Steps I followed:
AWS CLI was downloaded and installed.
Added a new IAM user to my AWS user.
Assigned AmazonS3FullAccess.
Created an Access Key + Secret Key.
Ran:aws configure.
Entered:
AWS Access Key.
Secret Key.
Region.
Output format.
Terraform uses credentials located in AWS CLI config, and after the authentication was performed, the provider was able to connect to AWS successfully.
Working: Terraform Init, Folder Structure and Plan.
After writing my config, I ran:
terraform init and here's what happened:
Terraform installed the plugin of the AWS provider.
Created the.terraform directory.
Lockfiles and metadata of providers stored.
Ready the working directory to work with it.
terraform plan:
Terraform made a comparison between my config and the actual state (which was nonexistent) and displayed me the specific operations that it would perform beforehand.
This was my configuration:
terraform {
requiredproviders {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
resource "awsvpc" "example" {
cidrblock = "10.0.0.0/16"
}
This gets Terraform ready to make a new VPC with provider of Amazon.
To experience this hands-on, try the AWS Terraform tutorial here:
Tomorrow we continue with the Terraform process:
Learning terraform plan in depth.
Developing real AWS resources.
Viewing the Terraform choices of things to provide.
The changes of state file during the creation of resources.
Top comments (0)