Skip to main content

Final Notes

Atmos provides unlimited flexibility in defining and configuring stacks and components in the stacks.

  • Terraform components can be in different sub-folders in the components/terraform directory. The sub-folders can be organized by type, by teams that are responsible for the components, by operations that are performed on the components, or by any other category

  • Atmos stack manifests can have arbitrary names and can be located in any sub-folder in the stacks directory. Atmos stack filesystem layout is for people to better organize the stacks and make the configurations DRY. Atmos (the CLI) does not care about the filesystem layout, all it cares about is how to find the stacks and the components in the stacks by using the context variables namespace, tenant, environment and stage

  • An Atmos component can have any name that can be different from the Terraform component name. For example, two different Atmos components s3-bucket/1 and s3-bucket/2 can provide configuration for the same Terraform component s3-bucket

  • We can provision more than one instance of the same Terraform component (with the same or different settings) into the same environment by defining many Atmos components that provide configuration for the Terraform component. For example, the following config shows how to define two Atmos components, s3-bucket/1 and s3-bucket/2, which both point to the same Terraform component s3-bucket (see the Multiple Component Instances design pattern):

    import:
      - orgs/acme/plat/dev/_defaults
      - mixins/region/us-east-2
      # Import the defaults for all `s3-bucket` components
      - catalog/s3-bucket/defaults

    components:
      terraform:
        # Atmos component `s3-bucket/1`
        s3-bucket/1:
          metadata:
            # Point to the Terraform component in `components/terraform/s3-bucket`
            component: s3-bucket
            # Inherit the defaults for all `s3-bucket` components
            inherits:
              - s3-bucket/defaults
          # Define/override variables specific to this `s3-bucket/1` component
          vars:
            name: assets-1

        # Atmos component `s3-bucket/2`
        s3-bucket/2:
          metadata:
            # Point to the Terraform component in `components/terraform/s3-bucket`
            component: s3-bucket
            # Inherit the defaults for all `s3-bucket` components
            inherits:
              - s3-bucket/defaults
          # Define/override variables specific to this `s3-bucket/2` component
          vars:
            name: assets-2

    Then we can execute the following atmos commands to provision the two buckets into the dev account in the us-east-2 region:

    atmos terraform apply s3-bucket/1 -s plat-ue2-dev
    atmos terraform apply s3-bucket/2 --stack plat-ue2-dev

All the above makes Atmos an ideal framework to organize infrastructure, to design for organizational complexity, and to provision multi-account environments for very complex organizations — and, as this tutorial showed, you can learn all of it offline against a local sandbox before pointing it at a real cloud account.