Skip to content

Releases: cloudposse/atmos

v1.4.5

14 Apr 04:18
6e7e88e
Compare
Choose a tag to compare

what

  • Fix detection of component dependencies for imported YAML config files

why

  • If a file was imported and did not contain a vars section, global or related to the component, the imported file was not included in the component dependencies (deps section), and a Spacelift label for the file was not created (if the imported file changes, Spacelift would not notice the change and would not run the stack)
  • Update the dependencies logic to check for these sections: backend, backend_type, env, remote_state_backend, remote_state_backend_type, settings or vars
// Component depends on the imported config file if any of the following conditions is true:
// 1. The imported file has any of the global `backend`, `backend_type`, `env`, `remote_state_backend`, `remote_state_backend_type`, `settings` or `vars` sections which are not empty
// 2. The imported file has the component type section, which has any of the `backend`, `backend_type`, `env`, `remote_state_backend`, `remote_state_backend_type`, `settings` or `vars` sections which are not empty
// 3. The imported config file has the "components" section, which has the component type section, which has the component section
// 4. The imported config file has the "components" section, which has the component type section, which has the base component section

v1.4.4

12 Apr 20:18
8a36575
Compare
Choose a tag to compare

what

  • Add atmos describe stacks command
  • Allow writing the result to a file by using --file command-line flag
  • Allow formatting the result as YAML or JSON by using --format command-line flag
  • Allow filtering of the result by using the command-line flags: stack, component-types, components, sections
  • Available component sections: backend, backend_type, deps, env, inheritance, metadata, remote_state_backend, remote_state_backend_type, settings, vars

why

  • Command to show stack configs and all the components in the stacks
  • Slice and dice the stack config to show different information about stacks and components

usage

atmos describe stacks
atmos describe stacks --component-types=helmfile
atmos describe stacks --component-types=terraform,helmfile
atmos describe stacks --components=infra/vpc
atmos describe stacks --components=echo-server
atmos describe stacks --components=echo-server,infra/vpc
atmos describe stacks --components=echo-server,infra/vpc --sections=vars
atmos describe stacks --components=echo-server,infra/vpc --sections=vars,settings
atmos describe stacks --components=test/test-component-override-3 --sections=inheritance
atmos describe stacks --components=test/test-component-override-3 --sections=component
atmos describe stacks --components=test/test-component-override-3 --sections=deps
atmos describe stacks --components=test/test-component-override-3 --sections=vars,settings --file=stacks.yaml
atmos describe stacks --components=test/test-component-override-3 --sections=vars,settings --format=json --file=stacks.json
atmos describe stacks --components=test/test-component-override-3 --sections=deps,vars -s=tenant2/ue2/staging

examples

Click to expand

Show all stacks with all the components with all the component sections (Warning: this will dump ALL YAML config for all components for all stacks to the console)

atmos describe stacks

......

