#atmos - August 2024

I am currently working on enabling Go templates in my Atmos config, and I’m having some trouble excluding a Go template from processing by Atmos. In my manifest, I originally had this:

vars:
  username: "aws-sso-qventus-admin-latam-{{SessionName}}"

After enabling templates globally in atmos.yaml, I got this error:
template: all-atmos-sections:136: function "SessionName" not defined

I changed the definition to

vars:
  username: "aws-sso-qventus-admin-latam-{{`{{SessionName}}`}}"

but I’m still getting the same error. I tried the printf syntax as well:

vars:
  username: '{{ printf "aws-sso-qventus-admin-latam-{{SessionName}}" }}'

Same error. Anyone know what I’m missing?

Is there a repository (yet) for common OPA policy patterns that are used with atmos ?

i'm so used to using .yml , is there a reason atmos doesn't find stacks named like that

i like the way atmos generated the tfvars from yaml but i'm wondering if I could disable the different workspace per component behaviour

i'm a real beginner here but it seems like there's a lot of complexity to share things between each state file

I’ve been rummaging around in the Atmos docs for hours, and I’m coming up blank, sorry. I have a stack I’m deploying to dev in an Azure subscription. My name_pattern is {namespace}-{environment} and so my stack is called dev-wus3. I’d like to provision a version of the stack in the same Azure subscription per pull request via a pipeline so that PRs can be tested, and destroy the stack when the PR is closed. If I set the namespace to pr192 atmos throws an error because the pr192 stack doesn’t exist.

I created a pr.yaml which imports the dev stack, and overrides the namespace, and while it works - it’s super hacky!

---
import:
  - development/westus3.yaml
vars:
  environment: wus3
  namespace: pr192

Thoughts on how best to achieve this? Thanks

Is there a way to inject environment variables on each plan/apply using the stack yaml ?

Having trouble with stack templates in github actions. My config works when run locally, but when run in a github action, the go templates return “<no value>“, and I haven’t been able to figure out why.

I’ve verified that my local atmos version and the one installed by the github action workflow are both 1.85.0. Both are using the same atmos.yaml, which has templating enabled. Obviously, both are using the same terraform and atmos code as well. Where else should I be looking for differences?

All the docs for our AWS reference architecture are now public

https://sweetops.slack.com/archives/C04NBF4JYJV/p1723233360401039

is there a custom way to generate files? kind of like the backend.tf.json is created? but I will like to create the version.tf files as well it can be .json as well

team, question wrt to atmos inheritance from catalogs. i.e. mainly seeing in var.tags
This is kind of new behavior, I am noticing the inline tag values takes precedence over any catalog imports correct? but the import values are taking over? anything to do with atmos version or new configs to be aware off

Is there a good way to do repo separation for

• Risky components such as root components
• Segment high priv accounts from developer friendly accounts
This would require sharing configurations between a root level atmos repo and the segmented ones

Thoughts on mixins per stack (i.e. per workspace per component) ?

I think it would help solve one off migrations.tf terraform state blocks per workspace

Any thoughts why atmos.Component is failing when using Geodesic 3.1.0 and atmos 1.86.1 ?

infrastructure ⨠ ATMOS_LOGS_LEVEL=Trace atmos dc jenkins-efs -s core-ue1-auto

Executing command:
atmos describe component jenkins-efs -s core-ue1-auto
invalid stack manifest 'mixins/automation/jenkins/ecs-service-tmpl.yaml'
template: mixins/automation/jenkins/ecs-service-tmpl.yaml:23:81: executing "mixins/automation/jenkins/ecs-service-tmpl.yaml" at <.stack>: invalid value; expected string

import:
  - path: catalog/terraform/efs/defaults
  - path: catalog/terraform/ecs-service/default
    context:
      stage: "{{ .stage }}"

components:
  terraform:
    jenkins-efs:
      metadata:
        component: efs
        inherits:
          - efs/defaults
      vars:
        name: jenkins-efs
        dns_name: jenkins-efs
        hostname_template: "%s-%s-%s-%s"
        provisioned_throughput_in_mibps: 10
        efs_backup_policy_enabled: true
        additional_security_group_rules:
          # ingress
          - cidr_blocks: []
            source_security_group_id: '{{ (atmos.Component "jenkins-ecs-service" .stack).outputs.ecs_service_sg_id }}'
            from_port: 2049
            protocol: TCP
            to_port: 2049
            type: "ingress"
            description: "Allow Local subnet to access"
    jenkins-ecs-service:
      metadata:
        component: ecs-service
        inherits:
          - ecs-service/default
      settings:
        depends_on:
          alb:
            component: jenkins-alb
          cluster:
            component: common-ecs-cluster
      vars:
        alb_name: jenkins-alb
        use_lb: true
        ecs_cluster_name: common-ecs-cluster
        health_check_path: /
        health_check_port: 8080
        health_check_timeout: 5
        health_check_interval: 60
        health_check_healthy_threshold: 5
        health_check_unhealthy_threshold: 5
        health_check_matcher: 200,302,301,403
        name: jenkins
        s3_mirroring_enabled: false
        unauthenticated_paths:
          - "/*"
        unauthenticated_priority: 10
        task:
          task_cpu: 2048
          task_memory: 4096
          use_alb_security_group: true
        containers:
          service:
            cpu: 2048
            name: jenkins
            image: jenkins/jenkins:lts
            memory: 4096
            readonly_root_filesystem: false

            map_environment: {}

            map_secrets:
              NEW_RELIC_LICENSE_KEY: "{{ .stage }}/common/newrelic/license_key"

            port_mappings:
              - containerPort: 8080
                hostPort: 8080
                protocol: tcp
              - containerPort: 50000
                hostPort: 50000
                protocol: tcp


