Skip to main content
Sponsor @cloudposse

Frequently Asked Questions

When should we write a new component?​

Developing a new component may be necessary when:

  1. Existing components do not provide the required functionality and the existing component cannot be easily extended.
  2. Cloud Posse's Library of Terraform Components does not already provide the component. We recommend asking Cloud Posse in your shared Slack channel with us if we happen to have the component not yet upstreamed.
  3. You have some existing Terraform code that you would like to import into the Atmos framework.

Can components include other components?​

Components should not include other components but instead can refer to another component's Terraform Output with remote-state. Components can however refer to any Terraform module

What is the purpose of context.tf?​

Cloud Posse uses context.tf to consistently set metadata across all modules and resources.

Where should the context.tf file be copied from?​

The context.tf file should be copied exactly from https://raw.githubusercontent.com/cloudposse/terraform-null-label/master/exports/context.tf.

How can Terraform modules or resources be added to a component?​

Terraform modules or resources can be added directly to the main.tf file or other files of your choosing.

Please be advised that modifying any of the vendored components may break the ability to pull down upstream changes. If modifying an existing component to preserve vendoring capabilities, name your files something like customizations.extended.tf, so that it won't collide with upstream files (e.g. using .extended.tf as the extension). Similarly, if needing to modify core functionality, consider using Terraform overrides.

What is an abstract component?​

An abstract component is a component configuration that cannot be instantiated directly.

Does Cloud Posse have automated testing for components?​

We do not have automated testing for our components at this time. However, GitOps pipelines with Spacelift can automate component deployment into lower environments so that we can validate any code changes in each stage before reaching production.

Also, we do have automated tests for all Terraform modules the components built off of (rds-cluster example) and static code linting for Terraform and Atmos (with a local .github/workflows/pre-commit.yml).