The Don’t Repeat Yourself (DRY) principle of software development states that code should be written once and not repeated. An important goal of the DRY principle is to improve the maintainability of code.
Some Terraform resources include repeatable nested blocks in their arguments. These nested blocks represent separate resources that are related to the containing resource. For example, Azure VNets contain a subnet block attribute that repeats for each subnet within the VNet. This can lead to repeated configuration blocks in a Terraform script, which violates the DRY principle.
Dynamic blocks are a solution for applying DRY in Terraform configuration scripts.
What we will cover:
Dynamic blocks in Terraform let you repeat configuration blocks inside a resource, provider, provisioned, or data source based on a variable, local, or expression you use inside them. Apart from keeping your configuration DRY, dynamic blocks also help you generate dynamic configurations based on your input, enabling your modules to accommodate several different use cases.
Terraform dynamic block components
Terraform dynamic blocks are supported inside of resource, data, provider, and provisioner blocks. A dynamic block consists of the following components:
| Component | Description |
| label
|
Specifies what kind of nested block to generate. In the above example, the label is “subnet”. A subnet resource will be generated for each element in the var.subnets variable.
|
| for_each
|
The complex value to iterate over. (More on Terraform for each.)
|
| iterator
|
(optional) Sets the name of a temporary variable that represents the current element. If not provided, the name of the variable defaults to the label of the dynamic block. An iterator has two attributes: key and value. Key is the element index. Value is the element value.
|
| content
|
Defines the body of each generated block.
|
A dynamic block can only generate attributes that belong to the resource type being created. It isn’t possible to generate meta-argument blocks like lifecycle. Some resource types have blocks with multiple levels of nesting.
The iterators for each block are important when working with multi-level nested blocks. The optional iterator component should be used to clearly define each level in the configuration and remove any ambiguities resulting from attributes with the same name as a parent block.
The configuration below illustrates a nested block example, with clearly defined iterators for each block.
dynamic "origin_group" {
for_each = var.load_balancer_origin_groups
iterator = outer_block
content {
name = outer_block.key
dynamic "origin" {
for_each = outer_block.value.origins
iterator = inner_block
content {
hostname = inner_block.value.hostname
}
}
}
}Having dynamic blocks in your configuration strengthens your Terraform code’s overall capabilities, making it easy to repeat blocks in your resource. They are a fundamental capability of Terraform, and you should leverage them when you want to repeat blocks inside a resource.
- Flexible and easy to re-use: Dynamic blocks allow you to define a block of code once and reuse it multiple times within your Terraform configuration.
- Simplified management of complex configurations: Dynamic blocks can significantly simplify the code for resources that require multiple nested blocks with similar structures.
- Reliability: Dynamic blocks help minimize the risk of misconfigurations by reducing the chances of errors that often occur when copying, pasting, and manually modifying large blocks of repetitive code.
What is one disadvantage of using dynamic blocks in Terraform?
One significant disadvantage of using dynamic blocks is that they can introduce complexity in debugging and readability. Because the code is generated dynamically, it can be harder to trace and understand the final configuration. This can make troubleshooting issues more challenging, as it may not be immediately clear how the dynamic generation logic translates into the actual resource definitions. While dynamic blocks offer powerful capabilities, they require careful implementation and thorough documentation to mitigate these potential downsides.
In a dynamic block, you can use the following parameters:
- for_each (required) – iterates over the value you are providing
- content (required) – block containing the body of each block that you are going to create
- iterator (optional) – temporary variable used as an iterator. If you omit it, the iterator will be the block name
- labels (optional) – list of strings that define the block labels.
You can have nested dynamic blocks or use dynamic blocks to avoid generating an optional block inside configurations.
Let’s take a look at the following example:
resource "helm_release" "nginx" {
name = "my-nginx"
chart = "nginx"
repository = "https://charts.bitnami.com/bitnami"
version = "13.2.12"
set {
name = "service.type"
value = "LoadBalancer"
}
set {
name = "replicaCount"
value = "2"
}
set {
name = "ingress.enabled"
value = "true"
}
}As you can see, a helm_release resource is used to deploy nginx in K8s, and it has three set blocks. This block can be easily repeated and generated dynamically by using a dynamic block. This is how you would rewrite the code using a dynamic block:
locals {
set = {
set1 = {
name = "service.type"
value = "LoadBalancer"
}
set2 = {
name = "replicaCount"
value = "2"
}
set3 = {
name = "ingress.enabled"
value = "true"
}
}
}
resource "helm_release" "nginx" {
name = "my-nginx"
chart = "nginx"
repository = "https://charts.bitnami.com/bitnami"
version = "13.2.12"
dynamic "set" {
for_each = local.set
content {
name = set.value.name
value = set.value.value
}
}
}This way, you can easily change a local variable instead of changing your resources. Of course, for this to be really reusable and dynamic, you should use variables for all resource parameters, and the for_each in the dynamic block should also happen on a variable.
Let’s see examples of using Terraform dynamic blocks in resource blocks and a data source
Example 1: Using Terraform dynamic block in resource blocks
The following code shows the configuration of an Azure VNet and four subnets. In this example, the subnet blocks are written out explicitly, creating repeated code.
resource "azurerm_virtual_network" "dynamic_block" {
name = "vnet-dynamicblock-example-centralus"
resource_group_name = azurerm_resource_group.dynamic_block.name
location = azurerm_resource_group.dynamic_block.location
address_space = ["10.10.0.0/16"]
subnet {
name = "snet1"
address_prefix = "10.10.1.0/24"
}
subnet {
name = "snet2"
address_prefix = "10.10.2.0/24"
}
subnet {
name = "snet3"
address_prefix = "10.10.3.0/24"
}
subnet {
name = "snet4"
address_prefix = "10.10.4.0/24"
}
}That same configuration using a dynamic block is shown below. Replacing the four subnet blocks with a dynamic block removes repeated attributes, leading to cleaner code that is easier to maintain.
The iterator is optional, and if you omit it, the iterator itself will become the name of the dynamic block. So if we were to omit the iterator above, in the content block for the name, we would have to use subnet.value.name instead of item.value.name
resource "azurerm_virtual_network" "dynamic_block" {
name = "vnet-dynamicblock-example-centralus"
resource_group_name = azurerm_resource_group.dynamic_block.name
location = azurerm_resource_group.dynamic_block.location
address_space = ["10.10.0.0/16"]
dynamic "subnet" {
for_each = var.subnets
iterator = item #optional
content {
name = item.value.name
address_prefix = item.value.address_prefix
}
}
}Here is the definition of the variable subnets:
variable "subnets" {
description = "list of values to assign to subnets"
type = list(object({
name = string
address_prefix = string
}))
}The values for the subnets variable are defined in a tfvars file. Sample values are:
subnets = [
{ name = "snet1", address_prefix = "10.10.1.0/24" },
{ name = "snet2", address_prefix = "10.10.2.0/24" },
{ name = "snet3", address_prefix = "10.10.3.0/24" },
{ name = "snet4", address_prefix = "10.10.4.0/24" }
]Example 2: Using Terraform dynamic block in data blocks
In the example below, we are using a dynamic block to filter AMIs in a data source based on some of their tags. If we get any matches, all these AMIs will be returned in a list that we can use further in our configuration code.
variable "ami_filters" {
description = "A list of tag filters for finding AMIs"
default = [
{
name = "tag:Purpose"
values = ["WebServer"]
},
{
name = "tag:Environment"
values = ["Prod"]
}
]
}
data "aws_ami" "custom_ami" {
most_recent = true
owners = ["self"]
dynamic "filter" {
for_each = var.ami_filters
content {
name = filter.value.name
values = filter.value.values
}
}
}Example 3: Creating an AWS Security Group with Terraform dynamic blocks
There are two ways in which you can define security group rules for AWS using Terraform:
- By using the security group resource and a dedicated security group rule resource
- By using only the security group resource (Note: This is the historical way of doing things, and it is not recommended anymore)
In the first case, the code will be similar to this:
resource "aws_security_group" "this" {
for_each = var.sg_params
vpc_id = each.value.vpc_id
tags = {
Name = each.key
}
}
resource "aws_security_group_rule" "this" {
for_each = var.sg_rule_params
type = each.value.type
from_port = each.value.from_port
to_port = each.value.to_port
protocol = each.value.protocol
cidr_blocks = each.value.cidr_blocks
security_group_id = aws_security_group.this[each.value.sg_name].id
}In the second case, the best way to do it would be to use dynamic blocks within the security group:
resource "aws_security_group" "this" {
for_each = var.sg_params
vpc_id = each.value.vpc_id
tags = {
Name = each.key
}
dynamic "ingress" {
for_each = [for rule in each.value.sg_rule_params : rule if rule.type == "ingress"]
content {
from_port = ingress.value.from_port
to_port = ingress.value.to_port
protocol = ingress.value.protocol
cidr_blocks = ingress.value.cidr_blocks
}
}
dynamic "egress" {
for_each = [for rule in each.value.sg_rule_params : rule if rule.type == "egress"]
content {
from_port = egress.value.from_port
to_port = egress.value.to_port
protocol = egress.value.protocol
cidr_blocks = egress.value.cidr_blocks
}
}
}In this example, we are using two dynamic blocks, one for the ingress traffic and the other for the egress traffic, and a single variable for everything related to the security groups. Keep in mind that AWS warns us against using only the aws_security_group for adding rules because these rules struggle with managing multiple CIDR blocks.
Example 4: Using Terraform dynamic block with lists
Dynamic blocks don’t care if you are using maps, lists, or sets when you are doing the for_each, so for this example, we will use a map(object) variable for defining our variable, and we will use list(object) to iterate through for our dynamic block.
resource "aws_route_table" "this" {
for_each = var.route_tables
vpc_id = each.value.vpc_id
dynamic "route" {
for_each = each.value.routes
content {
cidr_block = route.value.cidr_block
gateway_id = route.value.gateway_id
}
}
}
variable "route_tables" {
type = map(object({
vpc_id = string
routes = list(object({
cidr_block = string
gateway_id = string
}))
}))
default = {
route_table_1 = {
vpc_id = "vpc-0a1b2c3d4e5f6g7h8"
routes = [
{
cidr_block = "0.0.0.0/0"
gateway_id = "igw-0123456789abcdef0"
},
{
cidr_block = "10.0.0.0/16"
gateway_id = "local"
}
]
},
}
}As you can see, we are building the route table rules using a list.
Example 5: Using conditional statements inside Terraform dynamic blocks
We’ve already built an example that used a conditional statement in the for_each block when we went through the security group example. In this example, we will use a ternary operator to dynamically choose a variable based on a condition in a dynamic block.
resource "aws_instance" "this" {
ami = var.ami
instance_type = var.instance_type
dynamic "ebs_block_device" {
for_each = length(var.ebs_volumes) > 0 ? var.ebs_volumes : [
{
device_name = "/dev/sdf"
volume_size = 8
}
]
content {
device_name = ebs_block_device.value.device_name
volume_size = ebs_block_device.value.volume_size
}
}
}In this example, if we have any values inside our var.ebs_volumes, we will use them to dynamically generate the ebs volumes based on them. Otherwise, we will use a predefined device and volume_size.
In Terraform, dynamic blocks are used to dynamically generate nested content within a resource or module, allowing you to iterate over lists to create repeated configurations. On the other hand, for loops are used in expressions to build lists or maps from existing collections. While dynamic blocks focus on the structure of resources, for loops are primarily used for transforming or filtering data.
Read more: Terraform For Loop – Expression Overview with Examples
Here are some of the best practices around Terraform dynamic blocks you should consider:
- Don’t overuse dynamic blocks — As mentioned before, you should use dynamic blocks in every block that may be repeated (you may even need to not create a block, and you can also do this with dynamic blocks). However, overusing them and going for deep levels of nesting can hurt your overall understanding of the configuration in the future, and it will be harder to explain to other colleagues.
- Use a meaningful name for your iterator — If you want to skip using an iterator, that’s totally fine because it will reuse the name of the block, but if you do use it, it should have a meaningful name.
- Validate your data — Dynamic blocks rely on data to be generated. If you are using a variable, take advantage of the validation block and put different conditions in place. On the other hand, if you are using a local, ensure that you perform data checks through loops and functions.
- Scalability considerations — Dynamic blocks allow you to create multiple instances of resources or resource configurations, so you should be aware of potential scalability concerns, especially in cloud environments where provisioning many resources can affect performance and cost and even hit service limits.
- Consistent documentation — Thoroughly document your Terraform code, especially your nested dynamic blocks, to make things easier to understand for your team.
Spacelift supports all Terraform FOSS features, and dynamic blocks are one of them, so you can easily use dynamic blocks and orchestrate your Terraform code with Spacelift.
With Spacelift, you get:
- Policies to control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications
- Stack dependencies to build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that, for example, generates your ec2 instances using Terraform and combines it with Ansible to configure them
- Self-service infrastructure via Blueprints, or Spacelift’s Kubernetes operator, enabling your developers to do what matters – developing application code while not sacrificing control
- Creature comforts such as contexts (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code
- Drift detection and optional remediation
If you want to learn more about what you can do with Spacelift, check out this article.
A dynamic block is a great way to apply the DRY principle in Terraform configuration scripts. Implementing a dynamic block where appropriate removes repeated code leading to configurations that are easier to read, maintain, and reuse – just as the DRY principle aims to do.
If you want to elevate your Terraform management, create a free account for Spacelift today or book a demo with one of our engineers.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. OpenTofu is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.
Manage Terraform Better and Faster
If you are struggling with Terraform automation and management, check out Spacelift. It helps you manage Terraform state, build more complex workflows, and adds several must-have capabilities for end-to-end infrastructure management.