tenant2/ue2/staging:
  components:
    terraform:
      test/test-component-override-3:
        backend:
          acl: bucket-owner-full-control
          bucket: eg-ue2-root-tfstate
          dynamodb_table: eg-ue2-root-tfstate-lock
          encrypt: true
          key: terraform.tfstate
          region: us-east-2
          role_arn: null
          workspace_key_prefix: test-test-component
        backend_type: s3
        command: terraform
        component: test/test-component
        deps:
        - catalog/terraform/services/service-1
        - catalog/terraform/services/service-2
        - catalog/terraform/test-component
        - catalog/terraform/test-component-override-3
        - globals/globals
        - globals/tenant2-globals
        - globals/ue2-globals
        - tenant2/ue2/staging
        env:
          TEST_ENV_VAR1: val1-override-3
          TEST_ENV_VAR2: val2-override-3
          TEST_ENV_VAR3: val3-override-3
          TEST_ENV_VAR4: val4-override-3
        inheritance:
        - mixin/test-2
        - mixin/test-1
        - test/test-component-override-2
        - test/test-component-override
        - test/test-component
        metadata:
          component: test/test-component
          inherits:
          - test/test-component-override
          - test/test-component-override-2
          - mixin/test-1
          - mixin/test-2
          terraform_workspace: test-component-override-3-workspace
          type: real
        remote_state_backend:
          acl: bucket-owner-full-control
          bucket: eg-ue2-root-tfstate
          dynamodb_table: eg-ue2-root-tfstate-lock
          encrypt: true
          key: terraform.tfstate
          region: us-east-2
          role_arn: arn:aws:iam::123456789012:role/eg-gbl-root-terraform
          workspace_key_prefix: test-test-component
        remote_state_backend_type: s3
        settings:
          spacelift:
            stack_name_pattern: '{tenant}-{environment}-{stage}-new-component'
            workspace_enabled: false
        vars:
          enabled: true
          environment: ue2
          namespace: eg
          region: us-east-2
          service_1_list:
          - 5
          - 6
          - 7
          service_1_map:
            a: 1
            b: 6
            c: 7
            d: 8
          service_1_name: mixin-2
          service_2_list:
          - 4
          - 5
          - 6
          service_2_map:
            a: 4
            b: 5
            c: 6
          service_2_name: service-2-override-2
          stage: staging
          tenant: tenant2

....

Show only stacks with terraform components

atmos describe stacks --component-types=terraform

Show only stacks with helmfile components

atmos describe stacks --component-types=helmfile

Show only a specific stack with all the components with all the component sections

atmos describe stacks -s=tenant2/ue2/staging

Show only the stacks where a specific component is configured (with all component sections)

atmos describe stacks --components=infra/vpc

Show only the stacks where the specific components are configured (with all component sections)

atmos describe stacks --components=echo-server,infra/vpc

Show only the specific sections for the components in all stacks

atmos describe stacks --components=echo-server,infra/vpc --sections=vars,settings
atmos describe stacks --components=test/test-component-override-3 --sections=inheritance
atmos describe stacks --components=test/test-component-override-3 --sections=component
atmos describe stacks --components=test/test-component-override-3 --sections=deps

Write the result to a file (in YAML format)

atmos describe stacks --sections=vars,settings --file=stacks.yaml

Write the result to a file (in JSON format)

atmos describe stacks --sections=vars,settings --format=json --file=stacks.json

Show all configured stacks (by specifying a non existing component in the filter)

atmos describe stacks --components=none

tenant1/ue2/dev: {}
tenant1/ue2/prod: {}
tenant1/ue2/staging: {}
tenant2/ue2/dev: {}
tenant2/ue2/prod: {}
tenant2/ue2/staging: {}

Show all components in all stacks with just the component names (by specifying a non existing section in the filter)

atmos describe stacks --sections=none

tenant1/ue2/dev:
  components:
    helmfile:
      echo-server: {}
      infra/infra-server: {}
      infra/infra-server-override: {}
    terraform:
      infra/vpc: {}
      mixin/test-1: {}
      mixin/test-2: {}
      test/test-component: {}
      test/test-component-override: {}
      test/test-component-override-2: {}
      test/test-component-override-3: {}
      top-level-component1: {}
tenant1/ue2/prod:
  components:
    helmfile:
      echo-server: {}
      infra/infra-server: {}
      infra/infra-server-override: {}
    terraform:
      infra/vpc: {}
      mixin/test-1: {}
      mixin/test-2: {}
      test/test-component: {}
      test/test-component-override: {}
      test/test-component-override-2: {}
      test/test-component-override-3: {}
      top-level-component1: {}
tenant1/ue2/staging:
  components:
    helmfile:
      echo-server: {}
      infra/infra-server: {}
      infra/infra-server-override: {}
    terraform:
      infra/vpc: {}
      mixin/test-1: {}
      mixin/test-2: {}
      test/test-component: {}
      test/test-component-override: {}
      test/test-component-override-2: {}
      test/test-component-override-3: {}
      top-level-component1: {}
