Improve `!terraform.output` Atmos YAML function. Implement `static` remote state backend for `!terraform.output` and `atmos.Component` functions @aknysh (#863)
what
-
Improve
!terraform.output
Atmos YAML function -
Implement
static
remote state backend for!terraform.output
andatmos.Component
functions -
Add more advanced usage examples of the
!template
Atmos YAML function -
Fix the error messages when the user specifies an invalid component names in
atmos terraform plan/apply
-
Update docs
why
Improve !terraform.output
Atmos YAML function
The !template
Atmos YAML function now can be called with either two or three parameters:
# Get the `output` of the `component` in the current stack
!terraform.output <component> <output>
# Get the `output` of the `component` in the provided stack
!terraform.output <component> <stack> <output>
Examples:
components:
terraform:
my_lambda_component:
vars:
vpc_config:
# Output of type string
security_group_id: !terraform.output security-group/lambda id
security_group_id2: !terraform.output security-group/lambda2 {{ .stack }} id
security_group_id3: !terraform.output security-group/lambda3 {{ .atmos_stack }} id
# Output of type list
subnet_ids: !terraform.output vpc private_subnet_ids
# Output of type map
config_map: !terraform.output config {{ .stack }} config_map
NOTE: Using the .stack
or .atmos_stack
template identifiers to specify the stack is the same as calling the !template
function with two parameters without specifying the current stack, but without using Go
templates.
If you need to get an output of a component in the current stack, using the !template
function with two parameters
is preferred because it has a simpler syntax and executes faster.
Implement static
remote state backend for !terraform.output
and atmos.Component
functions
Atmos supports brownfield configuration by using the remote state of type static
.
For example:
When the functions are executed, Atmos detects that the test
component has the static
remote state configured,
and instead of executing terrafrom output
, it just returns the static values from the remote_state_backend.static
section.
Executing the command atmos describe component test2 -s <stack>
produces the following result:
Add more advanced usage examples of the !template
Atmos YAML function
The !template
Atmos YAML function can be used to make your stack configuration DRY and reusable.
For example, suppose we need to restrict the Security Group ingresses on all components provisioned in the infrastructure
(e.g. EKS cluster, RDS Aurora cluster, MemoryDB cluster, Istio Ingress Gateway) to a specific list of IP CIDR blocks.
We can define the list of allowed CIDR blocks in the global settings
section (used by all components in all stacks)
in the allowed_ingress_cidrs
variable:
settings:
allowed_ingress_cidrs:
- "10.20.0.0/20" # VPN 1
- "10.30.0.0/20" # VPN 2
We can then use the !template
function with the following template in all components that need their Security Group
to be restricted:
# EKS cluster
# Allow ingress only from the allowed CIDR blocks
allowed_cidr_blocks: !template '{{ toJson .settings.allowed_ingress_cidrs }}'
# RDS cluster
# Allow ingress only from the allowed CIDR blocks
cidr_blocks: !template '{{ toJson .settings.allowed_ingress_cidrs }}'
# Istio Ingress Gateway
# Allow ingress only from the allowed CIDR blocks
security_group_ingress_cidrs: !template '{{ toJson .settings.allowed_ingress_cidrs }}'
The !template
function and the '{{ toJson .settings.allowed_ingress_cidrs }}'
expression allows you to
use the global allowed_ingress_cidrs
variable and the same template even if the components have different
variable names for the allowed CIDR blocks (which would be difficult to implement using
Atmos inheritance or other Atmos design patterns).
NOTE:
To append additional CIDRs to the template itself, use the list
and Sprig concat
functions:
allowed_cidr_blocks: !template '{{ toJson (concat .settings.allowed_ingress_cidrs (list "172.20.0.0/16")) }}'