Terraform Optional Blocks with Conditional Variables

• Introduction
• Step-by-Step Guide
• Code Example
• Additional Notes
• Summary
• Conclusion
• References

In Terraform, you can create optional blocks within resources using a combination of variables and dynamic blocks. This approach allows you to define a flexible configuration where certain blocks are only included if specific data is provided.

1. Define a variable with a default empty list:

variable "optional_blocks" {
  type    = list(object({
    key = string
    value = string
  }))
  default = []
}

2. Use a dynamic block within your resource:

resource "example_resource" "example" {
  # ... other resource properties ...

  dynamic "optional_block" {
    for_each = var.optional_blocks
    content {
      key   = optional_block.value.key
      value = optional_block.value.value
    }
  }
}

3. Populate the variable with data if needed:

variable "optional_blocks" {
  # ... type definition ...
  default = [
    {
      key   = "example_key"
      value = "example_value"
    }
  ]
}

Explanation:

• The variable block defines an optional input with a default empty list.
• The dynamic block iterates over the optional_blocks variable.
• If optional_blocks is empty, no blocks are created.
• If optional_blocks contains data, a block is created for each element.
• The content block defines the structure of the optional block.

Key points:

• Use for_each to iterate over the variable.
• Set a default empty list to make the block optional.
• Use content to define the block's structure.
• Populate the variable with data to include the block.

The code defines a Terraform variable called "optional_ingress_rules" that accepts a list of objects, each representing an ingress rule for an AWS security group. The variable has a default value of an empty list. It then uses a dynamic block within the "aws_security_group_rule" resource to iterate over the "optional_ingress_rules" variable. For each rule defined in the variable, it creates an ingress rule for the security group. If the variable is empty, no additional ingress rules are created. This allows for dynamically creating optional ingress rules based on user input.

This example demonstrates how to use a variable with a default empty list to dynamically create ingress rules for an AWS security group.

1. Define the variable:

variable "optional_ingress_rules" {
  type = list(object({
    from_port   = number
    to_port     = number
    protocol    = string
    cidr_blocks = list(string)
  }))
  default = []
}

2. Use a dynamic block within the aws_security_group_rule resource:

resource "aws_security_group" "example" {
  name = "example"
  description = "Example Security Group"
}

resource "aws_security_group_rule" "ingress" {
  for_each = { for i, rule in var.optional_ingress_rules : i => rule }

  type              = "ingress"
  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.example.id
}

3. Populate the variable with data (optional):

variable "optional_ingress_rules" {
  # ... type definition ...
  default = [
    {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    },
    {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["10.0.0.0/16"]
    }
  ]
}

Explanation:

• The optional_ingress_rules variable defines the structure of optional ingress rules.
• The dynamic block iterates over the optional_ingress_rules variable.
• If optional_ingress_rules is empty, no additional ingress rules are created.
• If optional_ingress_rules contains data, an aws_security_group_rule resource is created for each element, defining an ingress rule with the specified properties.

This example demonstrates how to use a variable with a default empty list to dynamically create optional resources based on user input. You can adapt this pattern to other resources and use cases as needed.

These notes expand on the provided information, offering a more comprehensive understanding and practical tips:

Understanding the Pattern:

• Flexibility: This pattern shines when you need to conditionally include blocks in your resources based on user input or other dynamic factors. It avoids hardcoding and promotes reusability.
• Empty List as Default: Setting the variable's default to an empty list ([]) is crucial. It signals to Terraform that the block is optional. If a user doesn't provide data for this variable, no blocks will be created, preventing errors.
• Beyond Simple Structures: While the examples use basic object types, you can have more complex nested structures within your optional_blocks variable to accommodate intricate configurations.

Best Practices:

• Meaningful Naming: Choose descriptive names for your variables and block labels to enhance code readability and clarity.
• Validation: For added robustness, consider using Terraform's validation features to enforce constraints on the data passed to the optional_blocks variable (e.g., data types, allowed values).
• Comments: Document your code clearly, especially the purpose of the optional block and the expected structure of the data in the variable. This helps with maintainability.

Common Use Cases:

• Conditional Resource Creation: Create resources like security group rules, load balancer listeners, or database replicas only when specific conditions are met.
• Environment-Specific Configurations: Define different settings or blocks for various environments (development, staging, production) using the same Terraform codebase.
• Modular Code: Create reusable modules where certain blocks are optional, allowing users to customize the module's behavior without modifying its core logic.

Beyond the Basics:

• Nested dynamic Blocks: You can nest dynamic blocks within each other to create even more flexible and complex configurations.
• Conditional Logic within dynamic Blocks: Use Terraform's conditional expressions (e.g., if, ternary operator) within the content block of a dynamic block to further customize the generated configuration based on the input data.

Example in Context:

The AWS Security Group example highlights a practical application. Instead of defining separate ingress rules for every scenario, you provide a single variable where users can specify the rules they need. This makes your Terraform code adaptable to different network configurations.

This article explains how to define optional, repeatable blocks within Terraform resources using a combination of variables and dynamic blocks.

Here's how it works:

1. Define a variable with a default empty list: This variable will hold the data for the optional blocks. Setting an empty list as the default ensures the block is optional.
2. Use a dynamic block within your resource: The dynamic block, combined with a for_each loop referencing the variable, allows for creating multiple instances of a block based on the variable's content.
3. Populate the variable with data if needed: If you need to include the optional block, populate the variable with the desired data. Each element in the list will result in a separate block being created.

Key advantages of this approach:

• Flexibility: Easily add, remove, or modify optional blocks by simply updating the variable data.
• Cleanliness: Avoids repetitive code by dynamically generating blocks based on the provided data.
• Readability: Improves code clarity by separating the optional block definition from the main resource configuration.

This technique allows for creating more modular and reusable Terraform code by providing a structured way to handle optional configurations.

This approach enhances Terraform code flexibility and organization by enabling the creation of optional, repeatable blocks within resources. By defining a variable with a default empty list and leveraging dynamic blocks, users can conditionally include or exclude specific configurations, leading to cleaner, more maintainable, and reusable infrastructure code. This method proves particularly useful for managing complex deployments where resource configurations might vary based on specific requirements or environments.

• Execute Dynamic Block Based on Whether or Not A Variable is Null ... | Posted by u/[Deleted Account] - 1 vote and 9 comments
• terraform0.12+ - How to handle optional dynamic blocks in terraform ... | Dec 18, 2020 ... The first step would be to tell Terraform what type of value this variable expects. While it's often okay to omit an explicit type for a ...
• Optional dynamic blocks : r/Terraform | Posted by u/Swing-Many - 3 votes and 7 comments
• Dynamic Blocks - Configuration Language | Terraform | HashiCorp ... | If omitted, the name of the variable defaults to the label of the dynamic block ( "setting" in the example above). The labels argument (optional) is a list of ...
• Optional blocks in a resource : r/Terraform | Posted by u/alexs77 - 2 votes and 2 comments
• Add optional block syntax · Issue #21717 · hashicorp/terraform ... | Current Terraform Version Terraform v0.12.2 + provider.external v1.1.2 + provider.google v2.7.0 Use-cases some resources define blocks (not arguments) that make a difference whether they are presen...
• Terraform “dynamic” inside “dynamic” blocks — an implementation ... | Sometimes, to tackle seemingly easy tasks, one needs to venture into uncharted territory to find a solution.
• Terraform's optional inputs and variables | by Alex Tjahjana | Medium | Sometimes you need to configure your inputs as optional. You can use nullable, optional() or dynamic block
• Terraform - how to make a block optional : r/Terraform | Posted by u/ss-000 - 3 votes and 5 comments