CODEWITHSUNDEEP
terraformdevopsterraform-provider-awsterraform-modulesterraform-provider
FrezZ
FrezZ

Reputation: 1

Terrafrom providers in module, and in root file

I have a module that uses AWS resources, so I indicate the version of the AWS provider there:

terraform {
  required_version = ">= 1.5"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

and I have a place where this module is called, but nothing is used there except the module,

terraform {
  required_version = ">= 1.5"
}

so my question is, do I need to indicate the version of the provider in the module and where it is called? or is it possible to indicate it in the module, since there are no blocks in the resources where it is called.

In my opinion, you can use a tikki provider where there are AWS resources.

UPD: I know how use and working provider AWS, but I ask everyone how they use modules and providers, For example, if I have an AWS resource declared in a module, then I use the provider in the module, but if I don`t have AWS resources in the root file of the terraform (where the module itself is called), do I need to specify the provider there as well, or if no resources are used, then the provider does not need to be specified? The second option is more suitable for me because it goes through the TF linter

Upvotes: 0

Views: 897

Answers (1)

Martin Atkins
Martin Atkins

Reputation: 74209

In Terraform, each module has its own separate set of provider dependencies. Terraform will then consider all of the modules together and try to find a single version of each declared provider that will satisfy all of the modules.

Concretely, any module that contains at least one resource whose type belongs to the AWS provider, or that includes a provider configuration for the AWS provider, is depending on the AWS provider and so should declare that it is.

Because provider configurations always belong in the root module, any configuration that contains at least one module that uses the AWS provider should also have its root module depend on the provider, because that tells Terraform which provider the configuration is for and allows Terraform to see that the root module is configuring the same provider that the child module is expecting.

For example, a root module that calls another module that uses the AWS provider might be written like this (these declarations don't all need to be in the same file, but I'm writing it that way for simplicity's sake):

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

# The "aws" label below refers to the key declared
# in the required_providers block above, so Terraform
# can see that you intend "aws" to mean "hashicorp/aws"
# in this module.
provider "aws" {
  region = "us-west-2"
}

module "example" {
  source = "./example"

  # ...
}

If the child module also declares that aws means hashicorp/aws, using the same required_providers syntax, then Terraform will notice that the two modules are using the same provider and so will automatically associated the resource blocks in the child module with the provider "aws" block in the root module.

Version constraints (the version argument alongside source) are always optional, but if you specify one then it should ideally describe only what each individual module requires:

  • Since the root module's only interaction with the hashicorp/aws provider is setting the region argument in the provider configuration, and that region argument has been present right back to the very first version of this provider, the root module effectively has no version constraint at all: any version of the provider should understand what this module sets.
  • Your child module probably includes at least one resource block referring to a resource type belonging to the AWS provider, and so your minimum required version would be the oldest version that supports all of the resource types the module uses and supports all of the arguments you've set for each of those resource types.

In practice it's complicated to figure out which version is the earliest possible compatible version, so a reasonable shorthand is to set it to the earliest provider version that you've tested the module with. Unless you are making a module for broad use in many different contexts, you presumably won't be using your module with very old versions of the hashicorp/aws provider and so it doesn't matter too much if your version constraint specifies a newer version than is strictly required.

Upvotes: 0

Related Questions