Terraform - Providers

What Are the Providers in Terraform?

A provider in Terraform is a plugin that enables interaction with an API. This includes Cloud
providers and Software-as-a-service providers. The providers are specified in the Terraform
configuration code. They tell Terraform which services it needs to interact with.
There are hundreds of available providers that can be used with Terraform, making it a hugely
versatile tool. A lot of Terraform’s popularity stems from the fact that it is platform agnostic
and can be used so widely, as opposed to languages that may be platform-specific, such as
Microsoft Azure ARM templates or Bicep (which interact with the Azure API only).
Once a provider is specified, each provider makes a list of resources and data types available
for use in the Terraform code. These are listed in the documentation which can be found on
the Terraform Registry.
Each provider is released independently from Terraform itself with each version providing
additional features and bug fixes. Each provider has its own release cadence. Providers are
usually managed by either Hashicorp, the dedicated teams from the company making the
provider (e.g. Mongo for the mongodb provider), or by community groups, users, and
volunteers with an interest in the product or platform the provider utilizes.
• Providers maintained by Hashicorp are marked as ‘official’ on the documentation
pages.
• Providers marked as ‘verified’ are owned by official third-party technology vendors.
Vendors are also a member of the HashiCorp Technology Partner Program.
• Providers marked as ‘community’ are published by members or groups in the Terraform
community.
You can develop a provider in the unlikely event that it doesn’t already exist for the
infrastructure you are trying to provision using Terraform. Or you can develop it for your
product. Providers are written in Go and utilize the Terraform Plugin SDK.

Terraform providers are downloaded and installed during the terraform init stage of the
Terraform workflow. They can be downloaded from the public registry, or a local registry or
mirror. The provider is downloaded, when it’s not present in the .terraform subdirectory. When
it is already present, it is not downloaded again. The version number is also checked. Changing
the version number in the configuration files would cause that version of the provider to be
downloaded.
To save bandwidth and speed up the runtime, however, the use of an optional plugin cache
can be specified using plugin_cache_dir in the CLI configuration file which configures per
user CLI behaviors (terraform.rc or .terraformrc).
E.g.

Provider Configuration
Provider configurations should be declared in the root module of your Terraform project. They
can be declared in any .tf file. I would recommend either putting them in the main.tf, creating
a providers.tf file specifically for the Providers and nothing else, or alternatively
a versions.tf file which would include the required_providers block and specify the Terraform
version. Any child modules receive their provider configuration from the root module.
Providers are configured using a provider’s block. Some providers require certain information
to be configured such as endpoint URLs or cloud regions.
What is the Terraform lock file?
The Terraform lockfile as already mentioned is a file used by Terraform to track the desired
state of your infrastructure. It’s almost equivalent to the package-lock.json file in the realm of
npm as a package manager. Let's delve a bit deeper: Each Terraform project involves
dependencies on code components that extend beyond its immediate codebase. These

external dependencies hinge on Terraform Providers and Modules, which might reside outside
of the project. Before Terraform 0.14, there was any way to manage the versions of these
dependencies. But later (=> 0.14) the Dependency Lock File was introduced for this purpose.
This file .terraform.lock.hcl is generated by Terraform when you run the terraform
init command. This file serves as a reference point across all executions, aiding in the
evaluation of compatible dependencies with the current configuration. It is used to lock the
versions of the provider plugins and modules being used in your Terraform configuration,
ensuring that subsequent runs of terraform apply or terraform plan use the same versions. This,
in turn, facilitates the meticulous selection of fitting dependency versions for seamless
utilization.

How does it work?

Whenever the terraform init command is executed, and the Terraform Lock File is generated
automatically if absent. In cases where the file already exists, the command will update it with
the most current selections of dependency versions. During the initialization, Terraform installs
all of the Terraform Providers needed for the project code. It considers both the specified
version constraints and the version selection stored in the dependency lock file stored within
the dependency lock file. In scenarios where the lock file doesn’t contain a version record for
a provider, terraform will opt for the latest compatible version based on the defined constraints
and subsequently update the lock file to reflect this chosen version.
Aside from the selected version which is persisted in the file, all of the version constraints that
Terraform considered when making this selection are also stored including a number of other
checksums that are all considered to be valid for packages implementing the selected version
of this provider on different platforms.

Versioning the Terraform lockfile

It is generally a good practice to version control the .terraform.lock.hcl file especially in a
CI/CD pipeline when deploying Terraform across multiple environments. As already
mentioned, upon running terraform init the command, the lock file is updated with the selected
version. Subsequently, when you re-run the terraform init command again, it will only go
through the process of determining the compatible versions of dependencies for any new
dependencies added to the project since the previous run. Uploading the Dependency
Lock File (.terraform.lock.hcl) to version control will result in the enforcing installation with
the specified dependency versions outlined in the file. This could potentially cause version
incompatibility issues as new dependencies have been added. The way to get around this kind
of situation is to force the selected dependency versions to be updated by using the -
upgrade attribute flag as in the following commandterraform init -upgrade , or manually
confirm all compatible versions and update the version in your provider.tf file. This ensures
that anyone else who checks out your code will use the same versions of provider plugins and
modules, providing a consistent and reproducible environment for managing your
infrastructure with Terraform. It’s recommended not to manually edit this file as this could
cause irreversible issues to your infrastructure.