Configuring Components in Stacks
Stacks are used to compose multiple components together and provide their configuration. The schema is the same for all stacks, but the configuration can be different. Use a combination of imports, inheritance, and catalogs for a template-free way to reuse configuration and override values when needed.
Component Schema
A Component consists of the infrastructure as code business logic (e.g. a Terraform "root" module) as well as the configuration of that component. The configuration of a component is stored in a Stack configuration.
To configure a Component in a Stack, you define the component in the components
section of the Stack configuration.
-
Terraform Component is a simply a Terraform Root Module that consists of the resources defined in the
.tf
files in a working directory (e.g. components/terraform/infra/vpc) -
Component Configuration provides configuration (variables and other settings) for a type of component (e.g. a Terraform component) and is defined in one or more YAML stack config files (which are called Atmos stacks)
The schema of an Atmos Component in an Atmos Stack is as follows:
components:
terraform:
# the slug of the component
example:
# configuration specific to atmos
metadata:
# Components can be of type "real" (default) or "abstract"
type: real
# This is the directory path of the component.
# In this example, we're referencing a component in the `components/terraform/stable/example` folder.
component: stable/example
# We can leverage multiple inheritance to sequentially deep merge multiple configurations
inherits:
- example-defaults
# Settings are where we store configuration related to integrations.
# It's a freeform map; anything can be placed here.
settings:
spacelift: { }
# Define the terraform variables, which will get deep-merged and exported to a `.tfvars` file by atmos.
vars:
enabled: true
name: superduper
nodes: 10
Component Attributes
vars
(optional)- The
vars
section is a free-form map. Use component validation to enforce policies. vars.namespace
(optional)This is an optional
terraform-null-label
convention.The namespace of all stacks. Typically, there will be one namespace for the organization.
Example:
vars:
namespace: acmevars.tenant
(optional)This is an optional
terraform-null-label
convention.In a multi-tenant configuration, the tenant represents a single
tenant
. By convention, we typically recommend that every tenant have its own Organizational Unit (OU).Example:
vars:
tenant: platformvars.stage
(optional)This is an optional
terraform-null-label
convention.The
stage
is where workloads run. See our glossary for disambiguation.Example:
vars:
# Production stage
stage: prodvars.environment
(optional)This is an optional
terraform-null-label
convention.The
environment
is used for location where things run. See our glossary for disambiguation.Example:
vars:
# us-east-1
environment: ue1metadata
(optional)- The
metadata
section extends functionality of the component. settings
- The
settings
block is a free-form map used to pass configuration information to integrations.
Types of Components
The type of component is expressed in the metadata.type
parameter of a given component configuration.
There are two types of components:
real
- is a "concrete" component instance that can be provisioned
abstract
- a component configuration, which cannot be instantiated directly. The concept is borrowed from "abstract base classes" of Object-Oriented Programming