[Terraform] AWS 3-tier Achitecture를 구성하기 위한 Terraform 프로젝트 구조 잡기

아직 Terraform을 통해 AWS의 VPC 생성 조차 해보지 않았다면, 아래 링크인 이전 포스팅을 참고하길 바란다.

https://co-no.tistory.com/entry/Terraform-%ED%85%8C%EB%9D%BC%ED%8F%BC%EC%9D%84-%ED%86%B5%ED%95%9C-AWS-%EA%B5%AC%EC%84%B1-VPC-%EC%83%9D%EC%84%B1

[Terraform] 테라폼을 통한 AWS 3-tier 구성 (1) - AWS CLI 설정 및 VPC 생성

---

일단 Terraform 파일을 작성하기 전에, 깔끔한 Terraform 프로젝트 관리를 위해 Terraform 공식 홈페이지에서 권장하는 'Standard Module Structure' 를 참고하여 다음과 같이 디렉토리를 구성하자.

https://developer.hashicorp.com/terraform/language/modules/develop/structure

Standard Module Structure | Terraform | HashiCorp Developer

 

테라폼 프로젝트 '3-tier-aws' 의 디렉토리 구조

 

이전 포스팅에서 테스트한 AWS VPC 만드는 과정을, 테라폼 프로젝트를 깔끔하게 관리하기 위해 다음과 같이 구성하였다. 구성할 때, 외국 개발자 깃헙 중 테라폼 프로젝트가 아주 깔끔해 보여 해당 구조를 차용하였다.

https://github.com/BJWRD/three-tier-architecture/blob/main/main.tf

 

잘 이해가 가지 않더라도, 일단 아래 tf 파일들을 우선 다 작성하자!

 

1. 프로젝트 *루트 모듈의 main.tf

*루트 모듈 : 테라폼이 실행되는 디렉토리를 '모듈'이라 하는데, 이때 루트 모듈이란, 기본 작업 디렉터리의 정의된 파일 집합을 '루트 모듈'이라고 한다.

# main.tf

provider "aws" {
  region = var.region
}

module "vpc" {
  source       = "./modules/network"
  project_name = var.project_name
  environment  = var.environment
  vpc_id       = module.vpc.vpc_id
  vpc_cidr     = var.vpc_cidr
}

 

2. 프로젝트 *루트 모듈의 variables.tf

# variables.tf

variable "region" {
  description = "AWS Region"
  type        = string
  default     = "ap-northeast-2"
}

variable "project_name" {
  description = "Name of Terraform Project"
  type        = string
  default     = "AWS_3-Tier-Architecture"
}

variable "environment" {
  description = "Environment Type"
  type        = string
  default     = "dev"
}

################################################################################
# VPC Module - Variables 
################################################################################

variable "vpc_id" {
  description = "The VPC to be deployed"
  type        = string
  default     = "aws_vpc.VPC_3Tier.id"  
  # vpc module의 main.tf에서 지정한 aws_vpc 리소스의 name을 가지고 id를 조회해야 함.
}

variable "vpc_cidr" {
  description = "The VPC Network Range"
  type        = string
  default     = "10.0.0.0/16"
}

 

3. modules/network/variables.tf

variable "project_name" {
  description = "Name of Terraform Proejct"
  type        = string
}

variable "environment" {
  description = "Environment Type"
  type        = string
}

variable "vpc_id" {
  description = "The VPC to be deployed"
  type        = string
}

variable "vpc_cidr" {
  description = "The VPC Network Range"
  type        = string
}

 

4. modules/network/main.tf

locals {
  required_tags = {
    project      = "AWS_3-tier-architecture"
    environment  = "dev"
  }
}

################################################################################
# VPC
################################################################################
resource "aws_vpc" "VPC_3Tier" {
  cidr_block = var.vpc_cidr
  
  tags = merge(local.required_tags, { Name = "VPC-3Tier" })
}

 

5. modules/network/output.tf

output "vpc_id" {
  description = "The VPC to be deployed"
  value       = aws_vpc.VPC_3Tier.id
}

 

테라폼은 관리하는 인프라 인스턴스마다 모듈별로 나누어 관리할 수 있으며, 하위 모듈(디렉토리)에 작성한 tf 파일은 직접 실행이 되지 않는다. 루트 모듈에서 해당 하위 모듈을 호출하는 방식으로, 실제적으로 '실행'되는 것은 루트 모듈(main.tf) 하나인 것이다.

 

Visual Studio Code의 'Graphviz Interactive Preview' 라는 플러그인을 활용하여, terraform graph > graph.dot 명령어 수행을 통해 생성된 graph.dot 파일을 아래 그림과 같이 확인해 보자!

위 테라폼 프로젝트의 graph

 

테라폼 코드의 실행 순서는 terraform init 명령을 수행한 디렉토리를 루트 모듈(디렉토리)로 잡고, 그 하위에 있는 모든 .tf 파일을 스캔한다. 이때 해당 코드를 분석하여 실행 순서를 결정하는데, 만약 코드 실행 선후관계까 없다면 해당 코드는 병렬로 수행되고, 반대로 선후관계가 존재한다면 해당 코드는 순서대로 실행되게끔 종속성 그래프에 해당 정보가 들어간다.

 

위와 같은 테라폼 수행 방식을 이해했다면, 다음과 같이 테라폼 코드를 작성하는 순서를 어느정도 결정할 수 있다.

1. 루트 모듈의 main.tf를 작성한다. 이때, main.tf는 서브 모듈을 호출하는 방식으로만 작성한다.
2. 루트 모듈의 main.tf 실행에 필요한 변수들을 루트 모듈의 variables.tf 파일로 작성한다.
3. 루트 모듈의 variables.tf를 통해 유저로부터 입력받은 또는 정의된  변수를 실제 인스턴스 생성에 관여하는 서브 모듈(main.tf)의 속성값으로 넣어주어야 하는데, 이에 대한 매개체 역할이 서브 모듈의 variables.tf 파일이다.
   따라서 우선 서브 모듈의variables.tf 파일을 루트 모듈의 variables.tf 타입과 맞추어 작성해 준다.
4. 서브 모듈의 main.tf 를 작성한다. 서브 모듈의 main.tf는 루트 모듈에서 호출하는 module에 대한 실제 구현방식(?)인 resource 구문으로 작성한다. 그리고 루트 모듈에서의 변수 입력이 아닌, 서브 모듈의 resource 구문에서 곧바로 필요한 변수를 local 변수로 작성한다.
5. 서브 모듈의 resource 구현 이후 (실제 인스턴스 생성 이후)에 발생하는 variable이 루트 모듈에서 사용되어야 한다면, 해당 서브 모듈의 output.tf 파일로 작성한다.

 

위와 같이 구조를 잡고 테라폼 일단 테라폼 프로젝트를 작성하면, 반복되는 코드의 사용 및 수정이나 종속성에 영향이 생기는 문제는 많이 줄일 것으로 예상된다.혹여나 중간에 큰 문제가 생기면, 다시 프로젝트 구조를 변경해야 할 수도 있다. 

 

더 좋은 프로젝트 구조를 발견하고 테라폼 동작 방식을 좀 더 명료하게 설명할 수 있다면, 이 포스팅을 수정될 수도 있다..!

---

참고

https://github.com/BJWRD/three-tier-architecture

GitHub - BJWRD/three-tier-architecture: Highly Available, Fault Tolerant, Three-Tier-Architecture on AWS provisioned via Terrafo

https://malwareanalysis.tistory.com/619

테라폼으로 EKS만들기 프로젝트 3-2편 - 테라폼 동작원리