Skip to main content

!store

The !store YAML function allows reading the values from a remote store (e.g. SSM Parameter Store, Artifactory, etc.) into Atmos stack manifests.

Usage​

The !store function can be called with either two or three parameters:

  # Get the `key` from the store of a `component` in the current stack
  !store <component> <key>

  # Get the `key` from the store of a `component` in a different stack
  !store <component> <stack> <key>

Arguments​

component
Atmos component name
stack
(optional) Atmos stack name
key
The key to read from the store
tip

You can use Atmos Stack Manifest Templating in the !store YAML function expressions. Atmos processes the templates first, and then executes the !store function, allowing you to provide the parameters to the function dynamically.

Examples​

stack.yaml

components:
  terraform:
    my_lambda_component:
      vars:
        vpc_config:
          security_group_id: !store security-group/lambda id
          security_group_id2: !store security-group/lambda2 {{ .stack }} id
          security_group_id3: !store security-group/lambda3 {{ .atmos_stack }} id

Specifying Atmos stack​

If you call the !store function with three parameters, you need to specify the stack as the second argument.

There are multiple ways you can specify the Atmos stack parameter in the !terraform.output function.

Hardcoded Stack Name​

Use it if you want to get a value from the store for a component from a different (well-known and static) stack. For example, you have a tgw component in a stack plat-ue2-dev that requires the vpc_id key from the vpc component from the stack plat-ue2-prod:

plat-ue2-dev
  components:
    terraform:
      tgw:
        vars:
          vpc_id: !store vpc plat-ue2-prod vpc_id

Reference the Current Stack Name​

Use the .stack (or .atmos_stack) template identifier to specify the same stack as the current component is in (for which the !store function is executed):

  !store <component> {{ .stack }} <key>
  !store <component> {{ .atmos_stack }} <key>

For example, you have a tgw component that requires the vpc_id key from the store for the vpc component in the same stack:

  components:
    terraform:
      tgw:
        vars:
          vpc_id: !store vpc {{ .stack }} vpc_id
Using the .stack or .atmos_stack template identifiers to specify the stack is the same as calling the

!store function with two parameters without specifying the current stack, but without using Go templates. If you need to get a value from the store from a component in the current stack, using the !store function with two parameters is preferred because it has a simpler syntax and executes faster. :::

Use a Format Function​

Use the printf template function to construct stack names using static strings and dynamic identifiers. This is convenient when you want to override some identifiers in the stack name:

  !store <component> {{ printf "%s-%s-%s" .vars.tenant .vars.environment .vars.stage }} <key>

  !store <component> {{ printf "plat-%s-prod" .vars.environment }} <key>

  !store <component> {{ printf "%s-%s-%s" .settings.context.tenant .settings.context.region .settings.context.account }} <key>
<component
Placeholder for an actual component name (e.g. vpc)
<key>
Placeholder for an actual key (e.g. subnet_ids)

For example, you have a tgw component deployed in the stack plat-ue2-dev. The tgw component requires the vpc_id key from the store for the vpc component from the same environment (ue2) and same stage (dev), but from a different tenant net (instead of plat):

plat-ue2-dev
  components:
    terraform:
      tgw:
        vars:
          vpc_id: !store vpc {{ printf "net-%s-%s" .vars.environment .vars.stage }} vpc_id
Important

By using the printf "%s-%s-%s" function, you are constructing stack names using the stack context variables/identifiers.

For more information on Atmos stack names and how to define them, refer to stacks.name_pattern and stacks.name_template sections in atmos.yaml CLI config file

Considerations​

  • Using !store with secrets can expose sensitive data to standard output (stdout) in any commands that describe stacks or components.
  • When using !store with atmos describe affected, Atmos requires access to all referenced remote states. If you operate with limited permissions (e.g., scoped to dev) and reference production stacks, the command will fail.
  • Be mindful of disaster recovery (DR) implications when using it across regions.
  • Consider cold-start scenarios: if the dependent component has not yet been provisioned, the value in the store may not yet be available and the !store function call will fail.