In this article, we will discuss Terraform Providers. First, we will look at the purpose of a provider in Terraform, and how they can be used and referenced. We will then look at some of the available providers with examples.
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.
plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"Plugins are always downloaded in the case of runs in Terraform Cloud or Terraform Enterprise.
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 providers block. Some providers require certain information to be configured such as endpoint URLs or cloud regions. Depending on which provider you need to use, the associated documentation should detail which settings you need to configure along with examples. To find this for each provider, click on the ‘use provider’ button top right of the documentation page.
In the example shown above for the Microsoft Azure provider azurerm , the provider source and version are specified in the required_providers section. The providers block then contains the configuration options required by the provider. For example, azurerm includes features , clientid , subscription_id , tenant_id amongst others. Usually, provider configuration options include various ways to authenticate to the platform.
Two meta-arguments can also be specified in the Providers block, version and alias . version is deprecated and should no longer be used, this should be specified in the required_providers block instead. The alias meta-argument is useful for using the same provider, but with different configuration options. Again using our azurerm example, a classic case for this is when your Terraform code needs to reference multiple subscriptions.
Different subscription_id values can be specified here, and the calling resource or module can reference the specific provider using the alias name. For example, the provider blocks could be configured like this:
provider "azurerm" {
aubscription_id = "4321-4321-4321-4321"
}
provider "azurerm" {
alias = "subscriptionA"
subscription_id = "1234-1234-1234-1234"
}The resource itself references the specific provider to access the different subscriptions:
resource "azurerm_resource_group" "rg1" {
provider = azurerm.subscriptionA
.
.
}If a child module requires a specific provider it can be referenced using the providers meta-argument.
If a provider is configured without the alias option, it is considered the default and is used by all configurations unless another provider is explicitly specified.
- Azure Active Directory
- Active Directory
- Azure Stack
- Cisco
- Cloudflare
- Checkpoint
- Datadog
- Helm
- Hashicorp product providers — Vault, Consul, Nomad, Boundary
- F5
- Palo Alto — Panos
- Spacelift
- VMWare vSphere
The Spacelift Terraform provider is open source, and its README always contains the latest available documentation. It’s also distributed as part of our Docker runner image and available through our own provider registry. See how it can be used to incorporate Spacelift resources into your Infrastructure as Code. You can also check out Spacelift for free by creating a trial account!
Understanding how providers work in Terraform and knowing how to make use of the available providers found in the Terraform Registry are fundamental concepts when learning Terraform.
For more information, check out the official documentation.
Manage Terraform Better with Spacelift
Build more complex workflows based on Terraform using policy as code, programmatic configuration, context sharing, drift detection, resource visualization and many more.
