github cloudposse/atmos v1.129.0

latest releases: v1.130.0, v1
one day ago
Improve `!terraform.output` Atmos YAML function. Implement `static` remote state backend for `!terraform.output` and `atmos.Component` functions @aknysh (#863)

what

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:


image


image


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:


image


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")) }}'

Don't miss a new atmos release

NewReleases is sending notifications on new releases.