Tag: design-pattern

In this blog post, I'm going to share how to use Input Variables a.k.a variables, and Local Values a.k.a locals, to form a well-maintained infrastructure in Terraform while following the MVC design pattern.

The Approach

• Local Values (Model) are altered behind the scenes by architects, regardless of the application's Modules and Resources (View)
• Modules and Resources (View) are implemented according to the Local Values (Model)
• Input Variables (Controller) get user input and manipulate the Local Values (Model). These changes are reflected in Modules and Resources (View)

	Description (Source)	In Terraform
Model	Managing the data of the application	Local Values
View	Presentation of the model in a particular format	Modules and Resources
Controller	Receives the input, optionally validates it, and then passes the input to the model	Input Variables

Input Variables (Controller)

Mainly used for getting a dynamic input from architects and CI/CD processes. Here's a classic snippet of how Input Variables are used

variables.tf

variable "app_name" {
  type = string
}

variable "region" {
  type = string
}

variable "environment" {
  type        = string
  description = "dev, stg, prd"
}

• Avoid setting default values to "information variables". This enables other architects (or future you) to use the same Infrastructure-as-Code (IaC), without worrying about predefined names. Examples:
  • app_name
  • region
  • domain_name
• Set default values to "infrastructure and application variables". Examples:
  • desired_tasks = 1
  • firewall_enabled = true
  • docker_image = "nginx:1.19.2"

Variables As Maps

The combination of Input Variables, the default attribute, and the lookup function is amazing. For example, according to a given value, environment, get the relevant default value from a map. A more practical example:

variables.tf

variable "environment" {
  type        = string
  description = "dev, stg, prd"
}

variable "cidr_ab" {
  type = map
  default = {
    dev = "10.1"
    stg = "10.2"
    prd = "10.3"
  }
}

main.tf

module "vpc" {
  source             = "terraform-aws-modules/vpc/aws"

  # Later on we'll set cidr to a Local Value
  cidr               = "${lookup(var.cidr_ab, var.environment)}.0.0/16"

  # ... removed other attributes for brevity
}

Local Values (Model)

Any value that has even the slightest chance of changing in the future should be set to a Local Value. This means that most of the IaC will include Local Values. Terraform's official docs recommendations:

... if overused, Local Values can also make a configuration hard to read by future maintainers by hiding the actual values used ... Use local values only in moderation, in situations where a single value or result is used in many places, and that value is likely to be changed in the future. The ability to easily change the value in a central place is the key advantage of local values.

Local Values are "overused" to make the code modular and easier to maintain. To share the true powers of this approach, here's another practical example:

main.tf

module "vpc" {
  source             = "terraform-aws-modules/vpc/aws"
  version            = "~>2.0"
  name               = local.prefix
  cidr               = local.vpc_cidr
  private_subnets    = local.private_subnets
  public_subnets     = local.public_subnets
  azs = local.availability_zones

  tags = local.tags
}

Do you realize what this means? it's possible to manage all the values in a single place

variables.tf

# Input Variables (Controller)
variable "app_name" {
  type = string
}

variable "region" {
  type = string
}

variable "environment" {
  type        = string
  description = "dev, stg, prd"
}

variable "cidr_ab" {
  type = map
  default = {
    dev = "10.1"
    stg = "10.2"
    prd = "10.3"
  }
}

# Local Values (Model)
locals {
  prefix   = "${var.app_name}-${var.environment}"
  vpc_cidr = "${lookup(var.cidr_ab, var.environment)}.0.0/16"
  public_subnets = [
    "${lookup(var.cidr_ab, var.environment)}.1.0/24",
    "${lookup(var.cidr_ab, var.environment)}.2.0/24",
  ]
  private_subnets = [
    "${lookup(var.cidr_ab, var.environment)}.10.0/24",
    "${lookup(var.cidr_ab, var.environment)}.20.0/24",
  ]
  availability_zones = ["${var.region}a", "${var.region}b"]

  tags = {
    "Environment" : var.environment,
    "Terraform" : "true"
  }
}

Practical implementation

I've created a GitHub repository that implements the described MVC design pattern in Terraform. This repository also includes a CI/CD process for promoting environments. Here it is unfor19/terraform-multienv

Final Words

I hope you find this useful, and if you do, don't forget to clap/heart and share it with your friends and colleagues.
Got any questions or doubts? Let's start a discussion! Feel free to comment below.

---

Originally posted in https://dev.to on September 14, 2020.