1.3.0
Improvements and new features @aknysh (#66)
what
- Improvements and new features
why
- For terraform commands, put the additional arguments and flags at the end of the command. This allows to use, for example,
-var=service_1_name=service-1-override-3
to override the variables defined in terraform and YAML config
atmos terraform deploy top-level-component1 -s tenant1/ue2/dev -var=service_1_name=service-1-override-3
- Add flags and logic to auto generate TF backend file
Writing backend config to file:
./examples/complete/components/terraform/test/test-component/backend.tf.json
Controlled by the CLI config:
# Can also be set using `ATMOS_COMPONENTS_TERRAFORM_AUTO_GENERATE_BACKEND_FILE` ENV var, or `--auto-generate-backend-file` command-line argument
auto_generate_backend_file: false
- Add
remote_state_backend
andremote_state_backend_type
YAML config sections. They can be used to specify a different backend (different attributes, or even a completely different backend type) for remote state. It's useful for the privileged components where we use different attributes (e.g.role_arn
orprofile
) during the cold-start and during the normal operations to get the remote state of the privileged components
# Override backend for this component
backend_type: static # s3, remote, vault, static, etc.
backend:
static:
val1: 1
val2: "2"
val3: true
val4: ""
val5: null
# Override remote state backend for this component
remote_state_backend_type: static # s3, remote, vault, static, etc.
remote_state_backend:
static:
val1: 1
val2: "2"
val3: true
val4: ""
val5: 5
The new remote_state_backend
section in YAML is similar to the backend
section - you can specify it in globals, stage globals, or override per component (which all gets deep-merged into the final remote state backend for the component). The two sections are separate and the attributes from them are not merged together