tenant2/ue2/dev:
  components:
    helmfile:
      echo-server: {}
      infra/infra-server: {}
      infra/infra-server-override: {}
    terraform:
      infra/vpc: {}
      mixin/test-1: {}
      mixin/test-2: {}
      test/test-component: {}
      test/test-component-override: {}
      test/test-component-override-2: {}
      test/test-component-override-3: {}
      top-level-component1: {}
tenant2/ue2/prod:
  components:
    helmfile:
      echo-server: {}
      infra/infra-server: {}
      infra/infra-server-override: {}
    terraform:
      infra/vpc: {}
      mixin/test-1: {}
      mixin/test-2: {}
      test/test-component: {}
      test/test-component-override: {}
      test/test-component-override-2: {}
      test/test-component-override-3: {}
      top-level-component1: {}
tenant2/ue2/staging:
  components:
    helmfile:
      echo-server: {}
      infra/infra-server: {}
      infra/infra-server-override: {}
    terraform:
      infra/vpc: {}
      mixin/test-1: {}
      mixin/test-2: {}
      test/test-component: {}
      test/test-component-override: {}
      test/test-component-override-2: {}
      test/test-component-override-3: {}
      top-level-component1: {}

Show only a specific component in all stacks with just the component name (by specifying a non existing section in the filter) - this shows in which stacks the specified component exists

atmos describe stacks --components=infra/vpc --sections=none

tenant1/ue2/dev:
  components:
    terraform:
      infra/vpc: {}
tenant1/ue2/prod:
  components:
    terraform:
      infra/vpc: {}
tenant1/ue2/staging:
  components:
    terraform:
      infra/vpc: {}
tenant2/ue2/dev:
  components:
    terraform:
      infra/vpc: {}
tenant2/ue2/prod:
  components:
    terraform:
      infra/vpc: {}
tenant2/ue2/staging:
  components:
    terraform:
      infra/vpc: {}

v1.4.3

11 Apr 13:45
b4786a3
Compare
Choose a tag to compare

what

  • Add --dry-run command-line flag to all commands and workflows

why

  • Helps debugging atmos commands and workflows
  • The --dry-run flag shows all the flow and commands without executing them and without writing files to the file system (e.g. varfiles and backend config are not written)
  • The --dry-run flag shows all the workflow steps without executing them

tests and examples

Click to expand
atmos terraform plan test/test-component-override -s=tenant1-ue2-dev --dry-run

Variables for the component 'test/test-component-override' in the stack 'tenant1/ue2/dev':

enabled: true
environment: ue2
namespace: eg
region: us-east-2
service_1_list:
- 1
- 2
- 3
service_1_map:
  a: 1
  b: 2
  c: 3
service_1_name: service-1-override-2
service_2_list:
- 1
- 2
- 3
service_2_map:
  a: 1
  b: 2
  c: 3
service_2_name: service-2-override
stage: dev
tenant: tenant1

Writing the variables to file:
examples/complete/components/terraform/test/test-component/tenant1-ue2-dev-test-test-component-override.terraform.tfvars.json

Executing command:
/usr/local/bin/terraform init -reconfigure

Command info:
Terraform binary: /usr/local/bin/terraform
Terraform command: plan
Arguments and flags: []
Component: test/test-component-override
Terraform component: test/test-component
Inheritance: test/test-component-override -> test/test-component
Stack: tenant1-ue2-dev
Stack path: examples/complete/stacks/tenant1/ue2/dev
Working dir: examples/complete/components/terraform/test/test-component

Using ENV vars:
TEST_ENV_VAR2=val2
TEST_ENV_VAR3=val3-override
TEST_ENV_VAR4=val4
TEST_ENV_VAR1=val1-override

Executing command:
/usr/local/bin/terraform workspace select test-component-override-workspace-override

Executing command:
/usr/local/bin/terraform plan -var-file tenant1-ue2-dev-test-test-component-override.terraform.tfvars.json -out tenant1-ue2-dev-test-test-component-override.planfile
atmos workflow terraform-plan-test-component-override-2-all-stacks -f workflow1 --dry-run

