Releases: cloudposse/atmos
Releases · cloudposse/atmos
v1.4.5
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
orvars
// 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
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
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
what
- Add
init_run_reconfigure
CLI config - Update
stack_name_pattern
- Disable running
terraform plan
andterraform workspace
on abstract components
why
init_run_reconfigure
CLI config allows enabling/disabling the-reconfigure
argument forterraform 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
andterraform workspace
on abstract components creates terraform workspaces which is not needed
v1.4.1
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 thestacks
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 thecontext
)
v1.4.0
what
- Add workflows
- Define workflows in YAML
- Support two types of workflows:
atmos
andshell
- 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
- on the command line in the
- Update
atmos terraform shell
command
why
- Allow sequential execution of
atmos
andshell
commands - Update
atmos terraform shell
command to use thebash
shell by default on Unix systems if theSHELL
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
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 ofgenerate
anddescribe
to generate config and describe config/settings - These commands replace the old/obsolete command
atmos terraform write varfile
v1.3.29
what & why
v1.3.28
🚀 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 inremote-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 forcomponent-Processor
which is used inremote-state
andbackend
1.3.28
Fix Terraform workspace for remote state for derived components in su…