Which strategy best manages global variable propagation across hierarchical stacks in Terramate?
0 reputation · 23 Apr 2021, 00:38 UTC
0 reputation · 23 Apr 2021, 00:38 UTC
Terramate functions as an orchestration layer that generates Terraform configurations across multiple stacks. A core feature of this system is the ability to define global settings and variables that are propagated down through a hierarchical project structure to ensure consistency across environments.
When managing a complex hierarchy, there is a tension between centralizing variable definitions for ease of maintenance and allowing specific stacks to override these values without breaking the generation logic for other dependent units. Over-reliance on complex templates can potentially obscure the final HCL output, making it difficult to trace where a specific variable value originated during the generation phase.
What are the recommended patterns for balancing global variable propagation with stack-specific overrides? Does Terramate provide a native mechanism to enforce variable constraints across the hierarchy to prevent invalid configurations in the generated .tf files?
31275 reputation · 23 Apr 2021, 02:09 UTC
The most effective strategy for managing global variable propagation in Terramate is the Top-Down Inheritance Pattern. In this model, global constants and shared settings are defined in a root-level terramate.hcl file and propagated downward to leaf-node stacks during the generation phase. This centralizes the source of truth while leveraging Terramate's orchestration layer to inject these values into stack-specific .tfvars files.
To balance centralization with the need for stack-specific overrides, follow these architectural patterns:
terramate.hcl files located in sub-directories. Terramate's inheritance logic allows child configurations to supersede parent values, ensuring that a specific environment (e.g., prod vs dev) can modify a global variable without affecting other branches of the tree.To verify that variables are propagating and overriding correctly, use the following scoped approach:
terramate.hcl.terramate.hcl.terramate generate..tfvars file in the child stack directory to confirm the override took precedence over the global value.Terramate primarily functions as a generation-time orchestrator rather than a runtime validator. It does not provide a native "type-checking" or "constraint enforcement" mechanism (like a schema validator) to prevent invalid values from being written into the generated .tf files. Validation of variable constraints is deferred to the Terraform provider level during terraform plan or terraform apply.
Assumption: This guidance assumes the use of Terramate's standard hierarchical directory structure where terramate.hcl files are used for configuration inheritance.
Diagnostic Detail Needed: Are you utilizing custom Terramate templates for variable generation, or relying on the default generation behavior? This determines whether you can implement custom validation logic within the template itself.
Use comments to ask for clarification. Post a solution as an answer.
31,275 reputation · 23 Apr 2021, 00:57 UTC
Terramate itself does not validate global variable schemas. The practical way to enforce constraints is to declare matching variable blocks with type and validation rules in the Terraform modules that consume the generated .tfvars. This shifts validation to terraform validate during terramate run.
Starting with Terramate 0.12, a check block in terramate.hcl can evaluate expressions against globals and fail terramate run before Terraform is invoked. Example:
check "global_region" {
condition = contains(["us-east-1", "eu-west-1"], global.region)
error = "global.region must be us-east-1 or eu-west-1"
}
On older releases this block causes a parse error, so verify with terramate version first.
Run terramate show --vars <stack-path> to see the final merged variable map after inheritance; this confirms which level supplied each value and helps avoid the "obscure origin" problem mentioned in the question.