Executing the workflow 'terraform-plan-test-component-override-2-all-stacks' from 'examples/complete/workflows/workflow1.yaml'

description: Run 'terraform plan' on 'test/test-component-override-2' component in
  all stacks
steps:
- command: terraform plan test/test-component-override-2 -s tenant1-ue2-dev
  stack: ""
  type: ""
- command: terraform plan test/test-component-override-2 -s tenant1-ue2-staging
  stack: ""
  type: ""
- command: terraform plan test/test-component-override-2 -s tenant1-ue2-prod
  stack: ""
  type: ""
- command: terraform plan test/test-component-override-2 -s tenant2-ue2-dev
  stack: ""
  type: ""
- command: terraform plan test/test-component-override-2 -s tenant2-ue2-staging
  stack: ""
  type: ""
- command: terraform plan test/test-component-override-2 -s tenant2-ue2-prod
  stack: ""
  type: ""
stack: ""

Executing workflow step: terraform plan test/test-component-override-2 -s tenant1-ue2-dev

Executing command:
atmos terraform plan test/test-component-override-2 -s tenant1-ue2-dev

Executing workflow step: terraform plan test/test-component-override-2 -s tenant1-ue2-staging

Executing command:
atmos terraform plan test/test-component-override-2 -s tenant1-ue2-staging

Executing workflow step: terraform plan test/test-component-override-2 -s tenant1-ue2-prod

Executing command:
atmos terraform plan test/test-component-override-2 -s tenant1-ue2-prod

Executing workflow step: terraform plan test/test-component-override-2 -s tenant2-ue2-dev

Executing command:
atmos terraform plan test/test-component-override-2 -s tenant2-ue2-dev

Executing workflow step: terraform plan test/test-component-override-2 -s tenant2-ue2-staging

Executing command:
atmos terraform plan test/test-component-override-2 -s tenant2-ue2-staging

Executing workflow step: terraform plan test/test-component-override-2 -s tenant2-ue2-prod

Executing command:
atmos terraform plan test/test-component-override-2 -s tenant2-ue2-prod

v1.4.2

05 Apr 02:44
8c0796e
Compare
Choose a tag to compare

what

  • Add init_run_reconfigure CLI config
  • Update stack_name_pattern
  • Disable running terraform plan and terraform workspace on abstract components

why

  • init_run_reconfigure CLI config allows enabling/disabling the -reconfigure argument for terraform init when running it before running other terraform commands
  • Don't use the default stack_name_pattern because it used {tenant} which is not available for all clients
  • Running terraform plan and terraform workspace on abstract components creates terraform workspaces which is not needed

v1.4.1

04 Apr 17:34
e7cfb9b
Compare
Choose a tag to compare

what

  • Add settings.spacelift.stack_name_pattern
  • Fix parsing YAML config and detection of stacks when the stack name (on the command line) is the same as the YAML config file name in a subfolder

why

  • settings.spacelift.stack_name_pattern allows overriding Spacelift stack names. Supported tokens: {namespace}, {tenant}, {environment}, {stage}, {component}
components:
  terraform:
    "test/test-component-override-2":
      settings:
        spacelift:
          workspace_enabled: true
          # `stack_name_pattern` overrides Spacelift stack names
          # By specifying the following `stack_name_pattern`, the final Spacelift stack name will be
          # `tenant1-ue2-dev-new-component` instead of `tenant1-ue2-dev-test-test-component-override-2`
          # By default (if `stack_name_pattern` is not specified), the stack name is generated using the pattern {tenant}-{environment}-{stage}-{component}
          # Supported tokens: {namespace}, {tenant}, {environment}, {stage}, {component}
          stack_name_pattern: "{tenant}-{environment}-{stage}-new-component"

If the stack name pattern is specified incorrectly or not specific enough, an error like this will be thrown:

