#atmos (2024-12)
2024-12-01
2024-12-02
Hi All! Getting Started with Atmos and have some questions about the bootstrapping. I appreciate some guidance.
I am a little bit confused about the deployment of the tfstate-backend component with the temporary SuperAdmin IAM user, before setting up the organization. I am using the {tenant}-{environment}-{stage} naming convention.
• If I want to have a seperate state bucket/dynamodb table for each account, where should I deploy the tfstate-backend component? Currently it is deployed at core-gbl-root but it kinda does not make sense to me as the region of the dynamodb table is at eu-west-1.
• Where should I deploy the account and account-map components? The management account? If so what is the tenant, environment and stage for the management account?
Thanks!
Current Directory Structure:
.
├── README.md
├── atmos.yaml
├── components
│ └── terraform
│ ├── account
│ │ ├── context.tf
│ │ ├── main.tf
│ │ ├── outputs.tf
│ │ ├── providers.tf
│ │ ├── variables.tf
│ │ └── versions.tf
│ ├── account-map
│ │ ├── account-info.tftmpl
│ │ ├── context.tf
│ │ ├── dynamic-roles.tf
│ │ ├── main.tf
│ │ ├── modules
│ │ │ ├── iam-roles
│ │ │ │ ├── README.md
│ │ │ │ ├── context.tf
│ │ │ │ ├── main.tf
│ │ │ │ ├── outputs.tf
│ │ │ │ ├── providers.tf
│ │ │ │ ├── variables.tf
│ │ │ │ └── versions.tf
│ │ │ ├── roles-to-principals
│ │ │ │ ├── README.md
│ │ │ │ ├── context.tf
│ │ │ │ ├── main.tf
│ │ │ │ ├── outputs.tf
│ │ │ │ └── variables.tf
│ │ │ └── team-assume-role-policy
│ │ │ ├── README.md
│ │ │ ├── context.tf
│ │ │ ├── github-assume-role-policy.mixin.tf
│ │ │ ├── main.tf
│ │ │ ├── outputs.tf
│ │ │ └── variables.tf
│ │ ├── outputs.tf
│ │ ├── providers.tf
│ │ ├── remote-state.tf
│ │ ├── variables.tf
│ │ └── versions.tf
│ └── tfstate-backend
│ ├── context.tf
│ ├── iam.tf
│ ├── main.tf
│ ├── outputs.tf
│ ├── providers.tf
│ ├── variables.tf
│ └── versions.tf
├── stacks
│ ├── catalog
│ │ ├── account
│ │ │ └── defaults.yaml
│ │ ├── account-map
│ │ │ └── defaults.yaml
│ │ └── tfstate-backend
│ │ └── defaults.yaml
│ ├── mixins
│ │ ├── region
│ │ │ ├── eu-west-1.yaml
│ │ │ └── global.yaml
│ │ ├── stage
│ │ │ └── root.yaml
│ │ ├── tenant
│ │ │ └── core.yaml
│ │ └── tfstate-backend.yaml
│ └── orgs
│ └── dunder-mifflin
│ ├── _defaults.yaml
│ └── core
│ ├── _defaults.yaml
│ └── root
│ ├── _defaults.yaml
│ └── eu-west-1.yaml
└── vendor.yaml
22 directories, 55 files
Desired Organization Structure
[ACC] Root/Management Account (account name: dunder-mifflin-root)
│
├── [OU] Security
│ ├── [ACC] security-log-archive
│
├── [OU] Core
│ ├── [ACC] core-monitoring
│ └── [ACC] core-shared-services
│
└── [OU] Workloads
├── [OU] Production
│ └── [ACC] workloads-prod
│
└── [OU] Non-Production
└── [ACC] workloads-non-prod
Hey! FYI, if anyone uses Mise/asdf to manage Atmos version + Renovate to handle dependency updates, I recently created PR adding support for Atmos in respective Renovate managers. It was merged already and deployed by Renovate. I see it works for my repos, so if you use the same setup, it should take care of the updates, too. See docs: https://docs.renovatebot.com/modules/manager/mise/ https://docs.renovatebot.com/modules/manager/asdf/
Anything we can add here? https://atmos.tools/install#other-ways-to-install
…some examples of your configuration maybe
No need I think as I added asdf and Mise tabs a while ago. They are available in the link you provided. Renovate will take care of updating .tool-versions/.mise.toml respectively.
I have a question about abstract components, should they be ignore on the UI since they are not real components?
I have a defaults.yaml file on the catalog that is abstract that I’m using on some real components that I’m inheriting this abstract component but I see both of this on the atmos UI is this intended? should abstract components not be hidden from this UI?
currently we show all the components in the Atmos UI.
i agree we don’t need to show the abstract components to execute the commands like atmos terraform plan/apply, but they can be used in the commands like atmos describe component
we’ll probably disable the abstract components in the UI
@Andriy Knysh (Cloud Posse) we display abstract in the UI? I think we should remove that.
But add it to atmos list components
As one of the columns
2024-12-03
Question about remote-state and atmos.Component for sharing data between components/stacks. Basically, trying to share VPC and Subnet IDs.
I see this comment saying template functions should rarely be used https://sweetops.slack.com/archives/C031919U8A0/p1732031315369959?thread_ts=1732030781.552169&cid=C031919U8A0 but then in documentation template functions are the "new and improved way to share data. So which is it? https://atmos.tools/core-concepts/components/terraform/remote-state/
I’m hitting strange errors with atmos.Component where locally values are grabbed correctly but in TFC outputs are just null, despite existing in state. Or the first run grabs the Ids but then in subsequent runs the Ids are lost. All troubleshooting has failed - So im trying to switch to remote-state. Not doing anything special yet, and getting errors.
VPC is in the same stack, different component. Stage, tenent, environment are all the same. Using context = module.this.context
Any advice? Error: failed to find a match for the import '/home/tfc-agent/.tfc-agent/component/terraform/runs/run-xxxxxxx/config/stacks/orgs/**/*.yaml' ('/home/tfc-agent/.tfc-agent/component/terraform/runs/run-xxxxxxx/config/stacks/orgs' + '**/*.yaml')