v0.16.0

Fix `terraform backend generate component` command. Add `version` command @aknysh (#23)

what

• Fix terraform backend generate component command while keeping JSON pretty printing
• Add version command

why

• jq in terraform backend generate component command was just outputting to stdout, not to the backend file
• Simplify terraform backend generate component command
• atmos version command is useful to show the CLI version

references

• Closes #18

test

 > atmos terraform backend generate component vpc -s uw2-demo
{
  "terraform": {
    "backend": {
      "s3": {
        "acl": "bucket-owner-full-control",
        "bucket": "xxxxx-uw2-root-tfstate",
        "dynamodb_table": "xxxxxx-uw2-root-tfstate-lock",
        "encrypt": true,
        "key": "terraform.tfstate",
        "region": "us-west-2",
        "role_arn": "arn:aws:iam::xxxxxxx:role/xxxxxx-gbl-root-terraform",
        "workspace_key_prefix": "vpc"
      }
    }
  }
}

> atmos version
0.16.0

v0.15.0

Fix `terraform backend generate component` job @aknysh (#22)

what

• Fix terraform backend generate component job

why

• a comma was missing in the jq command

v0.14.0

add pretty printing for backend.tf.json @mcalhoun (#20)

what

• Add pretty-printing of JSON in backend.tf.json file

why

• So that it is easier to read and any diffs are easier to view/reason about what has changed

v0.13.0

🚀 Enhancements

stack-config json schema @dylanbannon (#19)

what

Including a comprehensive stack config JSON schema.

why

The goal is to provide infrastructure for linting of config files used by atmos.

v0.12.0

Add `component` attribute to stack configs. Allow configuring and provisioning many instances of the same component. @aknysh (#15)

what

• Add component attribute to stack configs

why

• Allow specifying YAML configs and provisioning many instances of the same component type.
  For example, we can specify the following config to provision many different instances of AWS Aurora clusters by referencing the common aurora-postgres component:

components:
  terraform:
    db1:
      component: aurora-postgres
      vars:
        instance_type: db.r4.large
        cluster_size: 1
    db2:
      component: aurora-postgres
      vars:
        instance_type: db.r4.large
        cluster_size: 1
    db3:
      component: aurora-postgres
      vars:
        instance_type: db.r1.large
        cluster_size: 1
    db4:
      component: aurora-postgres
      vars:
        instance_type: db.r8.large
        cluster_size: 1

and then use the following commands to plan/apply the database components:

atmos terraform plan db1 -s uw2-prod
atmos terraform apply db1 -s uw2-prod

atmos terraform plan db2 -s uw2-prod
atmos terraform apply db2 -s uw2-prod

atmos terraform plan db3 -s uw2-prod
atmos terraform apply db3 -s uw2-prod

v0.11.0

Publish Binary Release Artifact for Atmos @aknysh (#14)

what

• Publish Binary Release Artifact for Atmos

why

• Allow using the atmos binary in other projects and containers
• Speed up Docker image build time (building atmos binary takes time)

references

• https://cloudposse.atlassian.net/browse/CPCO-227
• https://github.com/cloudposse/atmos/releases/tag/0.0.2

0.0.2 Test CLI Build

what

• Test CLI build

why

• Build CLI and attach the binary to GitHub release

v0.10.0

Improve imports and deep-merging of variables of any complex types @aknysh (#13)

what

• Improve imports and deep-merging of variables of any complex types
• Use the latest variant2 features (recursive user-defined functions, list of file paths in config) for stack configuration module

why

• Simplify code
• Deep-merge any number of import files with any complex structures (maps/objects)
• Deep-merge all variables in this order: global-scoped, component-type-scoped, and component-scoped
• Deep-merge all backend attributes in this order: global-scoped, component-type-scoped, and component-scoped

references

• mumoshu/variant2#43

test

 ✗ . example ⨠ atmos stack config eks -s ue2-dev --config-type=vars
"cluster_kubernetes_version": "1.18"
"environment": "ue2"
"namespace": "eg"
"region": "us-east-2"
"stage": "dev"
"test-map":
  "a": "a4"
  "atr":
    "atr1": "1-1"
    "atr2": "2-4"
    "atr3": 3
    "atr4": 4
    "atr5": 5
    "list":
    - "1c"
  "atr-2":
    "atr1": 1
    "atr2": 2
  "b": "b2"
  "c": "c1"
  "d": "d4"
  "e": "e4"
  "f": "f4"
  "g": "g1"
  "list":
  - 4
  - 5
  - 6
  "list2":
  - 1
  - 2
  - 3

v0.9.0

Add `interactive` mode to Terraform commands. Add 10 levels of `imports` @aknysh (#12)

what

• Add interactive mode to Terraform commands
• Add 10 levels of imports

why

• Support interactive mode for TF commands that require user input (e.g. when moving TF state from local to remote state)
• The current 5 levels of imports were arbitrary and not enough in some cases

v0.8.0

Hierarchical imports. New stacks config format. Generic Terraform backend @aknysh (#11)

what

• Use hierarchical imports
• Use new stacks config format
• Add generic Terraform backend config
• Simplify

why

• Hierarchical imports - support import up to five level deep (so we can, for example, import environment globals into a stack, which in turn can import globals for the entire solution)

• Use new stacks config format - all stack config files use the same schema. No special config files, they are all the same and can be arbitrary named. All Terraform and helmfile vars, commands, and backends are defined in separate sections in any of the config files or imported config files (no pollution of Terraform variables with provided but not declared variables, which will be an error in TF 0.14). All sections in the config files and imported config files are merged together into configs consumed by the relevant modules in the CLI

• Add generic Terraform backend config - the ability to specify many different Terraform backends (e.g. s3, remote, vault) and select a particular one per component, stage, environment, or the entire solution