The DevOps Team's Terraform Adventure

The Kurly DevOps Engineering Team introduced Terraform to address management complexity caused by an increase in service launches and a surge of infrastructure across various environments (Stage, QA). Starting last August, they established an IaC (Infrastructure as code) strategy, applying it first to the Stage and QA environments before expanding to the production environment as they accumulated know-how.

Module Structure and Code Management

Considering the team's lack of experience with Terraform, they relearned the basics from scratch, and chose a 'large' structure in consideration of managing multiple AWS accounts and future application to the production network. The code was separated into env (dev, stg, etc.) and modules (acm, asg, efs, lb_listener, etc.), with source code managed in a GitHub private repository. tfstate files were stored in an S3 bucket under the Infra account, with a security policy applied that blocks AWS console modifications and only allows updates via a Terraform execution Accesskey.

Refactoring and Use of Dynamic Blocks

Initially, there was pain caused by repetitive variable declarations, but they used the locals keyword and the merge function to consolidate tag options and simplify the Environment Code. In addition, to solve problems that arose when adding or specifying EBS volumes in the Launch Template, they introduced dynamic block. By defining var.block_device_mappings as a list(object) type and using the lookup function to treat missing values as null, they refactored the setup so that the master image AMI and additional EBS volumes could be mapped simultaneously.