exit status 1

https://atmos.tools/quick-start/advanced/configure-terraform-backend/#provision-terraform-s3-backend

In the above example, once I provision the component for the s3 backend, how do I manage the state of the generated stack? I don't understand the lifecycle. I understand the stack created after this stack is provisioned, but not the stack for the s3 backend. can someone help?

I there any way to stop atmos from processing ALL atmos.Component template functions everytime you do a plan / apply?

Example

when I run:
atmos.exe terraform plan app/apigw --stack org-test-cc1 --skip-init

it retrieves all of the following:

Found component 'app/lambda-api' in the stack 'dhe-test-cc1' in the stack manifest '.../app-split'
Found component 'app/s3-exports' in the stack 'dhe-test-cc1' in the stack manifest '.../app-split'
Found component 'app/ecr' in the stack 'dhe-test-cc1' in the stack manifest '.../app-split'
Found component 'app/s3-graphs' in the stack 'dhe-test-cc1' in the stack manifest '.../app-split'


but only this one is required for the particular stack / plan I am running

Found component 'app/lambda-api' in the stack 'dhe-test-cc1' in the stack manifest '.../app-split'

Quick question, what’s the best way to add flags to an existing Atmos command? I see in the docs that there is an example for overriding an existing Terraform apply with an auto-approve command, but if I wanted to add an additional flag for only showing variables when an atmos describe component -light is ran, would this be a good way to do it?

  - name: describe
    description: "Shows the configuration for an Atmos component in an Atmos stack: atmos describe component <component> -s <stack>"
    commands:
      - name: component
        description: "Describe an Atmos component in an Atmos Stack"
        arguments:
          - name: component
            description: "Name of the component"
        flags:
          - name: stack
            shorthand: s
            description: Name of the stack
            required: true
          - name: light
            shorthand: l
            description: Only display component variables
            required: false
        component_config:
          component: "{{ .Arguments.component }}"
          stack: "{{ .Flags.stack }}"
        steps:
          - >
            {{ if .Flags.light }} 
            atmos describe component {{ .Arguments.component }} -s {{ .Flags.stack }} | yq -r '.vars'
            {{ else }}
            atmos describe component {{ .Arguments.component }} -s {{ .Flags.stack }}
            {{ end }}

Hello, I had an inquiry about the demo-helmfile example:
• Catalog file
• Stack file
• Helmfile
My understanding is that the stack file pulls in the catalog file and then changes it to be of the "real" type. Then I believe that the helmfile gets included via the key/value pair "component: nginx". Some of the previous terminology may be off, but I think that's the general idea.

My inquiry is are the vars of the catalog entry supposed to be injected into the helmfile's nginx release? How mapping to the nginx release work and how are they picked up? Does it use the state-values-file? I noticed this empty values section in the helmfile. Is that related?

I have a dump question:

I've read about schema validation: https://atmos.tools/core-concepts/validate/json-schema

Question:
if i check variables in terraform with input validation, why would i use json schema for components? What would be the advantage (as i need to convert terraform variables into json schema for the most part)

How do i validate vendoring? This is mentioned but not explained.

Hi everyone! I have been excitedly exploring Atmos recently and have a few questions. Overall, it has been relatively smooth so far, but there are a few things I am unclear on:

• Sharing state between components
◦ I get the impression that template functions with atmos.component is the current preferred mechanism over remote-state. Is this correct?
▪︎ A section in the Share Data Between Components page titled "Template Functions vs Remote State" (or something similar) would be very helpful.
▪︎ If someone could distill their knowledge/thoughts on the tradeoffs I would be happy to make a PR to add a distilled version to the docs!
• What is Atmos Pro?
◦ Is this just an optional add-on? or will it be a subscription service?
▪︎ My initial thought was that it was a paid subscription service, but I was able to sign up and install the GH app add a repo and did not see anything related to pricing.
▪︎ Then again, I can't find a public repo for it, which makes me think it is destined to be a subscription service, but it is just brand new.
◦ To share some perspective, when I saw this, it tarnished my excitement about Atmos a bit.
▪︎ I have used and trusted Cloud Posse TF modules for a long time and really enjoy the business model.
▪︎ Seeing Atmos Pro immediately made me think there must be some known painful parts of Atmos that will require me to add another subscription to fix. This didn't follow the Cloud Posse ethos that I was used to, and I am left with a nagging concern now that:
• Atmos will have new exciting features directed towards Atmos Pro instead of Atmos
• I will eventually run into some pain points of Atmos, which is why Atmos Pro exists.

Hi everyone! I have a question:
Can I overwrite a config in CI?
for local development I use aws_profile to authenticate to aws but on CI I will like to use OIDC but it looks like it's looking for the profile when I use the cloudposse/github-action-atmos-affected-stacks@v4 with the atmos config for roles under ./rootfs/usr/local/etc/atmos/

is there a way to maybe set aws_profile to null?

Hey guys I found a potential bug on the atmos plan workflow for github actions,

You guys have this step:
https://github.com/cloudposse/github-action-atmos-terraform-plan/blob/main/action.yml#L110

It will run atmos describe <component> -s <stack> .. but this requires the authentication to happen and that is something that happens after this on this step:
https://github.com/cloudposse/github-action-atmos-terraform-plan/blob/main/action.yml#L268

I have fix this by doing the authentication before the actions runs on the same job that looks to do the trick but maybe is something that should be documented or fix on the action

is it possible to import a mixin for only one component?

How do you folks integrate opensource scanning tools into atmos such as trivy/tfsec, checkov, tflint, etc ?

Related to the above, one thing that came up is inline suppressions with trivy/tfsec and how to do that on a stack-input level instead of in the base-component. 🧵