Terramate v0.8.0
The latest release of Terramate CLI v0.8.0 includes significant improvements to managing configuration with environment variables, offering users more flexibility and control. Let's explore some notable updates introduced in this version:
Configuring Environment Variables
Previously, you had to define environment variables in the terramate.tm.hcl
file located at the root of your project. While this allowed for global availability across all stacks, it lacked granularity for stack-specific configurations. In v0.8.0
, you can now define environment variables everywhere in your Terramate project. Think project-wide, directory and stack-specific configuration, empowering you to tailor variables to specific stacks and their nested structures.
Example: Project-Level vs. Stack-Level Configuration
- Project-Level Configuration (Previous Method):
# terramate.tm.hcl located at the root of your Terramate project
terramate {
config {
run {
env {
FOO = "BAR"
}
}
}
}
This setup made FOO
available globally across all stacks.
- Stack-Level Configuration (New Method):
# stack.tm.hcl located in a stack directory
stack {
name = "Bob"
description = "Bob's first stack"
id = "f4b30f69-9f40-49b0-ab98-395ff07c784f"
}
terramate {
config {
run {
env {
FOO = "BAR"
}
}
}
}
Here, FOO
is for the stack "Bob" and its nested stacks.
Evaluation Rules and Flexibility
When you define values in the terramate.config.run.env
block, Terramate follows clear rules for evaluation:
- Higher-level variables pass down to all nested stacks, ensuring consistent settings throughout.
- Redefining variables at the same level results in conflict.
- Redefining variables at lower levels replaces their previous values, allowing for precise customization.
- Terramate evaluates values only at the stack level, optimizing performance.
- Using
null
as a value for any variable signifies it is unset, preventing its export. - To unset a variable at lower levels, assign them to be
unset
ornull
.
Utilizing Namespaces
Use the env
namespace to access all environment variables available to the process. It is read-only and available at run time. For example, you can read any variable passed to the terramate
command or exposed to the process by your operating system.
Use it to dynamically assign variables in the stack configuration at runtime, thus adding more flexibility to your Terraform workflows.
# terramate.tm.hcl or any stack configuration
terramate {
config {
run {
env {
TF_VAR_environment = env.ENVIRONMENT
}
}
}
}
$ ENVIRONMENT=production terramate run -- bash -c 'echo $TF_VAR_environment'
terramate: Entering stack in /stacks/a
terramate: Executing command "bash -c echo $TF_VAR_environment"
production
terramate: Entering stack in /stacks/b
terramate: Executing command "bash -c echo $TF_VAR_environment"
production
Full Support for OpenTofu
We just added full support for OpenTofu to Terramate CLI and Terramate Cloud. You can now sync OpenTofu plans to Terramate Cloud using the --tofu-plan-file
argument in addition to the previously existing --terramate-plan-file
argument.
Please see our reference architecture at terramate-quickstart-aws for an example on how to use Terramate with OpenTofu.
Upgrade to Terramate v0.8.0
Upgrade to Terramate v0.8.0 for better environment variable management in Terraform. Enjoy more control and efficiency in your deployments. Happy coding!
Join the Community
We’re committed to continually improving Terramate to meet your evolving needs. Dive into the Terramate community and connect with like-minded individuals who share your passion for infrastructure management. Whether you’re a seasoned pro or just getting started, our community is here to support you every step of the way. Join us on Discord and be part of the conversation!