NUL projects such as Meadow and AVR have their own terraform
directories where their app-specific resources are managed. This repository is for resources (such as the VPC/Firewall, or third-party pieces like Fedora, Solr, etc.) that don't have another specific project managing them.
Each top-level folder represents a discrete piece of infrastructure, and we should strive to keep them relatively small and self-contained. Their resources and outputs can be referenced from other terraform projects in one of several ways:
- The AWS Systems Manager Parameter Store
- Terraform Remote State
- Variable files
Each folder should follow the same naming conventions:
main.tf
– The main terraform manifest for the folder, where the provider, backend, and primary resources are specifiedsecrets.tf
– Contains variables/secrets used elsewhere in the manifest, as well as any locals derived only from those valuesdata.tf
– Contains terraformdata
sources, if there are enough of them to warrant splitting them outoutputs.tf
– Contains only terraform outputs
Each folder should be initialized the same way:
-
Use the AWS provider with an S3 backend:
terraform { backend "s3" { key = "[project_or_folder_name].tfstate" # e.g., `solrcloud.tfstate` or `staging-waf.tfstate` } } provider "aws" { }
When running terraform init
:
- Use
nulterra-state-sandbox
as the remote S3 bucket
Before running terraform plan
or terraform apply
:
- Create or select a workspace with the same name as the environment you're deploying to, e.g.:
or (if the workspace doesn't exist yet)
$ terraform workspace select staging
$ terraform workspace new production
Reusable groups of resources can be assembled into modules with their own variables and outputs. Modules can be very useful, but can also greatly increase the complexity of the project. Any reusable modules we create can be put in the modules
folder. If used by other projects within this repo, they can be referenced by the relative path from the project folder (e.g., ../modules/some_module
). If used by terraform code owned by another project, they can be referenced using an HTTP url scheme (e.g., git::https://github.com/nulib/infrastructure.git//modules/my_module
).
If modules develop to a point where they need to be released and versioned, we can look into using a module registry.