Duplicate Spacelift stack name 'tenant2-ue2-new-component' for component 'test/test-component-override-2' in the stack 'tenant2/ue2/prod'.
Check if the component name is correct and the Spacelift stack name pattern 'stack_name_pattern={tenant}-{environment}-new-component' is specific enough.
Did you specify the correct context tokens {namespace}, {tenant}, {environment}, {stage}, {component}?
  • When a stack name on the command line (e.g. atmos terraform plan test/test-component -s tenant1-ue2-dev) was the same as the name of the YAML config file in a subfolder inside the stacks folder, the stack was incorrectly detected (throwing an error "The stack 'xxx' does not exist") because it was considered as the folder path and not as a logical stack name (which is detected from the context)

v1.4.0

11 Mar 15:47
c9c63b0
Compare
Choose a tag to compare

what

  • Add workflows
  • Define workflows in YAML
  • Support two types of workflows: atmos and shell
  • Allow specifying the atmos stack in 3 different ways:
    • on the command line in the command attribute in the workflow steps
    • as stack attribute in each workflow step
    • as stack attribute in the workflow itself
  • Update atmos terraform shell command

why

  • Allow sequential execution of atmos and shell commands
  • Update atmos terraform shell command to use the bash shell by default on Unix systems if the SHELL ENV var is not defined

test

atmos workflow test-1 -f workflow1
Executing the workflow 'test-1' from 'examples/complete/workflows/workflow1.yaml'

description: Test workflow
steps:
- command: echo Command 1
  stack: ""
  type: shell
- command: echo Command 2
  stack: ""
  type: shell
- command: echo Command 3
  stack: ""
  type: shell
- command: echo Command 4
  stack: ""
  type: shell
- command: echo Command 5
  stack: ""
  type: shell
stack: ""


Executing workflow step: echo Command 1

Executing command:
/bin/echo Command 1
Command 1

Executing workflow step: echo Command 2

Executing command:
/bin/echo Command 2
Command 2

Executing workflow step: echo Command 3

Executing command:
/bin/echo Command 3
Command 3

Executing workflow step: echo Command 4

Executing command:
/bin/echo Command 4
Command 4

Executing workflow step: echo Command 5

Executing command:
/bin/echo Command 5
Command 5


atmos workflow -f workflow1 terraform-plan-all-tenant1-ue2-dev
Executing workflow step: terraform plan test/test-component-override-2
Stack: tenant1-ue2-dev

Executing command:
/Users/andriyknysh/Documents/Projects/Go/bin/atmos terraform plan test/test-component-override-2 -s tenant1-ue2-dev

Variables for the component 'test/test-component-override-2' in the stack 'tenant1/ue2/dev':

enabled: true
environment: ue2
namespace: eg
region: us-east-2
service_1_list:

v1.3.30

06 Mar 04:59
fb2efbb
Compare
Choose a tag to compare

what

  • Add atmos terraform generate varfile command
  • Add atmos helmfile generate varfile command
  • The commands support -f argument to write to a specific file instead of generating the file name from the context
  • General cleanup

why

  • The command allow generating varfile for terraform and helmfile components and writing it to files in the components folders, or any file name specified by the -f command line argument (--file for the long version)
  • Use atmos patterns of generate and describe to generate config and describe config/settings
  • These commands replace the old/obsolete command atmos terraform write varfile

v1.3.29

21 Feb 20:45
c15a3c3
Compare
Choose a tag to compare

v1.3.28

21 Feb 15:32
c15a3c3
Compare
Choose a tag to compare

🚀 Enhancements

Fix Terraform workspace for remote state for derived components in subfolders @aknysh (#121)

what

  • Fix Terraform workspace for remote state for derived components in subfolders
  • General code improvements

why

  • Terraform workspace for remote state for derived components in subfolders was calculated differently from the terraform state for atmos terraform commands (leading to errors/failures in remote-state.tf for derived components in subfolders
  • Use the same code to calculate terraform workspace for all CLI commands: terraform plan/apply, describe component, and for component-Processor which is used in remote-state and backend

1.3.28

21 Feb 15:35
c15a3c3
Compare
Choose a tag to compare
Fix Terraform workspace for remote state for derived components in su…