Terraform providers manage resources by communicating between Terraform and target APIs. Whenever the target APIs change or add functionality, provider maintainers may update and version the provider.
When multiple users or automation tools run the same Terraform configuration, they should all use the same versions of their required providers. There are two ways for you to manage provider versions in your configuration.
terraform
block.If you do not scope provider version appropriately, Terraform will download the latest provider version that fulfills the version constraint. This may lead to unexpected infrastructure changes. By specifying carefully scoped provider versions and using the dependency lock file, you can ensure Terraform is using the correct provider version so your configuration is applied consistently.
In this tutorial, you will create a S3 bucket from an initialized Terraform configuration. Then, you will update the Terraform dependency lock file to use the latest version of the AWS provider, and edit the Terraform configuration to conform to the new provider version's requirements.
You can complete this tutorial using the same workflow with either Terraform Community Edition or HCP Terraform. HCP Terraform is a platform that you can use to manage and execute your Terraform projects. It includes features like remote state and execution, structured plan output, workspace resource summaries, and more.
Select the HCP Terraform tab to complete this tutorial using HCP Terraform.
Clone the Learn Terraform Provider Versioning repository.
$ git clone https://github.com/hashicorp-education/learn-terraform-provider-versioning
Navigate to the repository directory in your terminal.
$ cd learn-terraform-provider-versioning
This directory is a pre-initialized Terraform project with three files: main.tf
, terraform.tf
, and .terraform.lock.hcl
. HashiCorp has released a newer version of the AWS provider since this workspace was first initialized.
main.tf
Open the main.tf
file. This file uses the AWS and random providers to deploy a randomly named S3 bucket to the us-west-2
region.
main.tf
provider "aws" {
region = "us-west-2"
}
resource "random_pet" "petname" {
length = 5
separator = "-"
}
resource "aws_s3_bucket" "sample" {
bucket = random_pet.petname.id
tags = {
public_bucket = false
}
}
Explore terraform.tf
Open the terraform.tf
file. Here you will find the terraform
block which specifies the required provider version and required Terraform version for this configuration.
terraform.tf
terraform {
/* Uncomment this block to use Terraform Cloud for this tutorial
cloud {
organization = "organization-name"
workspaces {
name = "learn-terraform-provider-versioning"
}
}
*/
required_providers {
random = {
source = "hashicorp/random"
version = "3.1.0"
}
aws = {
source = "hashicorp/aws"
version = ">= 4.5.0"
}
}
required_version = "~> 1.2"
}
The terraform
block contains the required_providers
block, which specifies the provider local name, the source address, and the version.
When you initialize this configuration, Terraform will download:
>=
version constraint operator specifies the minimum provider version that is compatible with the configuration.The Terraform block also specifies that only Terraform binaries v1.x, but newer than v1.2, can run this configuration by using the ~>
operator.
terraform.lock.hcl
When you initialize a Terraform configuration for the first time with Terraform 1.1 or later, Terraform will generate a new .terraform.lock.hcl
file in the current working directory. You should include the lock file in your version control repository to ensure that Terraform uses the same provider versions across your team and in ephemeral remote execution environments.
Open the .terraform.lock.hcl
file.
.terraform.lock.hcl
# This file is maintained automatically by "terraform init".
# Manual edits may be lost in future updates.
provider "registry.terraform.io/hashicorp/aws" {
version = "4.5.0"
constraints = ">= 4.5.0"
hashes = [
"h1:PR5m6lcJZzSIYqfhnMd0YWTN+On2XGgfYV5AKIvOvBo=",
"zh:0573de96ba316d808be9f8d6fc8e8e68e0e6b614ed4d707bd236c4f7b46ac8b1",
## ...
"zh:f4722596e8b5f012013f87bf4d2b7d302c248a04a144de4563b3e3f754a30c51",
]
}
provider "registry.terraform.io/hashicorp/random" {
version = "3.1.0"
constraints = "3.1.0"
hashes = [
"h1:9cCiLO/Cqr6IUvMDSApCkQItooiYNatZpEXmcu0nnng=",
"zh:2bbb3339f0643b5daa07480ef4397bd23a79963cc364cdfbb4e86354cb7725bc",
## ...
"zh:d9e13427a7d011dbd654e591b0337e6074eef8c3b9bb11b2e39eaaf257044fd7",
"zh:f7605bd1437752114baf601bdf6931debe6dc6bfe3006eb7e9bb9080931dca8a",
]
}
Notice the two providers specified in your terraform.tf
file. The AWS provider version is v4.5.0. This fulfills the >=4.5.0
constraint, but is no longer the latest version of the AWS provider. The random provider is set to v3.1.0 and fulfills its version constraints.
Initialize this configuration.
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/random from the dependency lock file
- Installing hashicorp/aws v4.5.0...
- Installed hashicorp/aws v4.5.0 (signed by HashiCorp)
- Installing hashicorp/random v3.1.0...
- Installed hashicorp/random v3.1.0 (signed by HashiCorp)
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.
If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Open your terraform.tf
file and uncomment the cloud
block. Replace the organization
name with your own HCP Terraform organization.
terraform.tf
terraform {
cloud {
organization = "organization-name"
workspaces {
name = "learn-terraform-provider-versioning"
}
}
required_providers {
random = {
source = "hashicorp/random"
version = "3.1.0"
}
aws = {
source = "hashicorp/aws"
version = ">= 4.5.0"
}
}
required_version = "~> 1.2"
}
Initialize your configuration. Terraform will automatically create the learn-terraform-provider-versioning
workspace in your HCP Terraform organization.
$ terraform init
Initializing HCP Terraform...
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/random from the dependency lock file
- Installing hashicorp/aws v4.5.0...
- Installed hashicorp/aws v4.5.0 (signed by HashiCorp)
- Installing hashicorp/random v3.1.0...
- Installed hashicorp/random v3.1.0 (signed by HashiCorp)
HCP Terraform has been successfully initialized!
You may now begin working with HCP Terraform. Try running "terraform plan" to
see any changes that are required for your infrastructure.
If you ever set or change modules or Terraform Settings, run "terraform init"
again to reinitialize your working directory.
Notice that instead of installing the latest version of the AWS provider that conforms with the configured version constraints, Terraform installed the version specified in the lock file. While initializing your workspace, Terraform read the dependency lock file and downloaded the specified versions of the AWS and random providers.
If Terraform did not find a lock file, it would download the latest versions of the providers that fulfill the version constraints you defined in the required_providers
block. The following table shows which provider Terraform would download in this scenario, based on the version constraint and presence of a lock file.
terraform init
(no lock file) terraform init
(lock file) aws >= 4.5.0 Latest version (e.g. 5.55.0) Lock file version (4.5.0) random 3.1.0 3.1.0 Lock file version (3.1.0)
The lock file instructs Terraform to always install the same provider version, ensuring that consistent runs across your team or remote sessions.
Apply your configuration. Respond to the confirmation prompt with a yes
to create the example infrastructure.
$ terraform apply
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# aws_s3_bucket.sample will be created
+ resource "aws_s3_bucket" "sample" {
+ acceleration_status = (known after apply)
## ...
Plan: 2 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
## ...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
The -upgrade
flag will upgrade all providers to the latest version consistent within the version constraints specified in your configuration.
Upgrade the AWS provider.
Note
You should never directly modify the lock file.
$ terraform init -upgrade
Initializing HCP Terraform...
Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 4.5.0"...
- Finding hashicorp/random versions matching "3.1.0"...
- Installing hashicorp/aws v5.56.1...
- Installed hashicorp/aws v5.56.1 (signed by HashiCorp)
- Using previously-installed hashicorp/random v3.1.0
Terraform has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.
Terraform has been successfully initialized!
## ...
Notice that Terraform installs the latest version of the AWS provider.
Open the .terraform.lock.hcl
file and notice that the AWS provider's version is now the latest version.
.terraform.lock.hcl
provider "registry.terraform.io/hashicorp/aws" {
version = "5.56.1"
constraints = ">= 4.5.0"
## ...
}
Tip
You can also use the -upgrade
flag to downgrade the provider versions if the version constraints are modified to specify a lower provider version that the one specified in the lock file.
Plan your configuration to ensure that it works with the upgraded provider.
$ terraform plan
random_pet.petname: Refreshing state... [id=gratefully-radically-quickly-fitting-troll]
aws_s3_bucket.sample: Refreshing state... [id=gratefully-radically-quickly-fitting-troll]
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and
found no differences, so no changes are needed.
Tip
Occasionally a provider upgrade will require that you to modify your configuration to work with the new provider version. For example, attribute names or requirements may change from one major provider version to another. Always run a Terraform plan after changing your provider versions.
If the plan step completes successfully, it is safe to commit the configuration with the updated lock file to version control. If the plan or apply steps fail, do not commit the lock file to version control until you've resolved the error.
After verifying that the resources were deployed successfully, destroy them. Remember to respond to the confirmation prompt with yes
.
$ terraform destroy
## ...
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
- destroy
Terraform will perform the following actions:
# aws_s3_bucket.sample will be destroyed
- resource "aws_s3_bucket" "sample" {
## ...
Plan: 0 to add, 0 to change, 2 to destroy.
Do you really want to destroy all resources?
Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.
Enter a value: yes
## ...
Destroy complete! Resources: 2 destroyed.
If you used HCP Terraform for this tutorial, after destroying your resources, delete the learn-terraform-provider-versioning
workspace from your HCP Terraform organization.
In this tutorial, you used the dependency lock file to manage provider versions, and upgraded the lock file.
To learn more about providers, visit the following resources.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4