In the previous blog we discussed about what terraform is and it's architecture. In this blog, let's discuss about one of it's component, Providers, in more detail.
A Provider is a plugin that enables communication with an API. The Terraform configuration code contains information about the providers. Providers allow Terraform to interact with cloud providers, SaaS providers, and other APIs.
Provider inform Terraform of the services it must communicate with. There are hundreds of available providers that can be used with Terraform, making it a hugely versatile tool. In contrast to languages that may be platform-specific, like Bicep (which exclusively interacts with the Azure API) or Microsoft Azure ARM templates, Terraform is platform agnostic and can be used on a variety of platforms, which contributes significantly to its popularity.
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.
Providers are written in Go and utilize the Terraform Plugin SDK. Each provider is released independently from Terraform itself with each version providing additional features and bug fixes. 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.
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.
Provider Configuration
Provider configurations belong in the root module of a Terraform configuration. Any Child modules receive their provider configurations from the root module. Some providers require certain information to be configured such as endpoint URLs or cloud regions. Providers are configured using a providers block.
provider "google" {
project = "acme-app"
region = "us-central1"
}The name given in the block header ("google" in this example) is the local name of the provider to configure. This provider should already be included in a required_providers block.
The body of the block (between { and }) contains configuration arguments for the provider. Most arguments in this section are defined by the provider itself; in this example both project and region are specific to the google provider.
There are also two "meta-arguments" that are defined by Terraform itself and available for all provider blocks:
alias, for using the same provider with different configurations for different resources
version, which is deprecated (use provider requirements instead)
1. Alias: Multiple Provider Configurations
You can optionally define multiple configurations for the same provider, and select which one to use on a per-resource or per-module basis. The primary reason for this is to support multiple regions for a cloud platform.
To create multiple configurations for a given provider, include multiple provider blocks with the same provider name. For each additional non-default configuration, use the alias meta-argument to provide an extra name segment. For example:
# The default provider configuration; resources that begin with `aws_` will use
# it as the default, and it can be referenced as `aws`.
provider "aws" {
region = "us-east-1"
}
# Additional provider configuration for west coast region; resources can
# reference this as `aws.west`.
provider "aws" {
alias = "west"
region = "us-west-2"
}To declare a configuration alias within a module in order to receive an alternate provider configuration from the parent module, add the configuration_aliases argument to that provider's required_providers entry. The following example declares both the mycloud and mycloud.alternate provider configuration names within the containing module:
terraform {
required_providers {
mycloud = {
source = "mycorp/mycloud"
version = "~> 1.0"
configuration_aliases = [ mycloud.alternate ]
}
}
}Default Provider Configurations
A provider block without an alias argument is the default configuration for that provider. Resources that don't set the provider meta-argument will use the default provider configuration that matches the first word of the resource type name. (For example, an aws_instance resource uses the default aws provider configuration unless otherwise stated.)
Referring to Alternate Provider Configurations
When Terraform needs the name of a provider configuration, it expects a reference of the form <PROVIDER NAME>.<ALIAS>. In the example above, aws.west would refer to the provider with the us-west-2 region. These references are special expressions.
Selecting Alternate Provider Configurations
By default, resources use a default provider configuration (one without an alias argument) inferred from the first word of the resource type name.
To use an alternate provider configuration for a resource or data source, set its provider meta-argument to a <PROVIDER NAME>.<ALIAS> reference:
resource "aws_instance" "foo" {
provider = aws.west
# ...
}To select alternate provider configurations for a child module, use its providers meta-argument to specify which provider configurations should be mapped to which local provider names inside the module:
module "aws_vpc" {
source = "./aws_vpc"
providers = {
aws = aws.west
}
}Modules have some special requirements when passing in providers. In most cases, only root modules should define provider configurations, with all child modules obtaining their provider configurations from their parents.
2. version (Deprecated)
The version meta-argument specifies a version constraint for a provider, and works the same way as the version argument in a required_providers block. The version constraint in a provider configuration is only used if required_providers does not include one for that provider.
With this let's wrap the post here. I hope you find this informative.
Thank you for reading!
*** Explore | Share | Grow ***
留言