Production-level Guide to Terraform

Introduction

Thank you for clicking through to my article. I've been a DevOps Engineer for 2 years in dev-team of 7 engineers.

My name is MINSEOK, LEE, but I use Unchaptered as an alias on the interenet. So, you can call me anythings "MINSEOK, LEE" or "Unchaptered" to ask something.

Topics

This article has these topics.

• Understanding the basic syntax of terraform

• Understadning the reusable modules system as a CMS Pattern

• Problem of CMS Pattern and Solution

Prerequisites

This is the story of what happened after we finished "Terraform Journey in Startup".

In addition, you'd have the following experience.

• Basic experience with Terraform

• Basic understanding of various blocks in Terraform
  Resource, Data, Lock, Provider and so on

Article's KEYWORD

As you may know, terraform already has various keywords.
If you don't know terraform well, you should look at this chapter, "Terraform's Keyword".

In this article, I used some KEYWORD to help your imagination.
So to avoid confusion by conflict of keywords, I'll write article's keyword as a upper case.

• "module block" means terraform's module block syntax.

• "MODULE" means article's syntax in chantper "Design of Structure".

Terraform's Keyword

As I said in "Terraform Journey in Startup # Requisites", Terraform is an IaC Tool.
It allows you to create and destroy EC2 in AWS. To implement complex tasks, terraform has various keywords.

Terraform has a native syntax called HCL and we used it.
Of course, it also supports jSON, but it's not a standard syntax.

• resource block
  Describe one or more infrastructure objects, such as virtual network, compute instances, or higher-level components such as DNS records.

• datasource block
  Allow terraform to use information defined outside of terraform, defined by another separate terraform configuration.

• local block
  Define operations on local machine where terraform is running.

• variable block
  Make terraform is possible to pass values at terraform runtime.
  [Tips]
  A similar feature is local block, but it creates variables at the time HCL is written. Of course, variable block has a property named defualt(default value). But, the purposes of local and variable block were different.
  And in this article, we don't use local block.

• output block
  Make information available on the command line.
  Expose information for other terraform configurations to use.

• argument and attribute

  The resource, datasource, local block commonly has agrument and attribute.

• module block

Design of Structure

This chapter, I'll introduce CMS(COMPONENT-MODULE-SERVICE) Pattern.
In CMS Pattern, I used 6 kind of blocks only. This pattern is very DRY, KISS, YAGNIand make each module more reusable.

1. COMPONENT is high-level property of patterns.
   It contains resource, datasource, local blocks as a small module block.

2. MODULE is middle-level property of patterns.
   It's a group of each COMPONENTS. MODULE Engineer creates MODULE as a specific purpose. This module should be built with key principles in mind, such as the Principle of Least Privillege.

3. SERVICE is row-level property of patterns.
   It's a group of each MODULES. SERVICE Engineer uses MODULE as parts of service.

   

Examples

You can find similar examples of this in my current side project, IaC Storage.

COMPONENT

By default, It consists of these files.

main.tf
outputs.tf
variables.tf

MODULES

By default, It consists of these files

# Requirement Section
_.provider.tf
_.variables.tf

# Optional Section
_.locals.tf

# Modules Section
<prefix>.<fileName>.tf

To help you understand it, I've prepared an "Assets Storage MODULE". In example, file consists of 3 type of section.

1. Requirement Section