https://cloudposse.com logo
Join Slack
Powered by
I am using abstract components with inheritance. I...
# atmos
j
I am using abstract components with inheritance. Is the expectation that all components for a given stack are now written to a single remote state? Or is it because I need these defined to avoid drift?
Copy code
vars:
        labels_as_tags: []
        label_value_case: none
        regex_replace_chars: "/[^a-zA-Z0-9\\s-]/"
Copy code
Terraform has been successfully initialized!
Switched to workspace "cfsb-aws-org-units".
aws_organizations_organizational_unit.this[0]: Preparing import... [id=ou-8wia-m8s04a9h]
aws_organizations_organizational_unit.this[0]: Refreshing state... [id=ou-8wia-m8s04a9h]
Normally, I would expect the workspace to be formatted as 
{{ .atmos_stacks }}-{{ .atmos_components}}
c
Hey I think this is the most relevant section of the docs for you as it defines how 
atmos
decides that the 
workspace_key_prefix
is derived which then decides where the state is in the bucket: https://atmos.tools/design-patterns/version-management/folder-based-versioning#how-atmos-calculates-workspace_key_prefix If you actually set 
workspace_key_prefix
to something static in your top level 
backend.s3
then it would actually be the same state file for all (which would not be good). But based on these docs if you do not define 
workspace_key_prefix
then it should default to the component name (and then the actual workspace is a dir under that).
j
Odd that didn't work...this does though:
Copy code
aws/account:
      backend_type: s3
      backend:
        s3:
          acl: "bucket-owner-full-control"
          encrypt: true
          key: "{{ .atmos_stack}}-{{ .atmos_component }}.tfstate"
          region: "us-east-1"
          use_lockfile: true
          workspace_key_prefix: "account-factory"
It still reuses the workspace, but at least the value of 
key
ensures nothing is overwritten
c
So if you leave out 
workspace_key_prefix
in the above config, then do a plan and then look in the generated 
backend.tf.json
file you don't see it using the component name for the 
workspace_key_prefix
?
j
Figured it out! The article you provided referenced metadata values that I was previously missing
👍 1
For example:
Copy code
import:
  - mixins/providers/aws

components:
  terraform:
    aws/account:
      backend_type: s3
      backend:
        s3:
          acl: "bucket-owner-full-control"
          encrypt: true
          key: "terraform.tfstate"
          region: "us-east-1"
          use_lockfile: true
          workspace_key_prefix: "account-factory"
      metadata:
        type: abstract
        component: '{{ .atmos_component }}'
        name: '{{ .atmos_component }}'
      source:
        uri: <http://github.com/cloudposse-terraform-components/aws-account//src|github.com/cloudposse-terraform-components/aws-account//src>
        version: v2.0.0
      vars:
        enabled: true
        region: us-east-1
I'm futzing around with abstract components + JIT vendoring
I'm looking to improve our Service Catalog by replacing static vendor manifests with JIT vendoring for better flexibility
a
all the above is correct with a single exception (which the original question was about) https://atmos.tools/design-patterns/inheritance-patterns/multiple-component-instances
if you have multiple Atmos component instances inheriting from the same Atmos abstract component (with default values)
Copy code
components:
  terraform:
    # Atmos component `vpc/1`
    vpc/1:
      metadata:
        # Point to the Terraform component in `components/terraform/vpc`
        component: vpc
        # Inherit the defaults for all VPC components
        inherits:
          - vpc/defaults
      # Define/override variables specific to this `vpc/1` component
      vars:
        name: vpc-1
        ipv4_primary_cidr_block: 10.9.0.0/18

    # Atmos component `vpc/2`
    vpc/2:
      metadata:
        # Point to the Terraform component in `components/terraform/vpc`
        component: vpc
        # Inherit the defaults for all VPC components
        inherits:
          - vpc/defaults
      # Define/override variables specific to this `vpc/2` component
      vars:
        name: vpc-2
        ipv4_primary_cidr_block: 10.10.0.0/18
        map_public_ip_on_launch: false
then the generated ``workspace_key_prefix`` will be the Atmos component name(s) (not the terraform component name as in case of a simple Atmos component) to distinguish the two components' states
3 Views
Open in Slack
PreviousNext
Powered by