Terraform Conditionals: Writing and Maintainable Configurations

Conditional expressions give the ability to make decisions in Terraform configuration so that resource definitions can be dynamic based on variable values or some other condition. This is critical for creating flexible, reusable infrastructure code.

Syntax of Conditional Expressions

condition ? true_value : false_value

The generic syntax of a conditional expression in Terraform is as such:

condition: An expression that is either true or false.

true_value: The value returned if the condition is true.

false_value: The value returned if the condition is false.

Conditional expressions may also be used to assign values dynamically to resource attributes. For example, take into account choosing a Log Analytics workspace for diagnostic logs on a Key Vault based on an environmental variable.

Limitations of Conditional Expressions

This explains the limitations of conditional expressions while powerful:

1. Type consistency: Both true_value and false_value must be of the same type. Terraform tries automatic type conversion, but type inconsistencies often account for erroneous configurations. Explicit type conversion is often recommended to avoid such issues.
2. Complexity management: It makes conditions very complex when you overuse conditional expressions. One must find the right balance in their usage to ensure the codebase remains maintainable while adding to readability.

When to use conditional expressions?

Use conditional expressions when you want to:

1. Dynamically assign values based on specifying conditions.
2. Turn on or off resources or modules based on certain variable inputs.
3. Avoid rewriting resource definitions that would make the configurations neater.

2. Meta-Arguments: count and for_each

Terraform meta-arguments of count and for_each provide a mechanism to manage resource-and-module instances depending on configuration needs dynamically.

The count Meta-Argument

The count meta-argument dictates how many instances are created for a given resource or module.

Consider a scenario where you want to enable the diagnostic settings based on the environment. You can achieve this using the count meta-argument in combination with a conditional expression:

Count Limitations:

1. Indexing Issues: Resources with creation count are indexed in order numerically. The removal of an item from the middle of the list will make Terraform delete and recreate the resources, thus leading to potential downtime or data loss.
2. Due to Indenxing, the count fails to reference computed values
3. Lack of Granular Control: The primary downside of count is its somewhat limited flexibility in dealing with complex data structures or any configurations that require configuration unique to each one.

The for_each Meta-Argument

The for_each meta-argument allows you to iterate over maps or sets, creating one instance for every item.

Limitations of for_each

1. Complexity: By adding for_each into the mix concerning the depth of nesting or interaction with other dynamic constructs, a whole new level of complexity gets into the configurations.
2. Resource Addressing: The resources created by for_each are then addressed by their keys, and improper handling could lead to complications with such references.

Choosing Between count and for_each

Use count when you need to create a certain number of identical resources, with no need for unique identifiers or configurations.

Use for_each when modeling collections that need unique keys or otherwise whenever each instance has a different configuration.

3. Dynamic Blocks in Terraform

Dynamic blocks in Terraform allow for the dynamic generation of nested blocks within a resource or module. This is particularly useful to specify the dynamic nested blocks and their configurations, of which the counts may not be known ahead of time.

Suppose you want to attach several access policies for the Azure Key Vault instance based on the variable input.

Limitations of Dynamic Blocks

1. Loss of Clarity: Over-reliance on dynamic blocks makes the configurations hard to read or maintain. They should thus not be used too frequently; consider using them only when needed.

2. Difficult to Debug: Dynamically created blocks may complicate debugging and troubleshooting since the created-out configuration is never explicitly defined in the code.

4. Ideal Usage Cases Scenarios

Best for conditionally creating a single resource (e.g., count = var.enable_resource ? 1 : 0).

Best when different attributes exist on each resource, yet you still need fine-tune control.

Best for instances where the number of nested blocks may not be known ahead of time or where this is determined by variables.