Without a provider, Terraform is useless.
Welcome to day 2 of the #30daysofawsterraform challenge!
By the end of this post, you'll have an understanding of the most important conponent of terraform as an IaC tool, the provider.
If you already know the provider I guarantee you'll learn at least one new angle today, or provide me with one in the comments.
So ease in, let's dive.
Concepts to be aware of:
Registry: more common as a place were records a kept. In this case, we refer to a registry as a central location were providers and modules (more on modules soon) are published, versioned and downloaded.
Provider: plugins that allow Terraform to interact with target APIs: cloud platforms, Kubernetes, Docker, Saas/Paas APIs, etc. Each provider is versioned separately from Terraform Core. For AWS, we use the hashicorp/aws provider.
Terraform Core: The Terraform binary that processes .tf files, manages state and orchestrates the workflow.
A provider interpretes the .tf files for the target API. For example, when you deploy an object storage, whether clicking through the console, or using the CLI, you are ultimately talking to a cloud provider's APIs. Terraform lets you to declare the resources you want, and the provider communicates with the API to provision them.
Because Terraform Core and providers are developed by different teams and versioned separately, version compatibility is important for stability, reproducibility, and predictable behavior.
To ensure consistent versioning, version constraints are used:
-
= 1.2.3- exact version -
>= 1.2- greater than or equal to -
<= 1.2- less than or equal to -
~> 1.2- pessimistic constraint (allow patch releases) -
>= 1.2, < 2.0- Range constraint (allow a range of versions)
Basic AWS Provider Setup
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
}
}
provider "aws" {
region = "eu-west-2"
}
To know how these configuration blocks are structured, always refer to the provider's documentation on the registry: registry.terraform.io/providers/hashicorp/aws.
I love to treat documentation as the single source of truth and in some situations, the direct code, because LLM's are not always trained with the latest update. I know you can ask it to search the internet but reading documentation is a good skill to have you know.
Yes, you could have multiple providers in single Terraform configuration. As seen in this example, the random provider to generate random values is used with the aws provider.
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
random = {
source = "hashicorp/random"
version = "~> 3.1"
}
}
}
After writing your terraform files, you run :
terraform init
init downloads providers from the registry, installs plugins, and prepares Terraform to interact with your configured APIs. Authentication happens during this process too.
To experience this hands-on, try the AWS Terraform tutorial here: get started
Hey, you can get the juice directly from the source
It feels great to finally understand how Terraform performs its magic behind the scenes.
One quick tip I use for AWS authentication is adding a profile field to provider block of the .tf file and it's value is the name of my profile. Your AWS credentials live in ~/.aws/config (assumming you use a linux OS), and you can login to and store your credentials with a named profile using this command
aws login --profile <profile-name>
Terraform respects that configuration too.
Good luck exploring Terraform and building your infrastructure with code!
Tomorrow, we’ll explore the rest of the Terraform workflow. We’ll look at the plan command, create actual resources, and understand how Terraform decides what to provision.
Cheers! And see you tomorrow.
Top comments (1)
Hey.... thanks for reading to the end.
Did you gain anything new?
What is interesting to read?