Skip to main content
Version: v18.5.0

Component-based Cumulus Deployment

Cumulus is now released in a modular architecture, which will allow users to pick and choose the individual components that they want to deploy. These components will be made available as Terraform modules.

Cumulus users will be able to add those individual components to their deployment and link them together using Terraform. In addition, users will be able to make use of the large number of publicly available modules on the Terraform Module Registry.

Available Cumulus Components

Adding components to your Terraform deployment

Although Terraform components can be configured using a single file, it is recommended to add the following files to your deployment:

variables.tf, main.tf, and outputs.tf should be stored in version control, as they will be constant no matter what environment you are deploying to.

terraform.tfvars is going to contain environment-specific (and possibly sensitive) values, so it should be added to .gitignore.

terraform.tf is home to your Terraform-specific settings. This file will contain environment-specific values, so it should be added to .gitignore. Unfortunately, terraform blocks can only contain constant values; they cannot reference variables defined in terraform.tfvars.

An example of using Terraform to deploy components can be found in the example directory of the Cumulus repo.

Remote State

We suggest to follow the recommendations from the Terraform's Remote State documentation:

By default, Terraform stores state locally in a file named terraform.tfstate. When working with Terraform in a team, use of a local file makes Terraform usage complicated because each user must make sure they always have the latest state data before running Terraform and make sure that nobody else runs Terraform at the same time.

With remote state, Terraform writes the state data to a remote data store, which can then be shared between all members of a team.

The recommended approach for handling remote state with Cumulus is to use the S3 backend. This backend stores state in S3 and uses a DynamoDB table for locking.

See the deployment documentation for a walk-through of creating resources for your remote state using an S3 backend.