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

v0.7.1

chmod kubeconfig to 600 to avoid warning messages @Nuru (#10)

what

• chmod kubeconfig to 600 to avoid warning messages

why

• Avoid warnings like

  WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /dev/shm/uw2-demo-kubecfg
  WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /dev/shm/uw2-demo-kubecfg

v0.7.0

Update helmfile CLI @aknysh (#9)

what

• Rename kubeconfig-profile-pattern to helm-aws-profile-pattern
• Use helm-aws-profile-pattern to select an AWS profile for helmfile commands

why

• helm-aws-profile-pattern is used not only for kubeconfig, but also for helm and helmfile
• By default, assume the role specified by the helm-aws-profile-pattern when calling the helmfile CLI (still having the option to specify a different AWS profile)