Terrafile
Best of Both Worlds
The Terrafile approach simplifies managing modules. The advantage of using a Terrafile is centralization. You can centrally define, manage, and update modules. To define modules, add them to Terrafile:
Terrafile
org "boltops-tools" # set default org
mod "s3", source: "git@github.com:boltops-tools/terraform-aws-s3"
mod "sg", source: "terraform-aws-modules/security-group/aws", version: "3.10.0"
To install the modules, run:
terraspace bundle
Modules are downloaded to your vendor/modules folder. You can easily look at the module source code when you need to debug.
Usage
Here’s a demo stack that uses the downloaded vendor/modules/s3 module.
app/stack/demo/main.tf
resource "random_pet" "this" {
length = 2
}
module "bucket" {
source = "../../modules/s3" # looks up either app/modules/s3 or vendor/modules/s3
bucket = "bucket-${random_pet.this.id}"
acl = var.acl
}
A module downloaded to vendor/modules/s3 is sourced same way as if they were defined in app/modules/s3. This is because Terraspace considers multiple lookup paths. Docs: Lookup Paths
Here’s an example repo based on these docs: boltops-tools/terraspace-demo-terrafile
Terrafile.lock
A Terrafile.lock file is also generated. This file can be committed to version control to ensure that everyone on the team uses the exact same version.
Pure Terraform Approach
Of course, you can still use the typical approach of declaring the source directly in the module source code. Here are some examples from the docs:
module "consul" {
source = "hashicorp/consul/aws"
version = "0.1.0"
}
module "example" {
source = "github.com/hashicorp/example"
}
Terraspace provides flexibility. You can use either or both approaches. You get the best of both worlds.
